As of Eduke32 r2097, Puritan's Unaided Mission can't be finished any more because a sliding door doesn't open correctly. Both the 2004 and 2012 versions are affected. Works in DOS Duke, the custom CONs have no effect on this issue.
Page 1 of 1
Can't finish map in EDuke32
#1 Posted 06 October 2013 - 04:46 AM
This post has been edited by LeoD: 06 October 2013 - 04:46 AM
#2 Posted 08 October 2013 - 08:52 AM
This is related to the following level 3 corruption:
(Wall 1190 is the uppermost wall of the lower door half, as seen in the editor.)
Solution: corruptcheck tryfix 2, then click on one of the wall-points of the line dividing the two door halves, forcing a red wall creation.
Quote
#2: WALL[1190].NEXTWALL=1202 already referenced from wall 1186
wall[1202].nextwall=1190, suggest clearing wall 1186's nextwall and nextsector tags to -1
wall[1202].nextwall=1190, suggest clearing wall 1186's nextwall and nextsector tags to -1
(Wall 1190 is the uppermost wall of the lower door half, as seen in the editor.)
Solution: corruptcheck tryfix 2, then click on one of the wall-points of the line dividing the two door halves, forcing a red wall creation.
#3 Posted 08 October 2013 - 09:19 AM
You overrate me. I've heard about the things you mention, but, ...well, I'll try to figure it out
#4 Posted 08 October 2013 - 09:36 AM
Well... the rant implicit in my post is that it pays off to check a map for being free from corruptions before release. Even if everything appeared to work fine in pre-r2097 (thanks for bisecting BTW), the map contains a violation of certain consistency assumptions (in this case, one-to-oneness of red wall links) which made that particular door not work any more when a fix necessary for TROR was added to dragpoint() in r2097. Of course, Puritan can't be blamed for missing it in 2004...
#5 Posted 08 October 2013 - 10:22 AM
Helixhorned, on 08 October 2013 - 09:36 AM, said:
Well... the rant implicit in my post is that it pays off to check a map for being free from corruptions before release. Even if everything appeared to work fine in pre-r2097 (thanks for bisecting BTW)
Helixhorned, on 08 October 2013 - 09:36 AM, said:
the map contains a violation of certain consistency assumptions (in this case, one-to-oneness of red wall links) which made that particular door not work any more when a fix necessary for TROR was added to dragpoint() in r2097. Of course, Puritan can't be blamed for missing it in 2004...
#6 Posted 09 October 2013 - 06:24 AM
Helixhorned, on 08 October 2013 - 08:52 AM, said:
Solution: corruptcheck tryfix 2, then click on one of the wall-points of the line dividing the two door halves, forcing a red wall creation.
#7 Posted 13 October 2013 - 07:21 AM
LeoD, on 08 October 2013 - 10:22 AM, said:
A checkout/compile script that takes the revision number as an argument is actually faster than downloading and unpacking synthesis builds btw.
Are you referring to my bisecting tutorial on the wiki? Yeah, an automated way is certainly preferred. Would you consider releasing that script? I think it might come in handy for other Windows users encountering bugs that may be regressions.
non-edit: oh, I realized you said "checkout/compile". I first thought it's a script that takes a rev number and looks for a "nearby" synthesis build. Nevermind then, I guess...
Quote
And I wouldn't exactly blame a mapper for not updating Mapster on a weekly basis.
It's not about chasing the latest revision. The corruption checking functionality can be said to have stabilized a while ago, and presently, only undergoes minor tweaks.
Quote
IIRC there once were complaints about builds that corrupted maps from earlier versions or the like.
Mapster32 builds that corrupt clean maps are clearly buggy, but when you open a map containing a corruption, the only sensible course of action is trying to get rid of it. ("Corruption" here meaning at least level 4... level 3 is a bit special because they are sometimes used for deliberate effects.) If you're mapping on a corrupt map, you're totally on your own; there's no guarantee that the editor will do anything particular you ask of it.
LeoD, on 09 October 2013 - 06:24 AM, said:
Could this type of patch be applied at map loading time (nudge, nudge)?
While it's thinkable to include the corruption checking code with the game, it's not really the game's intent to fix broken maps. Moreover, many fixes need some form of human intervention; purely automated fixing ("corruptcheck tryfix") often removes the consistecy violation, but maybe in a different way than intended by the map author.
An alternative would be to allow arbitrary (or limited) map changes from maphacks, but that's work for another sub-project.
#8 Posted 14 October 2013 - 01:10 PM
Helixhorned, on 13 October 2013 - 07:21 AM, said:
I first thought it's a script that takes a rev number and looks for a "nearby" synthesis build. Nevermind then, I guess...
Helixhorned, on 13 October 2013 - 07:21 AM, said:
An alternative would be to allow arbitrary (or limited) map changes from maphacks, but that's work for another sub-project.
#9 Posted 22 June 2014 - 04:34 AM
Thanks to both of you for this info
So basically, tons of old maps would be unplayable because of this update to the engine?
Anyway, Unaided Mission is now fixed.
Unaided Mission
So basically, tons of old maps would be unplayable because of this update to the engine?
Anyway, Unaided Mission is now fixed.
Unaided Mission
Share this topic:
Page 1 of 1