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.
ZDoom Wiki Thread
-
Redneckerz
- Spotlight Team
- Posts: 1149
- Joined: Mon Nov 25, 2019 8:54 am
- Graphics Processor: Intel (Modern GZDoom)
-
GrayFace
- Posts: 40
- Joined: Mon Feb 13, 2023 1:34 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 7 x64
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: ZDoom Wiki Thread
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.
[edit] Nevermind, found them, thanks
> 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.
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
Re: ZDoom Wiki Thread
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.
"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.
Re: ZDoom Wiki Thread
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.
"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.
Re: ZDoom Wiki Thread
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.
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.