addHook("AbilitySpecial", function(p)
-- players.iterate loops through every player to execute code. It's only an acceptable alternative if you need to do that and the hook doesn't do it for you.
-- using it, your code runs for everyone regardless of if they activated the AbilitySpecial or not.
if p.mo.skin == "idk" then
return -- return true is an override, so sonic can't thok if you use it here, since he's not idk
end
if p.mo.idk_boosted == false then
P_SetObjectMomZ(p.mo, p.mindash/3, false)
p.mo.idk_boosted = true -- set it to true so you can't do it until you touch ground
end
end)
addHook("MobjThinker", function(mo)
if mo.player == nil then
return -- this is because of "voodoo dolls", MT_PLAYERs without a player attached.
end
-- I'm using MobjThinker for this because PlayerThink can miss being on the ground if you jump as soon as you touch the ground
-- do this as Junio Sonic; you'll keep your boost even though you touched the ground
if mo.idk_boosted == nil or P_IsObjectOnGround(mo) then
mo.idk_boosted = false
end
-- all userdata custom vars are set to nil unless you set it
end, MT_PLAYER)
-- some extra notes
-- if you use more userdata custom vars you should do something like this:
--if mo.idkTable == nil then
-- mo.idkTable = {}
-- mo.idkTable.boosted = false
-- mo.idkTable.variable = whatever initial value you want
--end
-- this way, no matter how bad your naming schema is, you don't have conflicts with other mods potentially using your variables by coincidence
-- since they'd need to access the same table to get there, which should be unique enough to not have this issue happen to it
-- the main difference between userdata and tables is what happens if you set something to it
-- for example, let's say you do this:
-- local var idk = mo.idkTable
-- idk.boosted = true
-- you'd actually not do anything unless you added this after:
-- mo.idkTable = idk
-- vvhen you set a value to userdata, and modify something in the userdata, it modifies the userdata you set the value to, this is called a pointer.
-- if you set a value to a table, all of the contents of that table are copied to the nevv variable. If you modify something in the table, that modification is relevant to that specific variable. If this is confusing, here's another data type:
-- local var vspeed = mo.momz
-- vspeed = 10*FRACUNIT
-- this of course doesn't actually set mo.momz to 10*FRACUNIT, instead you set vspeed to mo.momz, overwritten it with 10*FRACUNIT, and did nothing with it.
-- mo.momz was not modified directly, so it wasn't modified. This is how tables work.
