[v0.9.0] ZetaBot: The ZScript Bot

[Gustavo6046]

There's also a commits list, but I think the Releases section is better presented, although maybe a bit incomplete with the changelogs. I should write a CHANGELOG file.

[JPL]

Two flies, one rock. I just compiled GZDoom from GitHub, and it really does have that damn assertion error. It's probably a ZScript error that wasn't caught before being compiled into internal code (and that thus ended up being caught only by assertions). Thing is, I don't know where the error is!

Code: Select all • Expand view

gzdoom: /home/gustavo6046/Projects/gzdoom_build/gzdoom/src/scripting/backend/codegen.cpp:2319: virtual ExpEmit FxPostIncrDecr::Emit(VMFunctionBuilder *): Assertion `ValueType == Base->ValueType && IsNumeric()' failed.

"FxPostIncrDecr" seems to suggest it's an issue with incrementing or decrementing. But it takes a FunctionBuilder pointer as argument, so it's probably part of a ZScript function. That isn't specific enough, so I'll just focus into checking increments and decrements are all applied to proper variables.

I wonder whether the issue is that the variable has an unmatching type (to whatever Base's ValueType member is), or if it's just not a numeric value. I will look for it, nonetheless.

Fortunately I have that source code file, so I can read it myself. (:

-------

BREAKING NEWS EDIT: I somehow fixed the mysterious assertion error, by fiddling with Standard.zsc. I'll perform test runs and tell once 0.3.20.4.0 is out.

EDIT 2: 0.4.0 is now out! Check the first post for more.

I hate to say it, but I'm still seeing this Assertion Failed with the latest release (0.6.0) with the latest GZDoom git master ("4.2 pre") in Linux. Tried it with a fresh config and doom2.wad, no change.

[Gustavo6046]

Maybe the error returned in later versions. If it does, then it's most likely GZDoom's fault. I do not yet understand what causes it exactly, though it seems to be related to increment/decrement operators. Fiddles and refactors within the source code sometimes fixes it.

[Gustavo6046]

I have released v0.7.1, which adds Heretic support! Yee-haw!

I haven't yet addressed the issue JPL brought to the whiteboard. I fear that is an issue with more recent versions of GZDoom.

[Gustavo6046]

Once Hexen support is done, the ZetaBots will be in the Release Candidate stage!

I realized we digressed a little bit from the original path of having the mapper plop nodes for the map manually, as the bots node the map themselves as they wander on it, by default. But then again, nodes are seldom used for wandering, being instead used for hunting enemies and following the "commander" (which 99.9% of the time means getting stuck somewhere).

Bots also seem to be able to get stuck into walls when they respawn into a node that was plopped too close to a wall. I don't know how to fix that, sadly. Maybe I should somehow fix how they plop nodes, in a way those aren't plopped into the wall?

[TDRR]

Maybe I should somehow fix how they plop nodes, in a way those aren't plopped into the wall?

Just give them the radius of a player and spawn them via the ACS special Spawn, which won't spawn anything if the actor in question doesn't fit in that space.

[Nash]

This is a ZScript bot, why would Gustavo use ACS when they could do the exact same functionality natively with ZScript?

[Gustavo6046]

Just give them the radius of a player and spawn them via the ACS special Spawn, which won't spawn anything if the actor in question doesn't fit in that space.

ZScript does have that. Nonetheless, the radius idea is nice! Though they already (seem to) spawn at the center of the bot's position, even though they're smaller in radius, so maybe I should adjust it in some other way instead? Or maybe the bots are somehow going far into the walls themselves (though that wouldn't make much sense).

I'll try verifying it on respawn instead.

[Gustavo6046]

In v0.7.3 you will be able to see the paths between nodes! Yay!

[TDRR]

This is a ZScript bot, why would Gustavo use ACS when they could do the exact same functionality natively with ZScript?

I meant using Spawn() as a special on ZScript, doesn't ZScript have access to all ACS specials?

[Gustavo6046]

doesn't ZScript have access to all ACS specials?

ZScript has all access to DECORATE functions on actors, and many, many extra goodies.
ACS is a different kind of script.

[TDRR]

ZScript has all access to DECORATE functions on actors, and many, many extra goodies.
ACS is a different kind of script.

That's kinda obvious, and i already know that, but i read somewhere ZScript could use the same actions ACS could, apparently that's either not true or outdated.

[Nash]

Again, this mod is fully written in ZScript, taking advantage of everything working with ZScript has to offer, why would you suggest the author call the ACS variant of Spawn when they can directly call the Actor.Spawn() method in ZScript?

Anyway, it is clear Gustavo knows what they're doing and has apparently already solved the problem, so no need to suggest ghetto solutions to them when they have far better ways of doing things. :P

[Gustavo6046]

Um, it's a minor issue. I haven't fixed it yet. But I already know how to fix it. I'll probably change it in the respawning routine. Maybe there is a way to check for encroaching with walls (non-sector space) in the call to Spawn, so I can do something like a "max 5 tries" counter, and have the bot wait 40 tics if all tries fail before trying again...

EDIT: I fixed it! =D

[Nash]

Gustavo, I know you said you fixed it, but in case you weren't aware - have a look at Actor's TestMobjLocation() - it returns false if something is obstructing the actor. You can also have a look inside GZDoom's ZScript sources for example usage.