ZDoom

Player701 wrote:

Marrub wrote:Thanks, rewrote the description. Apparently I wrote the description before I knew what PClass was, so now it actually tells you properly what it does.

Thank you too. A minor correction, though: right now it is not required to mark the returned value as transient, though I wish it were. Apparently, it is not that easy to implement because it's difficult to tell what objects are supposed to be serialized (and would thus need to enforce this rule) and what aren't. I would definitely recommend marking these fields transient, though - makes the code easier to understand.

The document refers to what the user must do to not cause erroneous behaviour, so the current wording is correct.

Updated existing documentation for 3.7.0 including the new flagdef keyword, finished documentation for TexMan, State and Font, and documented Screen.DrawTexture & Screen.VirtualToRealCoords. I also have split the files so as to make it easier to read.

Masterful stuff man. This is exceptionally handy. Well done!

Major Cooke wrote:Masterful stuff man. This is exceptionally handy. Well done!

Thanks. If there's anything you need documented feel free to suggest or make a pull request.

Dynamic Arrays: Whenever changing the size of one, it's important to immediately initialize anything new, unless it was Push()'d. I just tested it: trying to check the new stuff after doing a Reserve crashes GZDoom. Best to record the old size and, after the array grows bigger, fill it with default values - in particular, object arrays with nulls. Otherwise GZDoom looks into an empty container and just dies.

Perhaps that should be added as a warning on the dynamic array page?

Major Cooke wrote:Dynamic Arrays: Whenever changing the size of one, it's important to immediately initialize anything new, unless it was Push()'d. I just tested it: trying to check the new stuff after doing a Reserve crashes GZDoom. Best to record the old size and, after the array grows bigger, fill it with default values - in particular, object arrays with nulls. Otherwise GZDoom looks into an empty container and just dies.

Perhaps that should be added as a warning on the dynamic array page?

I've expanded the description to clarify how it works more exactly.

Documentation wrote:Adds amount new empty-constructed objects at the end of the array, increasing Size and calling Grow if necessary. Value types are initialized to zero and reference types to null.

If you do a reserve on an object array in ZScript and then try null checking inside it without manual initialization, it will crash. Might be something to do with a difference between an internal null and ZScript null?

Whatever the case, it must be manually initialized or it will kill the game.

Major Cooke wrote:

Documentation wrote:Adds amount new empty-constructed objects at the end of the array, increasing Size and calling Grow if necessary. Value types are initialized to zero and reference types to null.

If you do a reserve on an object array in ZScript and then try null checking inside it without manual initialization, it will crash. Might be something to do with a difference between an internal null and ZScript null?

Whatever the case, it must be manually initialized or it will kill the game.

This sounds like an engine bug, which shouldn't be documented. I suggest reporting it. (If it isn't a bug, I'll add clarification.)

So still not finished eh? You still working on it? ^^

Josko wrote:So still not finished eh? You still working on it? ^^

Not at the moment, I have other projects taking priority, and lots of real-life stuff going on.

Alright, understandable

But how far on is this documentation? How much " Complete " is it?

Josko wrote:Alright, understandable

But how far on is this documentation? How much " Complete " is it?

It depends on what you need it for. Some parts of the documentation are very complete, whereas others are quite lacking and ridden with to-do markers.

Something's coming! I'm working on a 2.0 version of the documentation, which I'll release When It's Done. The language documentation has been updated, making it easier to read and more concise. The API documentation has been expanded and made far easier to read and maintain. Additionally, it also is planned to document the supported data formats and other DSLs like MAPINFO, as well as the ACS VM and ACS language. I will hopefully be able to release this within the next few months but I can't promise anything. As usual, development updates will occasionally be posted in my Discord channel, in-between me being obsessive over music.

Now that is going to make things a ton easier to work with.

That's some very exciting news indeed.