Crash with zscripted BD

[Apeirogon]

I try convert brutal doom to zscript.
Firstly gzdoom throw errors like "miss semicolon" or "lack of bracket".
But after I fix `2000 of such errors, gzdoom after start finds millions of errors and crash.

CrashReport.zip

(29.88 KiB) Downloaded 20 times

According to log, it also cant find some ancestors for some actors. Example in the beginning of a log, "WaterParticleXTinySpawner has unknown base class BlueParticleXSpawner". Both classes placed IN THE SAME FILE, I double check it.

I think this is because I mostly convert decorate to zscript, instead of fixing all crutches and hacks in code before do so.
But Im not sure about it.

[Matt]

Is BlueParticleXSpawner still Decorate while WaterParticleXTinySpawner is now ZScript?

Anything in ZScript must inherit from something in ZScript if they're loaded at the same time.

[Graf Zahl]

A crash without the file causing it is useless, especially if it so strongly hints at "user error".

[Matt]

Move this topic to Scripting maybe?

[Graf Zahl]

I'll wait for a day to see if he still posts some code.

[Apeirogon]

You need just code or code with sprites/sounds/etc so it can be launch?

[Graf Zahl]

It must launch and cause the crash. Include the minimum set of data for that.

[Apeirogon]

Give me 3-4 days so I can figure out what I can throw away.

[Apeirogon]

I cant make zscript example, because every time I delete anything from pack, sprites/sounds/etc., this particular error, cant find base class and its successor, appears/disappears and I cant find any system in this.

BUT, I can make tiny decorate example with similar problem. In decorate example, gzdoom again cant find base actor and it successor. Both files included in base decorate file, and base actor exist under same name under which successor use to inherit from it. But this happens only if included decorate files placed in folders.
If files lies like a pile of garbage in the pack root, gzdoom load it without any problem.

https://drive.google.com/file/d/1h7DfQa ... P1iGd/view
Unpack archive and drop on gzdoom firstly "in folders" folder and then "pile" to see what I mean. Use doom2 iwad.

[_mental_]

Order of #include's are different in 'pile' and 'in folders' test cases. That's the sole reason for a different outcome.

As for the crash, please provide a complete runnable sample, even if it's not so minimal. There is nothing can be done without it.

[Apeirogon]

Oh, so #including order is that important!? I thought that gzdoom smart enough to firstly load all resources and code and only then check it for errors.

I check zscript version, maybe there are too wrong "#including" order.

[Graf Zahl]

Including order is important for inheritance. You cannot inherit from something that hasn't been defined yet. Most of the rest can be resolved out of order but object size definitely not. To build a child class you need to know how large the parent is, and the only way is to define it before the child.

[Apeirogon]

You can close it as user error.
"Sergei Markov 4" is an idiot, because he defined non defined actor in actual code which used to spawn blood actors, which hidden in depth of fake errors because of....well, I dont know exactly why, but after I fix/replace all "Try to call a_changeflag/a_custommissile/and such, deprecated since jurassic period" "yellow" errors this is the one of the last unsolved "red" error which appears in gzdoom loading windows.
And Im an idiot because try to port his v21 alpha code to zscript.

[Matt]

Apeirogon, I suggest you follow DavidN's BDLite project for a bit... he's making huge strides in turning BD into something with more sensible code, which can be a much better base for any further systemic changes.

[Apeirogon]

But I want to do that alone...