ZDoom Wiki Thread

[Enjay]

Makes sense. In this case, however, there must already be dozens of mods using numbers with SpawnItemEx so, presumably, changing them will have an impact on quite a number of mods. I suggest that, for that particular pointer at least, it may be too late to restructure and change the numbers without having a detrimental effect on quite a bit of existing work.

[Gez]

Of course. Numbers aren't going to be changed without a good reason anyway. The point is that using numbers ought to be discouraged.

Note that, for reference purposes, you can always look up constants.txt in zdoom.pk3. Just as its name implies, it contains all constants, including flag names.

[DoomRater]

I can't believe the number of times digging around in zdoom.pk3 has saved me when I would otherwise need to look at the Wiki for info.

[Zippy]

Makes sense. In this case, however, there must already be dozens of mods using numbers with SpawnItemEx so, presumably, changing them will have an impact on quite a number of mods. I suggest that, for that particular pointer at least, it may be too late to restructure and change the numbers without having a detrimental effect on quite a bit of existing work.

Of course. Numbers aren't going to be changed without a good reason anyway. The point is that using numbers ought to be discouraged.

Exactly. Note that if things had gone well with using the flag names we would be in a better position to change values if it was ever needed. Fortunately it's unlikely to ever to be needed, so on that level it's more of a principle thing. Still should encourage the good practice of using the flag names though.

[Enjay]

I bet that if it had been known that names were better than numbers, and the initial announcement of such features and so on had also stressed the flag names over the numbers then I suspect that most modders would have used them. As it was, in many cases, the numbers seemed to be the obvious way to go for people who didn't know any better (myself included). Indeed, there are many threads on these boards where people say things like "just use flag 32" etc. This isn't a criticism of those who did know that flag names were better either. It's just the way it is. Aside from anything else, if you do know about such things, its easy to forget that others don't.

Further confusion, of course, arises with some line types having some arguments that are flags (eg the 3D floor line type). In that case the numbers have to be used because you can't put a flag name on a line. In fact, I don't think that there are flag names for that particular line type (IIRC it can't be set in a script).

[DoomRater]

I just hated the idea of not knowing what the value of the flag was.

Unfrotunately yes, it does result in easier to maintain code when names are used. It's funny, I was just going over that in my Software Evolution book a few days ago.

[HotWax]

Note that if things had gone well with using the flag names we would be in a better position to change values if it was ever needed.

What makes you say that? The "nice names" of these flags are dropped on the very first pass the ACC compiler makes to your code, and replaced with the numbers defined in zdefs.acs. Changing the value of even one of those flags would have a detrimental effect on every previously-released WAD out there whether the author decided to use the flag name or not. Or did you think the names were really stored in the compiled code?

Forcing users to use the names for readability is ridiculous, and akin to coding the ACC compiler to enforce a certain style of coding. While it's always good practice to produce readable code, trying to force that on the numerous WAD authors out there (many of whom know next to nothing about coding anyway) by hiding information is futile and only serves to make things harder on people like Enjay who need to have the reference available.

Besides all that, if you can't figure out how to translate a number back into its component flags given a wiki page that tells you what the numbers actually are, you probably shouldn't be trying to code ACS.

[Gez]

ACC compiler blah ACS.

We were talking about DECORATE. Compilation is done at run-time by the thingdef parser.

[HotWax]

We were talking about DECORATE. Compilation is done at run-time by the thingdef parser.

Some of what you were talking about was DECORATE, but not all of it.

Enjay mentioned the BLOCKF_* flags, which are not present or useful in Decorate.

[Cutmanmike]

We really need a decent example on [wiki]A_SpawnItemEx[/wiki] using flag names rather than values due to the possibility of the flag values being changed (mentioned by Randy in Gez's talk page). I can't test my examples right now and I can't remember how flags look in the function.

[Gez]

I put in one example (adapted from HPack) but more examples are needed to cover all the possibilities of that function.

[Cutmanmike]

Indeed, as there are quite a lot. I have boomerang kinda weapon on the way, I'll post that code when I get time.

[The Ultimate DooMer]

How does one edit pages such as http://zdoom.org/wiki/SetActorProperty#Actor_Properties (where there's no editable text, just what is presumably a library or source file)?

[Gez]

How does one edit pages such as http://zdoom.org/wiki/SetActorProperty#Actor_Properties (where there's no editable text, just what is presumably a library or source file)?

Uh?

Code: Select all

===Actor Properties===
{{:ACS actor properties}}

That's wiki syntax for "include the page [[ACS actor properties]] here". So you go to [wiki]ACS actor properties[/wiki]. The reason is that it's content that must be in sync on three different pages, so having all three pages include the same fourth page means that you only need to update one page, rather than three.

[DoomRater]

A_PlaySound suffers from the problem of not knowing what the numbers are, but more importantly most of the chan flags' meanings aren't obvious. What do CHAN_LISTENERZ and CHAN_MAYBE_LOCAL do? The other two I can guess what they're for.