General Curiosities
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
General Curiosities
There are a handful of standing issues and curiosities that I face in my editing, as I'm sure any one of us would be able to say. Sometimes, trying to solve them doesn't yield entirely optimal answers. Either it's particularly perplexing, or a 'perfect' solution for me doesn't feasibly exist, or perhaps some of them just slip through the cracks and get forgotten for periods of time. It happens. So, for the sake of convenience, as well as to help my own sanity, I've decided I should compile a short, running list of persistent issues that continue to grab my curiosity to one extent or another. So, in no particular order (resolved issues moved down for ease of reading)...
3. Selective NOAUTOAIM -- Previously discussed here
I'd like to be able to create weapons where either Primary or Secondary fire can ignore autoaim without inhibiting the other fire mode, but the flag is universal to the weapon and cannot be changed on-the-fly.
STATUS: Presented as feature suggestion; awaiting action/response
5. Piercing bullets -- Previously discussed here
I'm looking for a way to fire bullets that can pierce through multiple enemies.
Addendum: Railguns are proving the most viable solution thus far, though the desired autoaim is absent...
6. Forcing sound channels -- Previously discussed here
I'm hoping for a way to dictate which sound channel certain sound properties play on without harming other functionality.
8. BounceType Doom projectile death -- Previously discussed here
I need to verify if a projectile with BounceType Doom is supposed to live forever if it comes to rest on a solid object without touching a plane, or if this is a bug.
13. Mouse control issues after launching -- Previously discussed here
I have occasional issues with mouse control/response in Windows/other programs after launching ZDoom, but am unable to determine the cause of the issue, so I'm looking for any reports on similar incidents to possibly help narrow down the matter.
14. Controlling the order of autoload -- Previously discussed here
I want to know if anything can be done to dictate the order in which files are loaded when using a GAMEINFO LOAD command.
16. Ignoring KEYCONF -- Previously discussed here
Maps that redefine weapon slots with KEYCONF break weapons in my project unless I do the same, which leads to other complications. I'd like to see if the engine can be adapted to ignore/override this.
1. Blanking out default playerclass soundbytes -- Previously discussed here
If a sound is defined in for the "player" soundclass ("fighter" when running Hexen), it will apply to every player class, and there is no apparent way to blank it out if it's unwanted.
STATUS: RESOLVED
2A. Friction queries #1 -- Previously discussed here
Sector_SetFriction is supposed to return friction to normal with a value of 128, but floors will still be slippery enough that players bounce off of walls and play their *grunt sound.
STATUS: RESOLVED (Thanks to Nightfall and Randi for the information)
2B. Friction queries #2 -- Previously discussed here
Features were added to adjust the falling speed threshold for a player to play their *grunt sound when landing, but I don't know if this also affects their velocity when sliding into walls.
STATS: RESOLVED (Thanks, Blue Shadow)
4. TEXTURES scaling for the player select box -- Previously discussed here
Using TEXTURES to scale a graphic will not affect how said graphic appears in the player select box. I would like to know if this is intentional or should be reported as a bug or feature suggestion.
STATUS: RESOLVED
7. Forcing DoomPlayer in cast call --Previously discussed here
I'm looking for a way to force the base DoomPlayer class to appear in the endgame cast call without using the selected playerclass' sprites and sounds.
STATUS: RESOLVED
9. Checking for "Flying" -- Previously discussed here
I would like to know if there is a property I can run a check on for when a player is "flying", or if he has pressed "stop flying" and paused his powerup -- perhaps the same property which tells the engine to stop animating the powerup's icon when the power is dormant.
STATUS: RESOLVED (Thanks, GameFreakDude!)
10. Multiple invulnerabilities conflicting -- Previously discussed here
I'm looking for a solution to avoid having invulnerability powers/set commands interrupt each other.
STATUS: RESOLVED (Thanks for the tip, Neural!)
11. Affecting ammo drops based on monsters -- Previously discussed here
I'm looking to find if there's a simple way to have items created with A_SpawnItemEx reflect/recreate the halved-ammo property that comes with being dropped by a killed monster.
STATUS: RESOLVED
12. Working with unusual MIDI formats -- Previously discussed here
I have a set of IMF files that are apparently actually some form of MIDI, but don't know how to have ZDoom recognize them, or how to convert them to a more flexible format.
STATUS: RESOLVED (Thank you, Gez!)
15. Overriding locked doors -- Previously discussed here
I'm trying to develop a clean method to create player tools that will allow for opening locks without collecting the correct keys.
STATUS: RESOLVED
17. Dynamic viewheight and attackZoffsets -- Previously discussed here and here
I need to be able to dynamically alter a player's viewheight and attackZoffset, in order to properly scale them up when playing in larger game worlds.
STATUS: RESOLVED
That's pretty much what I've got on my plate right now. As always, any input is greatly appreciated. And, just because I don't deem a suggestion to be perfect for my needs doesn't mean it's necessarily not a completely valid idea. Sometimes I find myself working in peculiarly narrow parameters, and I know full well that there isn't always a 'perfect' solution for what I'm doing.
3. Selective NOAUTOAIM -- Previously discussed here
I'd like to be able to create weapons where either Primary or Secondary fire can ignore autoaim without inhibiting the other fire mode, but the flag is universal to the weapon and cannot be changed on-the-fly.
STATUS: Presented as feature suggestion; awaiting action/response
5. Piercing bullets -- Previously discussed here
I'm looking for a way to fire bullets that can pierce through multiple enemies.
Addendum: Railguns are proving the most viable solution thus far, though the desired autoaim is absent...
6. Forcing sound channels -- Previously discussed here
I'm hoping for a way to dictate which sound channel certain sound properties play on without harming other functionality.
8. BounceType Doom projectile death -- Previously discussed here
I need to verify if a projectile with BounceType Doom is supposed to live forever if it comes to rest on a solid object without touching a plane, or if this is a bug.
13. Mouse control issues after launching -- Previously discussed here
I have occasional issues with mouse control/response in Windows/other programs after launching ZDoom, but am unable to determine the cause of the issue, so I'm looking for any reports on similar incidents to possibly help narrow down the matter.
14. Controlling the order of autoload -- Previously discussed here
I want to know if anything can be done to dictate the order in which files are loaded when using a GAMEINFO LOAD command.
16. Ignoring KEYCONF -- Previously discussed here
Maps that redefine weapon slots with KEYCONF break weapons in my project unless I do the same, which leads to other complications. I'd like to see if the engine can be adapted to ignore/override this.
1. Blanking out default playerclass soundbytes -- Previously discussed here
If a sound is defined in for the "player" soundclass ("fighter" when running Hexen), it will apply to every player class, and there is no apparent way to blank it out if it's unwanted.
STATUS: RESOLVED
2A. Friction queries #1 -- Previously discussed here
Sector_SetFriction is supposed to return friction to normal with a value of 128, but floors will still be slippery enough that players bounce off of walls and play their *grunt sound.
STATUS: RESOLVED (Thanks to Nightfall and Randi for the information)
2B. Friction queries #2 -- Previously discussed here
Features were added to adjust the falling speed threshold for a player to play their *grunt sound when landing, but I don't know if this also affects their velocity when sliding into walls.
STATS: RESOLVED (Thanks, Blue Shadow)
4. TEXTURES scaling for the player select box -- Previously discussed here
Using TEXTURES to scale a graphic will not affect how said graphic appears in the player select box. I would like to know if this is intentional or should be reported as a bug or feature suggestion.
STATUS: RESOLVED
7. Forcing DoomPlayer in cast call --Previously discussed here
I'm looking for a way to force the base DoomPlayer class to appear in the endgame cast call without using the selected playerclass' sprites and sounds.
STATUS: RESOLVED
9. Checking for "Flying" -- Previously discussed here
I would like to know if there is a property I can run a check on for when a player is "flying", or if he has pressed "stop flying" and paused his powerup -- perhaps the same property which tells the engine to stop animating the powerup's icon when the power is dormant.
STATUS: RESOLVED (Thanks, GameFreakDude!)
10. Multiple invulnerabilities conflicting -- Previously discussed here
I'm looking for a solution to avoid having invulnerability powers/set commands interrupt each other.
STATUS: RESOLVED (Thanks for the tip, Neural!)
11. Affecting ammo drops based on monsters -- Previously discussed here
I'm looking to find if there's a simple way to have items created with A_SpawnItemEx reflect/recreate the halved-ammo property that comes with being dropped by a killed monster.
STATUS: RESOLVED
12. Working with unusual MIDI formats -- Previously discussed here
I have a set of IMF files that are apparently actually some form of MIDI, but don't know how to have ZDoom recognize them, or how to convert them to a more flexible format.
STATUS: RESOLVED (Thank you, Gez!)
15. Overriding locked doors -- Previously discussed here
I'm trying to develop a clean method to create player tools that will allow for opening locks without collecting the correct keys.
STATUS: RESOLVED
17. Dynamic viewheight and attackZoffsets -- Previously discussed here and here
I need to be able to dynamically alter a player's viewheight and attackZoffset, in order to properly scale them up when playing in larger game worlds.
STATUS: RESOLVED
That's pretty much what I've got on my plate right now. As always, any input is greatly appreciated. And, just because I don't deem a suggestion to be perfect for my needs doesn't mean it's necessarily not a completely valid idea. Sometimes I find myself working in peculiarly narrow parameters, and I know full well that there isn't always a 'perfect' solution for what I'm doing.
Last edited by Ed the Bat on Tue Aug 13, 2013 12:14 am, edited 18 times in total.
- Sgt Dopey
- Posts: 558
- Joined: Thu Jan 13, 2011 8:44 pm
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Australia
Re: General Curiosities
I think you have to add +RIPPER on the projectile definitionEd the Bat wrote: 5. Piercing bullets -- Previously discussed here
I'm looking for a way to fire bullets that can pierce through multiple enemies.
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
As was mentioned in the previous discussion on that subject, I can't really use a projectile for this since those will die on any actor that isn't +SHOOTABLE, meaning the piercing bullet will fail to pierce things that a regular bullet can.
Re: General Curiosities
Re 4, 13
If you feel that a behaviour doesn't behave as expected, just post it as a bug so that it can be addressed faster. The devs don't usually read/respond to threads created here.
Whether it gets a fix or [not a bug] is another story. The point is, you reported it.
If you feel that a behaviour doesn't behave as expected, just post it as a bug so that it can be addressed faster. The devs don't usually read/respond to threads created here.
Whether it gets a fix or [not a bug] is another story. The point is, you reported it.
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
Alright, I can do that. I just honestly didn't know if these were bugs, or it'll just be this way, and I thought I should ask the community to see if anyone knew, so I don't waste the developers' time with nonsense.
Re: General Curiosities
It hardly harms them if they just decide to dismiss a thread as [not a bug]... it's not like you're going to make them lose sleep or anything like that... :P
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
I've made a bug report about #4, so now I can just relax and wait to see what happens. As for #13, I'm still hesitant, because there are so many possible variables at play, ZDoom may very well be completely innocent. Sadly, I don't really have a setup that will allow me to isolate things for testing, so it might have to be left as it is for now.
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
I reported #10, Multiple invulnerabilities conflicting, a few days ago. It was deemed [Not a bug], as it seems the SetPlayerProperty command does nothing more than give an item to the player. I've learned from this that a command such as SetPlayerProperty(1,1,PROP_INVULNERABILITY) is no longer advisable, but this does leave me in search of a new workaround for my original problem, as well as a more 'proper' replacement for that command in scripted events.
- NeuralStunner
-

- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
- Contact:
Re: General Curiosities
How about:
Code: Select all
SetActorProperty (TID, APROP_Invulnerable, True);- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
I tried that in my bugtest wad, and found the same results. This leads me to suspect that it uses the same method as SetPlayerProperty, and thus would likely not be the 'correct' way to do it.
- NeuralStunner
-

- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
- Contact:
Re: General Curiosities
That directly sets the MF2_INVULNERABLE flag, which apparently PowerInvulnerable does as well.
You could try CustomInventory items that toggle the NoDamage flag. (There's currently no generic function for changing flags through ACS.)
You could try CustomInventory items that toggle the NoDamage flag. (There's currently no generic function for changing flags through ACS.)
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
That sounds like a reasonable idea. Thanks! I'll give that a shot when I get the chance and report back on any particular findings.
EDIT: So far, so good! And unlike setting/giving Invulnerable, this method lasts between level transitions! This can be quite useful, so long as I just make sure to manually turn it off if/when necessary.
EDIT: So far, so good! And unlike setting/giving Invulnerable, this method lasts between level transitions! This can be quite useful, so long as I just make sure to manually turn it off if/when necessary.
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
Regarding #9, Check for Flying, my talented colleague GamerFreakDude helped me figure out that flight sets an actor's NOGRAVITY flag, so I can use that to check when a player is "flying" or when he's paused the flight.
Re: General Curiosities
The only way I've seen to do piercing bullets is just to spawn more than 1 simultaneously. If shot at the same time with the same angle, they should always auto-aim on the same target and should mostly look like 1, piercing bullet.Ed the Bat wrote: 5. Piercing bullets -- Previously discussed here
I'm looking for a way to fire bullets that can pierce through multiple enemies.
If you're going for bullet spreads, you can manually handle this in decorate, I guess. Not exactly clean, but doable. You can't give multiple bullets sent at the same tic a random spread, or they will separate.
The bullets will only go through as many targets as you can spawn bullets, so its not "infinite". Each bullet can also cause pain independantly, so you might need to adjust and give some of the bullets nopain through their puff (thats possible, right? or give them a different damagetype that has no pain chance).
Simple? Depends. If the monster only drops AMMO, you'll just have to create another actor under that ammotype, make it give less and make the monster drop it. Very easy, no problems.Ed the Bat wrote: 11. Affecting ammo drops based on monsters -- Previously discussed here
I'm looking to find if there's a simple way to have items created with A_SpawnItemEx reflect/recreate the halved-ammo property that comes with being dropped by a killed monster.
The issue comes when you want to make them drop WEAPONS that gives less ammo. I've been confused as all hell with that. If you create a new weapon, you can now have 2 weapons on your character which is bullocks.
You can half the ammo the weapon gives, and make it spawn through a custominventory that creates TWO of that weapon. So basically, any instance of the weapon in the map is actually 2 of them, but when picked up in ZDoom they look like 1 (and there's only 1 pickup message given). FOr enemies, you only make them drop 1. Tada, they drop half-ammo.
Kinda. The catch? Custominventory spawning means the weapons will not stay/respawn in multiplayer and such. That is up to you if its a problem.
I have no idea if my solutions are ideal, but it is how I would have done it.
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Re: General Curiosities
These will not really work for me; the bullet solution seems like it would cause more issues, particularly how bullets will not pierce things that survive them; if something tough like the Cyberdemon absorbs all of them, nothing behind him will get hit. As for the weapon drops, there's no need to create a new weapon, since weapongiver can be used to adjust how much ammo comes out of it. But that would mean every weapon I have would need yet another contingent drop, and then I'd still need to find a way to tell my scripted spawners that a monster dropped it, which is the problem in the first place. Doing what you mentioned about making two weapons spawn together would mean I might pick one up, reach full ammo, and the other one would still be there. And yes, CustomInventory is already a problem because of multiplayer stay/respawn, and the source of curiosity #6.
Still, I appreciate the time and thought you've put into these suggestions. Thank you for your input.
Still, I appreciate the time and thought you've put into these suggestions. Thank you for your input.
