Duke4.net Forums: Can't finish map in EDuke32 - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Can't finish map in EDuke32

User is offline   LeoD 

  • Duke4.net topic/3513

#1

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.

Attached thumbnail(s)

  • Attached Image: UNAIDED-r2097.jpg


This post has been edited by LeoD: 06 October 2013 - 04:46 AM

1

User is offline   Helixhorned 

  • EDuke32 Developer

#2

This is related to the following level 3 corruption:

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 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.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#3

You overrate me. I've heard about the things you mention, but, ...well, I'll try to figure it out :P
0

User is offline   Helixhorned 

  • EDuke32 Developer

#4

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...
0

User is offline   LeoD 

  • Duke4.net topic/3513

#5

View PostHelixhorned, 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)
A checkout/compile script that takes the revision number as an argument is actually faster than downloading and unpacking synthesis builds btw.

View PostHelixhorned, 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...
And I wouldn't exactly blame a mapper for not updating Mapster on a weekly basis. IIRC there once were complaints about builds that corrupted maps from earlier versions or the like.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#6

View PostHelixhorned, 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.
Could this type of patch be applied at map loading time (nudge, nudge)?
0

User is offline   Helixhorned 

  • EDuke32 Developer

#7

View PostLeoD, 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.

View PostLeoD, 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.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#8

View PostHelixhorned, 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...
Hm, schau'n mer mal...

View PostHelixhorned, 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.
Yup, that's what I was thinking about. The HRP maphack tree already knows hundreds of maps by their MD4 sum, so adding this kind of functionality almost suggests itself.
0

User is offline   Puritan 

#9

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
1

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options