ZDoom

Found a bug with "String" style named scripts, this is what happens or how you can reproduce it:

• Open a UDMF map
• Mark a line that has the line special 80 and the "String" box checked
• Mark a second line without a special or the "String" box checked
• Open the "Edit" dialogue, check/uncheck any flag in the editing dialogue and hit "Ok"
• Edit the line with the line special 80 again, the "String" is unchecked and the script name has switched to "Script number 0"

Hello, sorry if this is the wrong thread.
I have this shootable switch and marked it as "On projectile impact" and "switch height check" (UDMF format). But if you shoot below it, it still activates. Is there a way to correct this?

I haven't been able to update since R2994, why is that?

Pedro vc wrote:Hello, sorry if this is the wrong thread.
I have this shootable switch and marked it as "On projectile impact" and "switch height check" (UDMF format). But if you shoot below it, it still activates. Is there a way to correct this?

At the moment, the height check applies only to "player use" switches.

The workaround is to make a shoootable object behind your switch, but it would be a good idea to make a feature suggestion for implementing height check for impact switches, because you're not the first person with that problem.

(And yes the editor thread isn't the appropriate place for this.)

Gez wrote:

Pedro vc wrote:Hello, sorry if this is the wrong thread.
I have this shootable switch and marked it as "On projectile impact" and "switch height check" (UDMF format). But if you shoot below it, it still activates. Is there a way to correct this?

At the moment, the height check applies only to "player use" switches.

The workaround is to make a shoootable object behind your switch, but it would be a good idea to make a feature suggestion for implementing height check for impact switches, because you're not the first person with that problem.

(And yes the editor thread isn't the appropriate place for this.)

Ok then. Thanks

Pedro vc wrote:

Gez wrote:

Pedro vc wrote:Hello, sorry if this is the wrong thread.
I have this shootable switch and marked it as "On projectile impact" and "switch height check" (UDMF format). But if you shoot below it, it still activates. Is there a way to correct this?

At the moment, the height check applies only to "player use" switches.

The workaround is to make a shoootable object behind your switch, but it would be a good idea to make a feature suggestion for implementing height check for impact switches, because you're not the first person with that problem.

(And yes the editor thread isn't the appropriate place for this.)

Ok then. Thanks

Pedro, I'd make a small sector in front of the switch, use ThingCountSector to check when there is at least on puff one that sector, and GetActorZ to check if said puff is at the correct height. The switch itself would be only "decorative", as the real trigger would be the script that constantly checks the presence of puffs at he sector.

Ok guys I really need help on that nothing appear in GZDB-BugFix and since that seem work for some people I would like to know how to fix that for me!

• I use the last GZDoom build
• GZDoom.pk3 for ressource

• Code: Select all

  DoomEdNums
  {
      13000 = Whatever
  }

• Code: Select all

  Default
  {
      //$Title Whatever
      //$Category Test/Whatever
      //$Sprite TESTA0
      //$Color 17
  }

EDIT:
FIXED!!!

I can't seem to update through the program or through running the updater. I also overwrote the updater with the newest from here and still nothing, why? It can't seem to be able to connect.
https://devbuilds.drdteam.org/doombuilder2-gzdb/

I mean, I could update manually but ... why isn't it working?

GENTEK wrote:Ok guys I really need help on that nothing appear in GZDB-BugFix and since that seem work for some people I would like to know how to fix that for me!

Full code please (i.e. a minimal pk3 with this code, that has the bug reproduced).
Also: are there any errors in GZDB?

VGA wrote:I can't seem to update through the program or through running the updater. I also overwrote the updater with the newest from here and still nothing, why? It can't seem to be able to connect.
https://devbuilds.drdteam.org/doombuilder2-gzdb/

I mean, I could update manually but ... why isn't it working?

It might be blocking certain useragents. Then again, I have no idea why it breaks, can be any other reason. Seems to work for me now.

Same problem, was working in the past:

Worked before 2.3.0.2994

Seems that GZDoom Builder Bugfix has a problem if you try to tag resources in one resource, that are inheriting off another resource, regardless of whether you're loading both of these or not.

I went and started working on a custom map pack for Hideous Destructor. The mod utterly lacks Doom Ed Nums, so I used decorate stubs to add the numbers to the classes, figuring that would be clever. However, not only does GZDB-B throw an error, failing to find the inheriting classes, it also fails to find the sprites from Hideous Destructor I was using to make tag sprites, and therefore renders the things as mystery spheres instead of the sprites that are very much clearly there, in the Hideous Destructor resource files. Unsure what to do to fix this, other than shoving redundant code in.....

File attatched. Load order is Doom 2.wad, GZDoom.pk3, Hideous Destructor and Desperate Halberd pk3, in the Editor.

http://www.mediafire.com/file/tc4wa3b0t ... alberd.zip

Feature request: add this new MODELDEF flag into GZDB: [ https://github.com/coelckers/gzdoom/pull/429/files ]. Never knew how much I needed this for decorative objects until this got added! Rotating models around the "feet" is annoying...

Hi, would it be possible to add an editor key to not list an actor in GZdoombuilder's decorate list when added? I do not use Doom 2 monsters in my mod for example and would like to fully get rid of them without having to configure my own gzdoombuilder configuration. Replacing them in any way still makes them exist, and will fill up the list either way.

I believe GZDB-BF has a full MAPINFO parser, so if you redefine the corresponding [wiki=Editor number definition]doomednums[/wiki] to "None" then they should disappear I think. You can find the list of all [wiki]standard editor numbers[/wiki] on the wiki.

I hope my report about how the thing parser isn't working right for ZScripted Classes got noticed, and will be worked on. It's sort of ruining ZScripted assets for maps.