Named scripts

[printz]

Will there be named tags (or ids, in UDMF lingo) some day?

[FDARI]

Oh, scripts are named that way? I thought they're supposed to look like identifiers.

Nope. People already use #define to give scripts symbolic names, so they have to be strings, or all the people who had #defined names for their scripts will have their scripts break if they compile them with the new ACC.

Well that's a real bummer. It's like getting the beautiful woman back to the hotel and finding she's a ladyboy

More like finding out she had chicken for dinner, or perhaps that she uses glasses when reading books. (Trivial.)

#define IDENTIFIER "string" will add a string to the compiled lump. However, the runtime-value of that string is not available to the compiler. In my experience, the identifier will resolve to 0. It might just possibly resolve to an index that is valid at compile-time but not necessarily at run-time. (Particularly it is nearly inconceivable that you should get a correct result if your script is loaded as a global library.)

#define in ACS/ACC does not create preprocessor-macros (text substitution), it adds named constants to resolve expressions at compile-time. If the compiler cannot complete the calculation without info from a running game, it will fail or give an unreliable result.

[printz]

#define in ACS/ACC does not create preprocessor-macros (text substitution), it adds named constants to resolve expressions at compile-time.

That's just bad.

[MartinHowe]

You honestly can't have two quote marks in the script definition? I completely fail to see what the big deal is.

Because in c-like computer programming languages, subroutines and similar things must be identified by, er, identifiers... ON PRINCIPLE. That's why they're called identifiers Principles are a "big deal" for a reason - they reduce the chance of something screwing up further down the line. IME, when one departs from principle, one opens the door to walking on patchy ground. Although to be fair, the code in the Doom engine has been mired in patchy ground since day one.

So yes it isn't the end of the world, and it's sure better than having to use just numbers; but it would have been nice to have proper script identifiers at last.

[printz]

ACS is not exactly C, it's ACS. So far, scripts have always been identified by constants (numbers), not by programming language identifiers. So the natural extension is to let those constants be strings too. It's less natural to let them have programming identifiers, because it would create ambiguity between aliases given to constants and direct identifiers.

It's functions which get their names, not scripts. Scripts need to easily communicate with the map, and that's done by numbers or text. Traditional identifiers have unwanted limitations, such as no spaces or unusual symbols. Strings not. And they need to be enclosed in quotes in the program if they can have spaces and such.

As for my previous statement about #define and later saying that "ACS is not exactly C", let's just say that the part about script string names is less fixable than the part about not being able to use macros, but them becoming constants.

[Nash]

I still don't see what MartinHowe is going on about. Using identifiers for ACS scripts have been around forever.

Code: Select all

#define MYSCRIPT 1

script MYSCRIPT
{
	// bla bla bla
}

[printz]

I still don't see what MartinHowe is going on about. Using identifiers for ACS scripts have been around forever.

Code: Select all

#define MYSCRIPT 1

script MYSCRIPT
{
	// bla bla bla
}

That is not even very useful, because from the map you still had to remember and use only numbers.

[Nash]

You never had access to strings for line special arguments in mapping anyway (well, at least before there was UDMF)

In ACS and DECORATE however, using identifiers (before named scripts were introduced) worked flawlessly though.

DECORATE

Code: Select all

const int MYSCRIPT = 1;

Actor Heh
{
	states
	{
		Spawn:
			TNT1 AA 1 ACS_Execute(MYSCRIPT, 0)
	}
}

But nobody cares about this anymore. We have named scripts now which

1) Minimizes (eliminates) script clashing between mods... very useful for gameplay/weapon mods
2) Naming scripts improves code readability... especially in complex ACS-DECORATE setups

[Graf Zahl]

You honestly can't have two quote marks in the script definition? I completely fail to see what the big deal is.

Because in c-like computer programming languages, subroutines and similar things must be identified by, er, identifiers... ON PRINCIPLE. That's why they're called identifiers Principles are a "big deal" for a reason - they reduce the chance of something screwing up further down the line. IME, when one departs from principle, one opens the door to walking on patchy ground. Although to be fair, the code in the Doom engine has been mired in patchy ground since day one.

Sorry, but you got this completely wrong. Any time a language has an external interface, identifiers become utterly useless because outside the language they have no meaning.

There's 2 ways to work around this:

1. Use a string representation of the identifier as its external representation. This is like dynamically loaded Windows DLLs work.
2. Allow specifying the external representation in a flexible way as a defined data type. Whether it's an integer or a string doesn't really matter.

But as has been said before, in this case identifiers wouldn't have worked - and they wouldn't have made much sense.

[Blue Shadow]

Sorry for the bump but there is something I'd like to know.

It is known that scripts with higher numbers execute before those with lower numbers, i.e, two Enter scripts, one is 500 and the other is 600. Script #600 will execute before script #500 at load time. That's for numbered scripts. However, how is this handled when it comes to named scripts? What is the factor that determines what named script to execute first before the other?

[Gez]

The names are converted into hashes, which are numbers. So I guess the same rule applies. Except it's not trivial to guess the order from the name.

My general protip would be to try not to make scripts that are utterly dependent on the order of execution.

[Zippy]

My general protip would be to try not to make scripts that are utterly dependent on the order of execution.

Indeed. Have scripts be discrete operations. If you have two operations that depend on order, then they should probably be in the same script to guarantee their order.

[Jekyll Grim Payne]

I have this weird problem. I try to compile SCRIPTS with named scripts in SLADE, and it works fine as long as there is at least one of them (doesn't matter which one) not-named (i.e. numbered) script (I have 6 scripts in the lump). If I try to make them all named, the compiler gives an error ("Script number must be between 1 and 999") referring to the first script in the lump. Can I work around it somehow?

UPD:
Sorry, outdated ACC. Silly me.