GZDoom Builder 2.3

[MaxED]

1. Oh hey! You have modified your DOOM2.WAD!
2. There is a 5-letter sprite name at that line.
3 and 4. There is also a cameratexture with the same name defined in ANIMDEFS.

Incorrect models: editor sprite picker logic prefers Idle state over Spawn state, which is incorrect in this case, because the editor picks one of the first person view models as a result. To properly fix this I'll need to implement actor inheritance tracking, which I'll get to, eventually. Alternatively, a mod author can indirectly assign a model using "//$Sprite" DECORATE comment.

[GENTEK]

Code: Select all

Model "TEST" // Remove the quotes. Those are not required and are no longer automatically stripped by GZDB.     

When you say... the quotes are no longer stripped by GZDB... all my actors name have quotes do you talk only about MODELDEF or about all in PK3!

[MaxED]

[GENTEK]

EDIT: Oh OK! Thanks Nash!

[Nash]

It's not about it being useful or not... you have to follow the specifications made by the programmers of ZDoom. Nothing in the documentation says that DECORATE actor names must be defined with quotes.

And actually, using quotes wrongly (putting them where they should not be, and vice versa) has been known to actually cause problems and errors several times in the past.

[Kappes Buur]

A lesson to all

1. Oh hey! You have modified your DOOM2.WAD!

My first reaction was .... WHAT THE .....??
After I calmed down a bit I went on a hash hunt.

From http://doomwiki.org/wiki/DOOM2.WAD I found that the correct MD5 hash is 25e1459ca71d321525f84628f45ca8cd. Then I checked all the occurrences of DOOM2.wad on my harddrive with the hash generator on http://onlinemd5.com , and they all came to MD5 AB204E6566D3EADC26D9BC336BD971CA. So, I must have been using a modified DOOM2.wad for years. How that could have happened, and when, will remain a mystery forever.

Anyways, I then checked on some older hardrives from storage and I found in a directory for Deth 4.24 a DOOM2.wad which hashed to 25E1459CA71D321525F84628F45CA8CD. I tried that, and indeed, error no 1 disappeeared.

[edit]

Not contend with leaving this just generating different hashes, I needed to know what the real difference is.
Turns out that the culprit is where the name D_RUNNIN is located

---

[Zanieon]

Okay i brainstormed a bit with this new model parser but managed to fix the Editor Resource to work with this new referencer, however i removed all the icons i put before because i'm lazy to go trough all the 60 actors and rename each sprite in MODELDEF just to get the old behavior, so everything became NADAA0.

[Gez]

Not contend with leaving this just generating different hashes, I needed to know what the real difference is.
Turns out that the culprit is where the name D_RUNNIN is located

---

You wouldn't be getting an error message about patch SW18_7 were that the only difference. Here you're looking at the wad directory. For reference, in the unmodified doom2.wad, D_RUNNIN is at index position 496; GZDB complains about something at index position 2357 -- quite a bit farther behind.

[Tormentor667]

Fixed. Optimized.

Perfect, thanks alot

[Kappes Buur]

You wouldn't be getting an error message about patch SW18_7 were that the only difference. Here you're looking at the wad directory. For reference, in the unmodified doom2.wad, D_RUNNIN is at index position 496; GZDB complains about something at index position 2357 -- quite a bit farther behind.

It's strange, both files, the one with hash MD5 AB204E6566D3EADC26D9BC336BD971CA and the one with hash MD5 25E1459CA71D321525F84628F45CA8CD, are the same size, 14,604,584 Bytes. The only difference which I can detect is the location of D_RUNNIN. Either ahead of or behind of D_STALKS.

Having mucked about with this for some hours, I remembered that Martin also had an occurence of SW18_7 popping up as double defined.
http://forum.zdoom.org/viewtopic.php?f= ... 55#p892228
which makes me wonder if the hashed MD5 AB204E6566D3EADC26D9BC336BD971CA is an official iwad after all. But then, this was to have been fixed according to this
http://forum.zdoom.org/viewtopic.php?f= ... 70#p893227
I wonder what the MD5 hash is for Martin's IWAD.

So, I don't know, I haven't the tools nor the wherewithal to investigate this any further. I guess, I just keep on using the hashed 25E1459CA71D321525F84628F45CA8CD file, which does not give the double defined error for SW18_7.

If you want to play around with the offending file, then let me know and I PM you the location from where to download it.

[Tormentor667]

Fixed. Optimized.

Perfect, thanks alot

Ah, not completely fixed: Flood fill textures suffers the same problem...

[MaxED]

...So, I don't know....

Uuuugh... Storytime!
Both official versions of Doom.wad and Doom2.wad have a duplicate SW18_7 patch.
So the editor warning about it started appearing for all users when any Doom/Doom2 game configuration was used after I added duplicate patch checking logic to GZDB.
Shortly after that I've also added MD5 hash-based official IWAD check to prevent the editor from saving them and also to allow saving user IWADs as IWADs (previously GZDB saved any wad file as PWAD).
In addition to that I've also disabled the duplicate patch checking logic for official IWADs, because now I had the means of detecting them and there are no good means of fixing the IWADs without, well, modifying them (which is never a good idea).

And that's how I found out you are using a modified Doom2.wad

[MaxED]

Flood fill textures suffers the same problem...

Fixed.

[Tormentor667]

Thanks again

[Overwatch-C-17]

Hi max
One very little problem.. I choose a script from a dropdown in a ([80: Script Execute] Dialog) then a label (Script Number) at the left side of the dropdown script chooser appearing a colon. If I write 0 at the dropdown the colon disappear.