ZDoom Wiki Thread

[GrayFace]

https://zdoom.org/wiki/A_Warp
Wrong description for WARPF_BOB. It only accounts for bobbing of the warp-to actor. If the warped actor's has FLOATBOB flag, not only is bobbing phase unchanged, but it won't even appear in the correct position at the frame on which A_Warp is called, because A_Warp fully ignores its own bobbing.

[Redneckerz]

P.S. I'd like to have a Wiki account to change things directly.

ask Rachael and/or Gez.

[GrayFace]

https://zdoom.org/wiki/ZScript_actor_flags
> The only flags which cannot be changed this way are NOSECTOR and NOBLOCKMAP
Also COUNT* flags must be changed using A_ChangeCountFlags to update counts on the level.

https://zdoom.org/wiki/A_SpawnParticleEx
size is the diagonal size of the particle, so you must multiply the desired size of the side of the square by sqrt(2).
Due to a bug (I assume) particle textures appear rotated by 180 degrees, you need to set startroll to 180 and specify SPF_ROLL to counteract this.

P.S. I'd like to have a Wiki account to change things directly.

ask Rachael and/or Gez.

Do you have a link to an account of one of them? Forum lacks search field in member list. I wrote to Jekyll Grim Payne, he's the only one of them in admins list, but the message is still in Outbox, which probably means he didn't read it.
[edit] Nevermind, found them, thanks

[Kovnikel]

https://zdoom.org/wiki/Functions
"You can place functions anywhere in your script file."
Is this accurate? You can't place functions inside numbered scripts - unless I'm doing something wrong.

[Enjay]

I notice on the Wiki page for the spotlight class ( https://zdoom.org/wiki/Classes:SpotLight ) that it says:

"This class doesn't define any unique properties, flags or fields; they are all contained in the DynamicLight class."

and on checking the DynamicLight page ( https://zdoom.org/wiki/Classes:DynamicLight ) it does have an explanation of some of the arguments for the spotlights.

However, one important thing is missing. The arguments for spotlights are different to most dynamic lights. Importantly color. Instead of being R,G,B,Intesity,[Intensity] like most lights, the spotlights' arguments are color, inner angle, outerangle, intensity, [intensity]. The angles thing is kind of covered, but I don't think either page explicitly/clearly states that these are the second and third arguments; it just says that the arguments exist. As far as I can see, there is no mention at all about the color argument (arg0).

Also, the format for the color argument is different to most uses of color in GZDoom. Instead of being three 0-255 R,G,B values, I *think* the spotlights take a single decimal number for color on arg0. Presumably this is because there aren't enough arguments available to do the usual RGB format because two arguments are taken up defining the angle.

So, anyway, as far as I can tell, the color argument is a decimal equivalent of the hex value of a color. e.g. White - R255, G255, B255 is FFFFFF in hex and that is 16777215 in decimal. I only figured/guessed that's how it works from finding a map where someone had used a spotlight and the color value was 16777215 and I asked Google to convert that to hex and got FFFFFF.

As you can tell from the above, I'm not fully confident in this information, and I'm also not sure which page would be best to add it to, or which section of whichever page would be best. But, the information doesn't seem to be there at the moment (or I can't find it) and it probably should be for anyone wanting to figure out how these lights work.

Is anyone able to make the appropriate changes?
Thanks.

[Enjay]

An observation about ZScript versus DECORATE code definitions for actors on the Wiki.

I have noticed that when a Wiki page for an actor has DECORATE code it is often more useful, in some ways, than when a page has ZScript code.

DECORATE code is usually presented in a way that provides hot-links to various elements such as any other actors mentioned in the code, code pointers and flags. e.g. if the DECORATE code has some actor flags, clicking on them will link to the appropriate entry on the Actor Flags wiki page.

ZScript code usually (but not always) uses cs Syntax highlighting which makes the code look pretty, but it means that it can't contain links to other actors, flags or pointers because starting the definition with <syntaxhighlight lang="cs"> means that the code for the various internal links get displayed as the codes, rather than converting them into a link.

So, when you are looking at a DECORATE actor, you might come across a code pointer and think to yourself "I wonder what this does." You can then click on the code pointer and get taken to the appropriate page to read about it. With ZSCript, you have to go to the appropriate page "manually" e.g. by entering the code pointer name into the search box and finding the page.

Also, the fact that there are links in the DECORATE code tells you that there is a page to go to. In the ZScript code, these things are mostly just presented as black text. So, you don't have a quick visual prompt that says "there is a page about this if you want it." Anything may, or may not, have a page. So, you have to search hoping that the page exists.

I realise that the syntax highlighting can be useful - especially when the actor definition contains some quite complex ZScript as part of it. However, most of the default actors are pretty simple and having a bunch of links that take you to the various elements of their code is often more useful than having a couple of words highlighted in green or blue.

As a very simple example, take the RealGibs actor. It has a very simple definition, but nothing is clickable in the ZSCript code. So, if you did want to find out what the DROPOFF flag does, you'd have to go to the actor flags page manually and look for it. Scroll down to the DECORATE definition and all of the flags can be clicked on and they will take you straight to the appropriate entry on the actor flags page.

Of course, the ZScript for some actors hasn't been listed using the syntax highlighting. e.g. the ZombieMan. On that page, neither the DECORATE not the ZScript actor use cs Syntax highlighting, and both contain embedded links. So, things haven't been applied consistently anyway.

Is there any way that this could be improved on so that ZScript code can have both nice highlighting and embedded links? Or, if they are mutually exclusive, could further consideration be given to what is the best way to display ZScript actors because I personally feel that the highlighting comes at quite a high functionality cost. Given that pages may, or may not, use syntax highlighting, I'm not actually sure what the current overall policy is anyway.

[Enjay]

Another thing to do with formatting that I just happened to notice. It's exemplified on the A_SpawnParticleEx page.

On that page there an example actor for how to set up a particle generator. The text describing the generator, and most of the code itself says that it will produce a particle that rolls (randomly either left or right). However, there is a problem with the code as it is viewed on the page. In order for a particle to roll, A_SpawnParticleEx should be given the SPF_ROLL flag. The code, apparently, doesn't have this flag. It reads:

Code: Select all

flags: SPF_FULLBRIGHT,

So, if someone copies it and uses it, they get a non-rolling particle and, possibly, some confusion.

I was going to fix the entry but when I hit Edit: I was surprised to find that the relevant line of code in the editor said this:

Code: Select all

flags: {{const|SPF_FULLBRIGHT|SPF_RELATIVE|SPF_ROLL}},

So, not only is the SPF_ROLL flag there, the SPF_RELATIVE flag is too. I'm guessing that something about the "|" character that is used to separate flags is causing a problem with displaying all of the flags in the normal page view?

[phantombeta]

Yeah, that's wrong. | is used to specify/separate parameters in MediaWiki templates, so you can't just use it like that. The wiki has templates for | and || as "!" and "!!" respectively, so you'd put in a | by writing {{!}} and || by writing {{!!}}. Like so: flags: {{const|SPF_FULLBRIGHT{{!}}SPF_RELATIVE{{!}}SPF_ROLL}},

IMO the |s shouldn't be colourized with the constant names anyway, so I'd personally just separate it as flags: {{const|SPF_FULLBRIGHT}}|{{const|SPF_RELATIVE}}|{{const|SPF_ROLL}},

[Enjay]

Good to know, thanks (and I agree about colouring the "|"). Page edited with your suggestion.