Duke4.net Forums: Transport Elevators - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

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

Transport Elevators

User is offline   Forge 

  • 5,913

#1

Transport elevators are crashing eduke32.

example:
SE 17 (warp elevator) setup failed: sprite # at (grid #, grid #)

works with r2962
crashes with r2971

Example of a map attached

Attached File(s)

  • Attached File  area.zip (56.42K)
    Number of downloads: 19


This post has been edited by Forge: 17 January 2018 - 06:12 PM

0

User is offline   Paul B 

  • 441

#2

Hi Forge,

Here is what I did. I took the teleporting Elevators out of the map you posted. I placed them in a fresh new map and I loaded them map with just the elevators. I grabbed the latest EDuke synthesis which is at the time of writing this version: r6581.

I experienced 0 crashes going up and down and reverting the direction mid stream.

Perhaps this problem has been addressed in more current releases..?


Interesting that Helix made mention of the Warping elevators in:

------------------------------------------------------------------------
r2971 | helixhorned | 2012-08-26 15:17:14 -0700 (Sun, 26 Aug 2012) | 4 lines

Quit the game if SE17 (warp elevator) setup fails.

The spawn-time SE 17 setup uses nextsectorneighborz() which can fail
(return -1) on some circumstances and would cause an OOB sector[] access.
------------------------------------------------------------------------


Looks like it was fixed below:

r3013 | helixhorned | 2012-09-12 02:48:31 -0700 (Wed, 12 Sep 2012) | 6 lines

SE17 setup: when failing to find warp z height for lower level, use heuristic.

Specifically, use the elevator's own ceiling z height instead of searching
nextsectors with nextsectorneighborz(). This makes maps like L9.map (Spaceport
from N64) or DEMOUNT.MAP work. [Note well: work at all, since if it happened
to work before, that was pure coincidence.]
------------------------------------------------------------------------


This post has been edited by Paul B: 17 January 2018 - 07:02 PM

0

User is offline   Forge 

  • 5,913

#3

map's broke.
worked before.
doesn't work now.
That means there are other pre-2012 maps & TCs that could be broke as well.

This post has been edited by Forge: 17 January 2018 - 07:01 PM

0

User is offline   Paul B 

  • 441

#4

View PostForge, on 17 January 2018 - 07:00 PM, said:

map's broke.
worked before.
doesn't work now.
That means there are other pre-2012 maps & TCs that could be broke as well.


Forge update your Eduke to r3013 and try again. I seem to recall this problem back in the day. So are you posting this so they can go back to that version to patch it like r3013? I don't understand?


This post has been edited by Paul B: 17 January 2018 - 07:08 PM

0

User is offline   Forge 

  • 5,913

#5

I'm using r6581 for everyday use. (which has the same problem as what I stated in the op)
Why would I downgrade to r3013?

I traced the problem back to where it originally started. When the map last worked & when it stopped working.

Why are you ducking up my bug report with your unhelpful flotsam? Are you going to investigate and make a commit to the server if you can fix it?

This post has been edited by Forge: 17 January 2018 - 07:19 PM

1

User is offline   Paul B 

  • 441

#6

View PostForge, on 17 January 2018 - 07:09 PM, said:

I'm using r6581 for everyday use. (which has the same problem as what I stated in the op)

This is a bug report thread, not a plea for being told to downgrade.



Okay, if you actually play the map then yes I see the problem. I was working with the wrong teleporting elevator in the map at first because I didn't see the coordinates error message on eduke launch as I was looking and testing the wrong elevators in my sandbox.

Now onto the problem:

I suspect it has to do with the lower elevators neighboring floor door sector. The elevator must calculate the lower sector based on the adjacent sector floor height. Since that neighboring sector is a floor door that sectors floor height becomes dynamic and as a result the elevator can't calculate rock bottom and probably why the elevator is crashing .


This post has been edited by Paul B: 17 January 2018 - 07:52 PM

0

User is offline   Forge 

  • 5,913

#7

edited for continuity to match someone else's edit

View PostPaul B, on 17 January 2018 - 07:17 PM, said:

I suspect it has to do with the lower elevators neighboring floor door sector. The elevator must calculate the lower sector based on the adjacent sector floor height. Since that neighboring sector is a floor door that sectors floor height becomes dynamic and as a result the elevator can't calculate rock bottom and probably why the elevator is crashing .

probably - but the map worked in dos, & eduke32 up to a certain snapshot - then they changed the code for it for some reason

This post has been edited by Forge: 17 January 2018 - 08:17 PM

0

User is offline   Hank 

  • 1,710

#8

I looked at the map.

SE17 has a hi-tag of 1

There are two switches with the same tag, but unrelated to the lift. Hovering over any of those SEs, and Pressing LSHFT shows the unwanted connections.

If it is your map, try to give either the switches or the SE17 a different tag number.

Time waits for no one.

This post has been edited by Hank: 17 January 2018 - 07:48 PM

0

User is offline   Forge 

  • 5,913

#9

View PostHank, on 17 January 2018 - 07:46 PM, said:

I looked at the map.

SE17 has a hi-tag of 1

There are two switches with the same tag.

If it is your map, try to give either the switches or the SE17 a different tag number.

you mean something that is way abnormal from the rest of the map - say like 994?

& the ST15 is correct with 0 for the lower floor & 1 for the upper floor

This post has been edited by Forge: 17 January 2018 - 07:58 PM

0

User is offline   Hank 

  • 1,710

#10

yes, at least try it.

Look, all my maps have elevators, and there are no crashes, since 1999 :P

Time waits for no one.
0

User is offline   Paul B 

  • 441

#11

View PostHank, on 17 January 2018 - 07:51 PM, said:

yes, at least try it.

Look, all my maps have elevators, and there are no crashes, since 1999 :P


No the crash is a result of the floor door connected immediately beside the elevator. There should be a child sector between the door and the elevator. (IMO - Mappers fault). The only way I can think of having a permanent fix in code is to somehow store the initial elevators floor height value instead of searching for a next sector Z-Axis. But then again who knows what else that might screw up with people exploiting the elevator to offer 3 different floors. I think it would just be much easier to have the mapper add an extra sector between the door and the elevator.


This post has been edited by Paul B: 17 January 2018 - 08:05 PM

1

User is offline   Forge 

  • 5,913

#12

here's the deal - we can mess with the map & probably get it to work. Fine.

The reason I made this thread:


View PostPaul B, on 17 January 2018 - 07:53 PM, said:

Mappers fault

not the mappers fault - The map works in dos duke3d


the map worked with eduke32 up to a certain snapshot
now the map no longer works with eduke32 after a certain snapshot


there are probably more maps & TCs that are broke because of this.

It makes more sense to see if eduke32 can be adjusted instead of fixing an unknown amount of maps and such.

This post has been edited by Forge: 17 January 2018 - 08:07 PM

3

User is offline   Hank 

  • 1,710

#13

View PostPaul B, on 17 January 2018 - 07:53 PM, said:

No the crash is a result of the floor door connected immediately beside the elevator.

Bullshit.
Hover over the SE17, and press LSHIFT, and you see the conflict.
If you read the old FAQs from Bishop, it too suggest to give those sprites a unique tag number.

If this worked before, lucky you. :P

Time waits for no one.
0

User is offline   Paul B 

  • 441

#14

View PostHank, on 17 January 2018 - 08:12 PM, said:

Bullshit.
Hover over the SE17, and press LSHIFT, and you see the conflict.
If you read the old FAQs from Bishop, it too suggest to give those sprites a unique tag number.

If this worked before, lucky you. :P


Hank that was the first thing I noticed when I was testing this map. However, in this case the elevator conflicting with a switch doesn't appear to have any impact on the crash.

Now where's the tylenol?


This post has been edited by Paul B: 17 January 2018 - 08:19 PM

0

User is offline   TerminX 

  • el fundador
  • 5,227

  #15

It only worked before out of pure luck, with out-of-bounds array access happening to fall on memory that allowed the map to work similar to how the author wanted despite the effect being constructed wrong. Plenty of things worked in DOS because DOS has no concept of "protected" memory, and any application can shit all over any memory address without repercussion. Such errors are "harmless" in DOS but fatal in any modern OS.

EDuke32 wiki svn builds bugs
Join us in #eduke32 on irc.freenode.net!
1

User is offline   Forge 

  • 5,913

#16

View PostTerminX, on 17 January 2018 - 08:19 PM, said:

It only worked before out of pure luck, with out-of-bounds array access happening to fall on memory that allowed the map to work similar to how the author wanted despite the effect being constructed wrong. Plenty of things worked in DOS because DOS has no concept of "protected" memory, and any application can shit all over any memory address without repercussion. Such errors are "harmless" in DOS but fatal in any modern OS.

It also worked in earlier versions of eduke32
r2962 & before.

So is there any way to adjust the eduke32 code, or is everything constructed with 'luck' going to have to be manually fixed in order to use the latest version of this port?

This post has been edited by Forge: 17 January 2018 - 08:30 PM

0

User is offline   Hendricks266 

  • EDuke32 Senior Developer
  • 5,969

  #17

Quote

-------------------------------------------------- ----------------------
r6582 | hendricks266 | 2018-01-17 22:28:55 -0600 (Wed, 17 Jan 2018) | 1 line

When SE 17 can't find the next sector for the floor, use the heuristic added for ceilings in r3013 to determine the floorz, replacing the game exit added in r2971.
------------------------------------------------------------------------

With this change I was able to load and complete the map. I also found the affected sector's location in Mapster and verified that it functions properly during my playthrough. Please see if this works for you.
2

User is offline   Paul B 

  • 441

#18

View PostForge, on 17 January 2018 - 08:28 PM, said:

It also worked in earlier versions of eduke32
r2962 & before.

So is there any way to adjust the eduke32 code, or is everything constructed with 'luck' going to have to be manually fixed in order to use the latest version of this port?


Forge the luck part came from 3dRealms. Technically the way 3DRealms introduced the Teleporting Elevator it should never have worked. EDuke is making the code more concrete and reliable rather than relying on luck.

Damn the speed at which Hendricks266 works makes my head spin.


This post has been edited by Paul B: 17 January 2018 - 08:39 PM

0

User is offline   Forge 

  • 5,913

#19

View PostHendricks266, on 17 January 2018 - 08:31 PM, said:

With this change I was able to load and complete the map. I also found the affected sector's location in Mapster and verified that it functions properly during my playthrough. Please see if this works for you.

I'd ask to have your children, but I already promised Yatta.
(you'll have to settle for an under the table handy at Thanksgiving dinner.)

^that means it worked.

This post has been edited by Forge: 17 January 2018 - 08:38 PM

1

Share this topic:


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


All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Maiden! ;) © 2018 Voidpoint, LLC

Enter your sign in name and password


Sign in options