Substitute MT_NULL with MT_RAY in Lua
As of !1973 (merged), P_SpawnMobj
no longer replaces MT_NULL
with MT_RAY
, and instead aborts spawning MT_NULL
mobj types. However, some Lua scripts, including [Silver the Hedgehog], expect MT_NULL
to be spawnable.
This merge request replaces MT_NULL
with MT_RAY
in Lua's mobj-spawning functions, with a // TODO: 2.3:
comment for making it show a Lua error instead for v2.3 (because usually, trying to spawn MT_NULL
means that something has gone wrong, that you don't want to spawn anything and so don't need to call a spawning function, or that you should be using MT_RAY
instead).
(SOC actions trying to spawn MT_NULL
will still not spawn anything, though.)
TL;DR: Reverted Lua mobj-spawning to v2.2.13's behaviour. Not worth mentioning in v2.2.14's changelog.
Merge request reports
Activity
mentioned in merge request !1973 (merged)
mentioned in merge request !2267 (merged)
44 44 else if (hook_cmd_running)\ 45 45 return luaL_error(L, "CMD building code should not call this function!"); 46 46 47 #define NOSPAWNNULL if (type >= NUMMOBJTYPES)\ 48 return luaL_error(L, "mobj type %d out of range (0 - %d)", type, NUMMOBJTYPES-1);\ 49 else if (type == MT_NULL)\ 50 {\ 51 CONS_Debug(DBG_GAMELOGIC, "Tried to spawn MT_NULL, using MT_RAY\n");\ Is it worth it for semantics' sake only? The behaviour (automatically substituting
MT_NULL
withMT_RAY
) is the same as in v2.2.13, and updating the script to useMT_RAY
doesn't cause any in-game difference. That would cause harmless-but-annoying warnings to pop up for end users, "requiring" a mod to be updated just for semantics.(For reference, this
CONS_Debug
line is taken verbatim from pre-!1973 (merged)P_SpawnMobj
.)It's not really semantics, though. From a comment you added right below this:
TODO: 2.3: Use the below NOSPAWNNULL define instead. P_SpawnMobj used to say "if MT_NULL, use MT_RAY instead", so the above define maintains Lua script compatibility until v2.3
That, to me, sounds like
MT_NULL
is now obsolete and shouldn't be used. We already warn in cases where scripts useP_TeleportMove
in favor ofP_*Origin
, so why not do that here too? If we don't warn, script writers won't be able to prepare for a breaking change we've planned for in 2.3, which can lead to unexpected breakage to some script writers once 2.3 is released.I agree. Trying to spawn an invalid object is very distinctly a script error, and it should be treated as such.
I reported the Silver crash because Lua causing crashes is always a flaw. It ended up just being a genuine regression, but if it was due to bad Lua, then that should've also been changed to error.
changed this line in version 2 of the diff
@ Hanicef - [...] We already warn in cases where scripts use
P_TeleportMove
in favor ofP_*Origin
, so why not do that here too? [...]Funnily enough, I considered bringing that up in my previous comment. There's a difference between changing
P_TeleportMove
toP_MoveOrigin
and changing it toP_SnapOrigin
(i.e. it's not just semantic), and SRB2 can't automatically tell what the Lua scripter originally intended.I'd be happy to add a Lua warning here too, but I'd like to hear STJr's opinion first - and with LJ Sonic giving a thumbs-up and Sal commenting, I've heard their opinion now.
added Changed behavior Lua labels
added Regression label
changed milestone to %2.2.14
added 294 commits
-
bdeec562...d4053057 - 293 commits from branch
STJr:next
- 7f68a727 - Merge branch SRB2:next into substitute-null-with-ray
-
bdeec562...d4053057 - 293 commits from branch
mentioned in commit add091ba