I'm not sure, but...
I was playing IC2004, by Ian Cunnings (Map01), this pure jewel, this awesome masterpiece, and didn't find any way to end it.
So I looked at it with Doombuilder and discovered that 4 pillars should have been lowered after the cyberdemon's death.
The dehacked file was containing:
[CODEPTR]
Frame 700 = KeenDie
I must add that I didn't see it firstly when I included another dehacked entry for the name of the levels of the IC's Series.
Conclusion:
1) The fact to have 2 dehacked entries can have a bad effect on the CODEPTR value? Thus, the level was correctly named, so MY dehacked values were used.
2) GZDoom v1.0.10 is not fully compatible with Zdoom, at least for this part of the code and the use of the tag 666.
[CODEPTR]
Moderator: Graf Zahl
- Jive
- Posts: 340
- Joined: Sat Mar 11, 2006 23:44
- Location: Manaus (Amazonia)
- Contact:
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
- Jive
- Posts: 340
- Joined: Sat Mar 11, 2006 23:44
- Location: Manaus (Amazonia)
- Contact:
Ok, but Ian advise us that his pwad is zdoom compatible:
May Not Run With... : Non Boom compatible sourceports, and any
sourceport that hasn't increased the SEG
limit. Requires ports that spawn Voodoo Dolls
and can read embedded dehacked files. Tested and
works fine in ZDoom 2.0.63a and PRBoom 2.2.6
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
- Jive
- Posts: 340
- Joined: Sat Mar 11, 2006 23:44
- Location: Manaus (Amazonia)
- Contact:
you're right: I came back here to tell you that the dehacked patch was efficient, once integrated within the other one, so that there is no more 2 but 1 entry for dehacked.
Strangely, the entry made by Ian was using "Doom version = 19" and mine "Doom version = 21". So, I guess that the latest version (mine) was choosen by GZDoom to be the one to use, which was preventing the other one to be used. Or, like Zdoom, the GZDoom engine don't worry about this entry?
If yes, why the second entry was used and not the first one?!?
I guess that it's because of the rule "The last entry crush the other ones".
Resume: only ONE dehacked entry!!!
Strangely, the entry made by Ian was using "Doom version = 19" and mine "Doom version = 21". So, I guess that the latest version (mine) was choosen by GZDoom to be the one to use, which was preventing the other one to be used. Or, like Zdoom, the GZDoom engine don't worry about this entry?
If yes, why the second entry was used and not the first one?!?
I guess that it's because of the rule "The last entry crush the other ones".
Resume: only ONE dehacked entry!!!
Last edited by Jive on Mon May 22, 2006 23:42, edited 1 time in total.
- Jive
- Posts: 340
- Joined: Sat Mar 11, 2006 23:44
- Location: Manaus (Amazonia)
- Contact:
Special Monster Death Effects available for extended dehacked files (bex files):
KeenDie
Type: Monster death / "Magic" codepointer, normal
Purpose: The Fall codepointer will be called on the object. It will then check the level to see if all objects of the type which called this pointer are dead. If so, all sectors tagged 666 will be opened as normal, stay-open doors.
Notes: This "magic" pointer works on all maps and with any type of monster.
So, the way the code was written by Ian is fine.
Other explanations here
KeenDie
Type: Monster death / "Magic" codepointer, normal
Purpose: The Fall codepointer will be called on the object. It will then check the level to see if all objects of the type which called this pointer are dead. If so, all sectors tagged 666 will be opened as normal, stay-open doors.
Notes: This "magic" pointer works on all maps and with any type of monster.
So, the way the code was written by Ian is fine.
Other explanations here