Coding conventions in the tmwAthena DSL

This section is for the reporting of bugs or any sort of issues found during testing. It is also used for the organisation of contributors in general.


Post Reply
User avatar
Ratstail91
The Mana World
The Mana World
Posts: 8
Joined: 16 Oct 2025, 21:14
Location: Australia
Contact:

Coding conventions in the tmwAthena DSL

Post by Ratstail91 »

Hello everyone!

I've been working within tmwAthena's scripts since I joined a few months ago, migrating some existing scripts into the quest log. I've noticed that there's some coding conventions that were either written before newer alternatives were added, or are simply "CONVENTION" (queue Fiddler on the Roof musical number).

I have more than a passing interest in domain-specific languages - DSLs for short - and while I haven't dived into the engine's code yet, I am curious what people's thoughts on it's capabilities and coding styles are. I know the wiki has a page about this language, but it's woefully out of date and in need of a massive facelift.

One example would be the tag "L_Close" which was often used to store the local variable within the server's database/flat file, like this:

Code: Select all

001-1,1,1,0|script|Dummy|1
{
    //using @inspector as an exampel
    set @inspector, ((QUEST_Hurnscald & NIBBLE_3_MASK) >> NIBBLE_3_SHIFT);
    mes "[Dummy]";
    mes "\"I'm a dummy, not dumb."";
    goto L_Close;
    
L_Close: set QUEST_Hurnscald, (QUEST_Hurnscald & ~(NIBBLE_3_MASK)) | (@inspector << NIBBLE_3_SHIFT); close; }

Before the quest log's ServerVar and CommonVar were added, the above seemed to be the only way to access persistent variables. Now though, quest-log.txt defines the stored variable and the useable nybble slices, so "goto L_Close" is just a wasted step.

I wonder, are there any other instances of older code or conventions that are no longer needed? Things like clear_vars.txt feels like a bad bandaid that worked at the time, but is becoming more and more unmanageable as time goes on. I feel like I'd love to write a complete up-to-date manual for this language (which is apparently called "eA script", but that name makes the "challenge everything" soundbyte play in my brain), so I wanted to ask if anyone had some input of their own.

I know Hercules has a slightly modified version of this language, so input from there would be great as well.

Couldn't hurt to at least ask, right?

Kids these days will never know what it's like to trade Pokémon over a link cable.

User avatar
Bjørn
Manasource
Manasource
Posts: 1489
Joined: 09 Dec 2004, 18:50
Location: North Rhine-Westphalia, Germany
Contact:

Re: Coding conventions in the tmwAthena DSL

Post by Bjørn »

Since I mentioned it on Discord already, I know at least we have some convenience functions which the scripts were never adjusted for:

Code: Select all

    mes "[Dummy]";
    mes "\"I'm a dummy, not dumb.\"";

Can be written like this now:

Code: Select all

    mesn;
    mesq "I'm a dummy, not dumb.";

Though personally I would like to rename "mesq" to "say" before we make serious use of that.

ThinkSome
Moubootaur Legends
Moubootaur Legends
Posts: 133
Joined: 02 Apr 2023, 16:47

Re: Coding conventions in the tmwAthena DSL

Post by ThinkSome »

Italian cuisine is now UNESCO protected immaterial heritage and as such these spaghetti must stay.

Jokes aside, I say: clean it up while migrating. Your example probably trims the code that was between goto and L_Close:, but I've already seen multiple instances of "goto LABEL;" followed by LABEL: and no other callers of LABEL. That should be cleaned on sight.

I know Hercules has a slightly modified version of this language, so input from there would be great as well.

In MLHerc (and perhaps EvolHerc and upstream Hercules as well?) quest vars are special and accessed via getq/setq. Each quest gets 4 integers and they are automatically sent to client. Hercules also has statement blocks ({}) and function argument passing, which together kill the need for most labels and global per-char temporaries. A pain point is that it still does not support (or does, and I'm not aware of it?) declaring function parameters, so that, for example

Code: Select all

function script mesq {
return "\"" + getarg(0, "") + "\"";

Would become

Code: Select all

function script mesq(.@msg$ = "") {
return "\"" + .@msg$ + "\"";

(probably with implicit .@)

Post Reply