dMZX Forums: Subroutine Versions of Built-In Labels -> Archived Requests -> Tracker

A perennial feature request. It has been suggested that MZX gain subroutine versions of the built-in labels, e.g. : "#touch".

I doubt this would be particularly difficult to add. How does the game know which one to send the robot to, though? Does it try both regardless?

Updating status to: Approved
Updating severity to: 2 - Fair
Updating version to: 2.84


This will require a version lock, so if I don't get it into 2.84, it will be pushed off until 2.85.

I'd personally assign precedence to any subroutine versions of a label, and have it fall back to normals if the subroutine versions do not exist. We already handle justentered/justloaded in a somewhat similar fashion.

Updating version to: 2.84


Which ones should/shouldn't get it? *s are the ones I see as mandatory.

*TOUCH
*BOMBED
INVINCO (all)
PUSHED
*PLAYERSHOT/SHOT
*NEUTRALSHOT/SHOT
*ENEMYSHOT/SHOT
*PLAYERHIT (all)
*LAZER
*SPITFIRE
JUSTLOADED (all)
JUSTENTERED (all)
GOOPTOUCHED (all) (seriously??????)
*PLAYERHURT (all)

Yeah, you might have noticed EDGE and THUD aren't a part of this list. I'll hunt them down shortly.

edit: Found EDGE and THUD, they're in run_robot.c. KEYn is in game.c.

Updating status to: Implemented
Issue fixed in: 2.84


Implemented for everything besides those stupid sensor labels. I'd deprecate those things (along with signs and scrolls) and remove them from the F10 menu if it wouldn't alienate literally half of MZX's current userbase. One issue I forsee is the fact that in conjunction with the default labels and subroutine versions, these aren't going to be very "smart" and probably make the stack a mess. Before I commit this I want to know two things for certain:

Which should be excluded (see above)?
How should this behave when, for example, SHOT and #SHOT are both present? Currently it sends both, which will be a stack mess in the making if used improperly. I wouldn't mind making it "one or the other" and giving subroutines precedence.

Oh yeah, before I forget, selective sending like that isn't possible for the ones marked (all). For consistency it's probably better to just have it send both and then leave a note in the changelog and helpfile about it.

The biggest reason for subroutine call versions of built-in labels is that it is extremely difficult to keep track of the stack with built-in labels. Face value, #justloaded and #justentered don't improve the situation.

For example, a common justification for using justentered is to reset a robot to it's default state when the board is reloaded.

Compare the hypothetical subroutine built-in label call with this standard built-in label call. Basically the same 5-6 lines of code are necessary to properly maintain the stack with all commands for both instances (with just a slightly different order).

: "mainloop"
goto "#MAIN"
goto "mainloop"
: "#justentered"
. "initialize variables"
goto "#top"

: "#MAIN"
: "l"
. "insert comment about how I stole this code from the irc"
goto "l"

: "justentered"
. "init variables"
goto "#top"
: "mainloop"
goto "#MAIN"
goto "mainloop"

: "#MAIN"
: "l"
. "insert comment about how I stole this code from the irc"
goto "l"

Furthermore, I can't think of any instance where you would want justentered or justloaded to be called within a subroutine either.

So, unless #justloaded/#justentered were to reset the stack, I don't think they're worth it.

The problem here is that you're trying to get #justentered to go to the start of the code, which is completely useless and you should obviously be using "justentered" for anyway. The real use of something like #justloaded would be:

: "l"
cycle 1
. "do something complex here that could have multiple waits"
goto "l"

: "#JUSTLOADED"
if "gameInitialized" = 0 "#init"
. "fade in or whatever, loading music, reset local counters, SOMETHING that needs to be done every time you load"
goto "#RETURN"

: "#init"
set "gameInitialized" 1
goto "#RETURN"

I don't see this getting used a whole lot though and the idea of having subroutine versions of justloaded/entered makes me kinda queasy just at the thought of someone trying what was in your first example (which I originally wrote because you specifically wanted to go to the start of the code on #justentered).

Final exclusions: JUST*, SENSOR*. Sensors are archaic and the just- labels could cause confusion and stack issues. The documentation should also reflect that things like #SHOT and #TOUCH should be used in conjunction with LOCKSELF or ZAP to prevent multiple triggers from stacking up.

master -- f6e324d
2.84 ---- c019571

Moving to: Archived Requests