variables go away

[quietlyquietly]

I was writing some scripts and got strange failures.

Testing revealed that the .@ variables (local scope) were losing their values when menu or input commands were used.
I am guessing that to execute menu or input, the script engine stops execution. Upon getting an answer from the client it uses a new scope to continue execution. I expect all the commands that get input from the client are going to kill all the .@ variables.

Is this a bug that needs to be fixed ?
Perhaps it is a strange feature that I do not understand ?

Just changing to using NPC or player storage is gong to be a problem, as anything created will live forever.
Such variables cannot be destroyed again (At least I have not found any way to do that).

A few of scripts do not have player invocation, nor a NPC. Those are probably the only ones that are working well because they cannot use the menu or input commands.

[Bjørn]

Your analysis seems to be exactly right. The run_script_l function which is called indirectly from for example npc_scriptcont always creates a new ScriptState st on the stack, which will not have any local variables set.

If we want such variables to stay available, they'd need to be stored somewhere else, either permanently or temporarily and then restored before continuing the script.

[quietlyquietly]

I have been debugging my script for hours and hours each day.
It has been more than once that I found out that some variable value had gone-away on me across a function call because that function asked the user a question.

This script language has many more gotcha's in it.

Here are some more:

1. Hex numbers are accepted in expressions. But if you use one in a parameter (args) to a function, it is read as 0.
2. Many operations convert using conv_int and conv_str. But some do not, and your value will not been seen.
3. The menu allows the text to be an empty string "". If the menu str is empty, that line will not be shown. See eAthena docs. BUT, if you use this then every menu line after that will not be shown either. The menu stops at the first empty str. You have to put all such lines at the end. If you have two such lines, you are out-of-luck unless they have exact same conditions.
4. If your script has to do much processing, it may take too much time. I have some menu that erratically put up a button "stop waiting", and the server log says "infiinite loop". No amount of testing will find the infinite loop. As far as I can tell, the script was stopped because it took too much time, and the menu system "stop waiting" is misleading.
5. OnInit labels work if the script function declaration with a location, but they are ignored if put into an ordinary function.
6. The function names are visible across multiple files. I have two files, one for quest and one for messages, and both had an implode function I wrote because the implode function is missing in tmwAthena. I found that the message file was using the implode funciton from the quest file, which was slightly different.
7. The callfunc and callsub do not pass arguments to the function. They had this, but it has been commented out in the tmwAthena code.
   If you have arguments to pass, you have to use the CALL( ) operation.
8. If the CALL( ) operation is used, it has trouble with the CALL return stack. Often, I have had to do this to stop the error messages.
   This scripting language does not ignore an unused return value the way C does.
   void call( ... )
9. Only functions declared using "function" can be called using callfunc.
10. If you call a function using the name that appears on a trigger point, it will crash the entire server when the function name is "not found".
    This will not be found at compile-time, it is only at run-time does it realize this and the crashing the server is entirely excessive.
    Example: 008-2,33,66,0,0|script|QuestBoard#|151
    callfunc "QuestBoard"; // this will crash the server when executed.
11. The return and end operations are unforgiving. If you have called a function and it uses an end instead of return, then the dialog is left hanging as that script is still waiting for the called function to return.
    If you are processing for an event, you better have it end.
    I had to get inventive several times when a script took calls, but also was invoked by some OnInit or other event.
    If the engine has enough information to detect this at run-time, then it has enough information to recover more gracefully.
12. The mobinfo command returns -1 when the <mobid> is not recognized. It does this even when you are fetching a name str. The -1 does not store well into a string and cannot be tested. I had to call mobinfo once storing into an int to test for the -1, and then again to store the name into a str.
    This is two database lookups of the same data.
    I have yet to discover what transform I have to use to get moningo to recognize my monster id numbers. It does not recognize any of them
    (Example 1107, // bluepar).
    There is no substitute for using mobinfo.
13. The fall-through to label restriction is extreemly annoying. Upon any code editing you can be guaranteed to have one of these be discovered.
    It means that the script is littered with all these extraneous goto, just to continue to the next line/lable.
    I do not know what it is protecting against, as falling through a label is not regarded as an ERROR by any other language. They all manage to do it perfectly fine. Makes me want a label that does not have this restriction, and I would use it almost everywhere.
    Now an event label, and a label used for a callsub would need to have this restriction. Perhaps the S_ labels are for callsub, and thus they could be restricted that way.

[Bjørn]

In general you'll find that indeed the scripting implementation as well as the implementation of many functions is quite far from being perfect. Generally, people who are writing scripts rely on testing whether everything works, also by somebody else, to avoid putting broken things live.

For sure some of these problems can be fixed, but the few people who write scripts are often busy addressing problems they're running into themselves. Hence it would be great if you'd be willing to learn how to contribute back.

[quietlyquietly]

The main question that I see, is if the manaworld community is willing to let me loose in the code, because I already see so many things that I would replace with more sensible constructs. I have been doing game coding for many years, and our programming prioritizes readability and correctness, which are nearly the same thing as you cannot see if it is correct unless you can read the code. The tmwAthena code is not readable as it is and that would be one of the first priorities. It has so many templates used where such are not needed and not contributing. What is needed is basic types were you do not have to keep 4 pages open on the editor to read and understand the usages. There are also some violations of basic conventions, like any function that is named "is_xxx" returns a boolean, not a ptr to the thing.

Do you really want to turn me loose on this code, knowing that I am going to "fix" many things that someone else thought was "neat idea" ???
Also, what do you have for community testing. Is any alteration to the GIT repository going to be in the current code, or is there some current version, and proposed versions under testing. Who does this testing ? If it is only the one guy doing the changes it is pointless. I already got a project taking up 90% of my time that is like that. They only find the bugs after it hits release, so I am constantly doing emergency bug fixing.

[ThinkSome]

Hi quietlyquietly, I can't wait to see you looose in https://git.themanaworld.org/legacy/tmw ... e_requests !!

We'll try and have someone on staff 24/7 to review and merge in your fixes. Testers are unfortunately in short supply, so you'll have to do some of this work yourself, too:(

[quietlyquietly]

I just tried to debug the mobinfo command.
EDIT: Disregard mobinfo problem, was missing a $, and eventually got it to work, somewhat.
Still don't like the implementation.

Investigated the mobinfo code.
Something seems to be hidden as a side effect of something called "wrap".
This is all over the place and I have no idea what it does.
Is there some grand service being given by this "wrap" that I don't recognize.
I am familiar with wrapping something, but have not seen it done this way before. It is unmaintainable if nobody actually knows what it does.
At least it is unreadable.
You know the original author is going to have a fit if we just have to rip it out and put in something easier to maintain.

Will consider that, I suppose I will need to got to GIT and apply or something. I never have anything but trouble with GIT repositories.

[quietlyquietly]

Yea, GIT login says that I have to get someone to get me a GIT account.

[Bjørn]

Yea, GIT login says that I have to get someone to get me a GIT account.

You can email me at bjorn@lindeijer.nl (or send forum PM) and I can create the account for you. I think all I need is your email and what you'd like to use as username.

You know the original author is going to have a fit if we just have to rip it out and put in something easier to maintain.

We don't have to worry about original authors a lot because they have largely left (or, were never part of this project since this server was originally meant to be a Ragnarok Online server emulator). However, we do try to make only necessary and small changes, because somebody else will need to review the change.

[quietlyquietly]

Email to request GIT account has been sent.

[Hello=)]

On side note you can also ask me or HoraK about TMWA internals, e.g. in game. And its really wise to read https://raw.githubusercontent.com/eathe ... mmands.txt to get idea how this supposed to work. TMWA is descendant of eAthena, slightly older version than this one describes but over time TMWA got also new features not found in this one.

[Hello=)]

As for variables destruction
1) Engine returns 0 on any unset integer variable. Setting variable to 0 is equivalent to unsetting variable. At least permanent variables stop being saved like that.
2) For strings its setting string to "" that removes it. Interestingly this fails via @setvar server command, just because command can not swallow empty arg, but it works in script code.

Per-player TEMPORARY variables (@variable) aren't such a big deal. Even if you do not clean it, it would take some bytes, but it only that many bytes - on that player. And once player logs off, all their temporary variables vanish. Some of @vars dynamically set by server on the fly, to hand over some event related data -> invoked script when server throws event (both native server code and scripts can throw NPC events).

But PERMANENT per-player or per account variables? (ones without prefix, or #variable) No, no no and no, unless you REALLY need to store persistent, per-player state and it brings some gameplay improvement. Especially if that set for each and every player. TMWA got almost 300 000 accounts, all their persistent vars are loaded to RAM. Its something to remember. This CAN eat RAM.

Per NPC variables (.variable), once set, live until server restart. Or until NPC destroyed. TMWA got some funny extension, puppet() builtin that duplicates NPC, so it inherits structure of its parent npc(tmw port to herc and ML got comparable extension). But its separate NPC - with separate set of npc vars, events, timers, sprite, location, name, etc. And destroy() call can be used to destroy NPC. When NPC destroy()'ed, its timers are cancelled, its events are no more, and all variables go away. So instatiating temporary npc, doing some things, and then destroy()ing it can be a thing. Furthermore such thing can live detached from player, e.g. some spells do that. Care should be taken to not destroy() important NPC. Its possible to issue destroy() on e.g. "template" npc or even unrelated "persistent" NPC, this would obvuiusly cause bugs. Other than that it can dub as funny way to do plenty of cleanup in one shot.