Doing Lua stuff on a SOCed object.

[Lat']

Basically, I'd like to interact with a "SOC-made" object with Lua (changing states when some conditions are met etc), the thing is that I don't know how I should even get started, by that I mean I don't even know what I am supposed to do to tell the Lua to do this for this object and not another one.

I hope I was clear enough.

 

[742mph]

If you've already written the SOC for it, you can simply treat a custom object type like you would any type from vanilla SRB2 when it comes to Lua. You can add hooks for it, create new instances of it with P_SpawnMobj, refer to it by its custom name, etc. The only extra thing you should do is add the names of any custom objects, states, sounds, etc. to a freeslot block at the top of the Lua lump you're referencing them in, e.g. freeslot("MT_OBJECT", "S_STATE", "SFX_SOUND").

 

[Lat']

If you've already written the SOC for it, you can simply treat a custom object type like you would any type from vanilla SRB2 when it comes to Lua. You can add hooks for it, create new instances of it with P_SpawnMobj, refer to it by its custom name, etc. The only extra thing you should do is add the names of any custom objects, states, sounds, etc. to a freeslot block at the top of the Lua lump you're referencing them in, e.g. freeslot("MT_OBJECT", "S_STATE", "SFX_SOUND").

So if I understood right, I should be golden if I spawn the object with Lua and give it its custom name instead of placing it in the map editor?

 

[742mph]

You can do that if you want, or you can set MAPTHINGNUM = <number> in the object type's SOC block, where <number> isn't already used by a vanilla object, and place an object with its type set to <number> in your level. As long as your SOC is loaded when the level starts, the game will recognize the object type that's supposed to go there and spawn it, even if the map editor tells you it's an unrecognized type.

 

[toaster]

The reason 742mph suggests adding the freeslot is because of the fact that Lua is loaded before SOC. This means you must either define your SOC objects through Lua syntax, or define them through SOC whilst defining their freeslots in Lua. Either way will enable you to refer to the object via MobjThinker hooks and P_SpawnMobj (and any other situation where you need to explicitly refer to a type), but the former way will also enable you to read their structures. For example, mobjinfo[MT_OBJECT].height may return nil if MT_OBJECT is not defined in Lua. (mo.height will always be a number, though.)

Ultimately, it's an annoying side effect of the order of operations upon WAD load - and one that has led me to define all my objects in Lua alone.

 

[Lat']

Alright, so I thrown all of my SOCs freeslots in the Lua script, and tried to do some things using a MobjThinker hook, unfortunatly, it doesn't affect the mobj at all.

addHook("MobjThinker", function(knux)
    if knux.state == "S_CHUCKBOSSGLIDE12"
    and P_IsObjectOnGround(knux)
        knux.state = "S_CHUCKBOSSSPAWN2"
    end    
end, MT_CHUCKLESBOSS)

The Lua doesn't output any error, it just doesn't do what it should do. What did I screw up there?

 

[toaster]

How are you adding the file? If you're using a launcher or .bat file, any errors in the file's loading (not running) will be printed in log.txt only, not mirrored to the console. I don't see anything wrong with that section at a glance, so take a look at log.txt to see if there's an error somewhere else in the file.

edit: woops

 

[Zipper]

addHook("MobjThinker", function(knux)
    if knux.state == "S_CHUCKBOSSGLIDE12"
    and P_IsObjectOnGround(knux)
        knux.state = "S_CHUCKBOSSSPAWN2"
    end    
end, MT_CHUCKLESBOSS)

Don't use quotes around the state names.

e.g. S_CHUCKBOSSGLIDE12 instead of "S_CHUCKBOSSGLIDE12"

 

[Lat']

Don't use quotes around the state names.

e.g. S_CHUCKBOSSGLIDE12 instead of "S_CHUCKBOSSGLIDE12"

Wow, I didn't know the error was that dumb, especially because I already did state-changing Luas before... Thanks anyway, this works perfectly!

 

[Lat']

Another question, but is there a way to properly check if my object is moving or not? (Like player.speed)
Using both knux.momx and knux.momy leads to weird things where the game considers the object is "standing" when it is still moving, and I didn't really found another way to check if it's moving or not.

 

[742mph]

Another question, but is there a way to properly check if my object is moving or not? (Like player.speed)
Using both knux.momx and knux.momy leads to weird things where the game considers the object is "standing" when it is still moving, and I didn't really found another way to check if it's moving or not.

Are you sure the game has trouble when you just check if knux.momx == 0 and knux.momy == 0? If it does, that's weird, but another thing you can do is check if FixedHypot(knux.momx, knux.momy) < <small>, where <small> is some small but non-zero value like FRACUNIT or FRACUNIT/2. That way, the script will consider the object to be stationary even if its horizontal momentum is very small but not exactly zero.

 

[Lat']

Are you sure the game has trouble when you just check if knux.momx == 0 and knux.momy == 0? If it does, that's weird, but another thing you can do is check if FixedHypot(knux.momx, knux.momy) < <small>, where <small> is some small but non-zero value like FRACUNIT or FRACUNIT/2. That way, the script will consider the object to be stationary even if its horizontal momentum is very small but not exactly zero.

Having to wait til both momx and momy hit 0 was extremely weird for the walking animation, and Knuckles ended up walking with a borderline 0 speed, but with FRACUNIT, the game considered Knux to not have both of them anymore while he was still moving. Works much better with what you sent me, Thankies~