Fixed [Fixed for 2.2] A_Boss1Laser doesn't work properly when set by Lua

Status
Not open for further replies.

FuriousFox

AKA FuriousFox
1. Load the attached Lua file (test.lua)
2. Go to MAP03 (Greenflower Zone, Act 3)
3. Wait for the boss to fire

Expected Result:
Boss should fire a laser along the ground that rises towards the player.

Actual Result:
Boss fires laser directly into the ground. On subsequent attacks, the boss fires directly at the player.

Note:
The settings in the Lua file are the default settings for those two states, as stated by info.c and the SRB2 Wiki. Using SOCs works fine, it just seems to be Lua that's having a problem.
 

Attachments

  • test.lua
    448 bytes · Views: 308
Last edited by a moderator:
After testing it a little further, it looks like it only fires for one tic, and MT_EGGMOBILE_TARGET doesn't spawn on subsequent attacks. Not sure why, though.
 
Last edited:
That sounds very strange indeed. Any idea if anything weird could be going on with MT_EGGMOBILE_TARGET the first time?

BTW A_Boss1Laser is a weird action that is run for every single tic the state that called it lasts, through some MF2_FIRING hack or something. In case it helps to know these things.
 
Wait, hang on a sec, what happens if you put quotation marks around A_Boss1Laser in the Lua script? Just checked lua_infolib.c (the source code file where Lua handles state/mobjinfo modification) and I think I suspect what's going on here now.
 
Yeah, that's it then. Supplying one of the names for actions that already exist as a string actually makes the game look for the action function that goes with that string. Supplying anything else (whether it be a custom function or a pre-existing C function) will make Lua think you're supplying a custom Lua action of some sort, which is handled by some special source-code exclusive action called "A_Lua". This action then runs whatever function you supplied as the state's action when it is called on changing state. However, this causes the code to run A_Boss1Laser again and again for the rest of the state to fail, since the state's action is now A_Lua and not A_Boss1Laser directly!

No other action in the source code needs to be run for the rest of the state's duration like A_Boss1Laser does, this is why A_Boss1Laser is the only one that fails without quote marks. =V

EDIT: If that was too much to read, have this instead: when you supply names for actions without quote marks, the state's action actually becomes A_Lua, which in turn runs the action. A_Boss1Laser's code for running after the state's first tic requires the state's action to actually BE A_Boss1Laser, which is where the problems come from.
 
Last edited:
Sorry for the inconvenience, FuriousFox. You happened upon a previously undiscovered edge case consequence of my crazy programming. We'll figure out how to fix it for the next version, for now the quotation marks workaround will suffice.
 
Status
Not open for further replies.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top