[LeoD]

In recent and much less recent versions of EDuke32, colossus.map no longer works correctly. Touchplates and other items show up as visible sprites and do not take effect:

Compatible EDuke32 snapshots are 20070901 and 20090313 for example. Synthesis snapshots r1517 and later don't work.

chicken, could you please have a look into this and provide a patched version (or an EDuke32 bug report)?

[Helixhorned]

Extracting a part of the map and running it under vanilla Duke3D in DOSBox shows that the same behavior is exhibited there. This is further confimed by investigating the source codes. The problem is that the touchplate is wall-aligned (and has a non-zero hitag). This makes A_Spawn() change it to a STAT_FALLER, circumventing the touchplate's intended setup code.

[Danukem]

Helixhorned, on 31 October 2015 - 07:10 AM, said:

Extracting a part of the map and running it under vanilla Duke3D in DOSBox shows that the same behavior is exhibited there. This is further confimed by investigating the source codes. The problem is that the touchplate is wall-aligned (and has a non-zero hitag). This makes A_Spawn() change it to a STAT_FALLER, circumventing the touchplate's intended setup code.

So, DOS Duke exhibited the behavior, but then EDuke32 corrected it (the map was released in 2008 and worked fine until recently). Now the behavior has returned. I have seen other reports of maps being broken by this cstat issue. Is there a good reason not to process effect sprites if they are wall or floor aligned? This strikes me as a very serious problem -- there are probably many maps effected, and the only reason we aren't hearing more about it is that there aren't very many people playing them at a given time, nor will they necessarily go to the trouble of posting on a forum.

For those interested, here is a simple fix using CON code. You can insert the following code at the end of GAME.CON (or anywhere outside of actor and event code). I am already using this code in the latest release of my Attrition mod, because I was getting complaints about maps being broken.

onevent EVENT_LOADACTOR
ifvarl sprite[THISACTOR].picnum 11
    cstat 0
endevent

[chicken]

I have this sitting on my hd for quite some time now but never bothered to rerelease it. All the necessary changes regarding sector effector sprites etc. should be in now though.
Can you guys playtest this for me and see if there is still anything that isn't working?

Spoiler

Due to criticism i received after the initial release i changed the place where you can get the combination you need to finish the level.
It is now right in front of the buttons where you enter it.
In the original version it was hidden.
Is it better now?

Attached File(s)

•  colossus.zip (214.64K)
  Number of downloads: 192

[Helixhorned]

LeoD, on 31 October 2015 - 05:29 AM, said:

In recent and much less recent versions of EDuke32, colossus.map no longer works correctly. Touchplates and other items show up as visible sprites and do not take effect: colossus-touchplate.jpgCompatible EDuke32 snapshots are 20070901 and 20090313 for example. Synthesis snapshots r1517 and later don't work.

Trooper Dan, on 09 November 2015 - 12:23 AM, said:

So, DOS Duke exhibited the behavior, but then EDuke32 corrected it (the map was released in 2008 and worked fine until recently).

If the change from non-face-alinged effectors functioning (in contrast to DOS Duke) to becoming breakable sprites (as it is now) is a more recent one than r1517, could someone determine a revision?

[Mark]

Holy Cow. Chicken is a mapper too.

It was difficult. I got killed a few times along the way. Too many tanks and Fat Commanders for my playing skills. There was a place I got trapped towards the beginning. There is a light pole near a cliff wall. It looked like plenty of room to squeeze through to escape a tank. I got stuck and killed. Later on there is a building with a blocking sprite roof. The liztroopers from underneath were able to jump up thru the ceiling and onto the roof. Also inside one of the buildings an enemy clipped thru a fence. I was able to activate a switch behind a locked door. So even with the small glitches I've seen so far it is still quite a good,but tough map. I was playing with HRP and Polymer. I had slowdowns to under 20FPS in some places. I'm pretty sure if I disabled either one of those features it would have run much better as you mentioned in your text. But as far as any SE glitches, I didn't spot any yet.

[Danukem]

Helixhorned, on 09 November 2015 - 11:53 AM, said:

If the change from non-face-alinged effectors functioning (in contrast to DOS Duke) to becoming breakable sprites (as it is now) is a more recent one than r1517, could someone determine a revision?

I don't know, but, why would anyone want to make SECTOREFFECTOR etc. into a breakable sprite? Couldn't you just exclude tile numbers 0-9 from the breakable sprite feature?

[chicken]

Mark., on 09 November 2015 - 12:01 PM, said:

Holy Cow. Chicken is a mapper too.

It was difficult. I got killed a few times along the way. Too many tanks and Fat Commanders for my playing skills. There was a place I got trapped towards the beginning. There is a light pole near a cliff wall. It looked like plenty of room to squeeze through to escape a tank. I got stuck and killed. Later on there is a building with a blocking sprite roof. The liztroopers from underneath were able to jump up thru the ceiling and onto the roof. Also inside one of the buildings an enemy clipped thru a fence. I was able to activate a switch behind a locked door. So even with the small glitches I've seen so far it is still quite a good,but tough map. I was playing with HRP and Polymer. I had slowdowns to under 20FPS in some places. I'm pretty sure if I disabled either one of those features it would have run much better as you mentioned in your text. But as far as any SE glitches, I didn't spot any yet.

That was my appearance on the Duke-scene. Damn, 2008 ...
I hadn't mapped for Duke before and it shows. The outside area is way too large and too difficult but i'll leave all that as it is. Call it "vintage"
Just the obvious glitches will be taken care of.

Could you post screenshots of the issues you mentioned in our secret little Decay-Thread temporarily?
Then i'll fix the pole, the enemy clipping through the fence, the switch behind the locked door and i'll try to keep the liztroopers in place.

[Mike Norvak]

Trooper Dan, on 09 November 2015 - 01:17 PM, said:

I don't know, but, why would anyone want to make SECTOREFFECTOR etc. into a breakable sprite? Couldn't you just exclude tile numbers 0-9 from the breakable sprite feature?

If you actually break an SE it stops working right? I'd have an use for that.

[LeoD]

Trooper Dan, on 09 November 2015 - 12:23 AM, said:

here is a simple fix using CON code.

IIRC one of the maps that come with DukePlus has a similar issue. I'll check if this code fixes that, too.

chicken, on 09 November 2015 - 10:37 AM, said:

I have this sitting on my hd for quite some time now but never bothered to rerelease it. All the necessary changes regarding sector effector sprites etc. should be in now though.
Can you guys playtest this for me and see if there is still anything that isn't working?

Thanks!

Helixhorned, on 09 November 2015 - 11:53 AM, said:

If the change from non-face-alinged effectors functioning (in contrast to DOS Duke) to becoming breakable sprites (as it is now) is a more recent one than r1517, could someone determine a revision?

r1349 breaks Colossus.

Mark., on 09 November 2015 - 12:01 PM, said:

Too many tanks and Fat Commanders for my playing skills. [...] I was playing with HRP and Polymer. I had slowdowns to under 20FPS in some places. I'm pretty sure if I disabled either one of those features it would have run much better as you mentioned in your text.

Polymer is the main issue here IMO - tanks shoot lots of glowing projectiles, the resulting frame rate drop makes it even harder to deal with them, especially when they show up in groups.

chicken, on 09 November 2015 - 01:18 PM, said:

That was my appearance on the Duke-scene. Damn, 2008 ...
I hadn't mapped for Duke before and it shows. The outside area is way too large and too difficult but i'll leave all that as it is. Call it "vintage"

I like it that way. A remarkable release.

chicken, on 09 November 2015 - 01:18 PM, said:

Could you post screenshots of the issues you mentioned in our secret little Decay-Thread temporarily?

Why not here? Others may have remarks to contribute as well.

[Danukem]

Mike Norvak, on 09 November 2015 - 02:44 PM, said:

If you actually break an SE it stops working right? I'd have an use for that.

If the sprite is breakable then it wouldn't have worked as an effector in the first place. But if you want an SE to stop working, there are other ways of doing it.

[chicken]

LeoD, on 09 November 2015 - 07:53 PM, said:

Why not here? Others may have remarks to contribute as well.

Good point, ok bring it on!

[LeoD]

LeoD, on 09 November 2015 - 07:53 PM, said:

IIRC one of the maps that come with DukePlus has a similar issue. I'll check if this code fixes that, too.

Nope. Further investigation pending...

chicken, on 10 November 2015 - 02:08 AM, said:

Good point, ok bring it on!

The yellow-key-door should better slide to the other side:

[Helixhorned]

LeoD, on 09 November 2015 - 07:53 PM, said:

r1349 breaks Colossus.

Ah well, that provides the missing piece to the puzzle. That revision has the following change in prelevel():

             case SECTOREFFECTOR__STATIC:
(...)
             case RESPAWN__STATIC:
-                sprite[i].cstat = 0;
+                sprite[i].cstat &= ~(1|256);

Since the check in A_Spawn is for cstat having bits 32 or 16 set, the change in EDuke32 behavior follows. DOS Duke doesn't tweak the effector sprites in any way here, which explains why non-face-aligned effectors fail there.

How did you find out, by the way? Did you succeed in compiling those dinosaurs and were not afraid of actually running them?

Trooper Dan, on 09 November 2015 - 01:17 PM, said:

I don't know, but, why would anyone want to make SECTOREFFECTOR etc. into a breakable sprite?

Of course probably nobody would use any effector as a decorative breakable sprite, but the reason I was so conservative here is one of compatibility: someone making a map in EDuke32 and set wall/floor-alignment bits on an effector might assume it to work the same in DOS Duke. Not that I personally care too much about this, but I think some mappers around here would. The ideal solution IMO is to issue a warning somewhere since we're in an unfortunate state: either behavior leads to some kind of compatibility issue. So:

r5420 said:

Mapster32: add var 'corruptcheck_game_duke3d' and enable by default.

r5422 said:

premap.c: on prelevel(), clear bits 16 and 32 of effector sprites.

[LeoD]

Helixhorned, on 14 November 2015 - 09:23 AM, said:

How did you find out, by the way? Did you succeed in compiling those dinosaurs

No big deal since I've been used to do this bisect-compile shit for years now. And I've made a script to automate some stuff. I just tend to forget to downgrade the compiler to an appropriate version. The oldest buildable version is r16 btw. It doesn't work, however. (Maybe it would on WinXP.)

Helixhorned, on 14 November 2015 - 09:23 AM, said:

and were not afraid of actually running them?

Turning off the sound is all what's really necessary.

[EDIT:]Btw., could you please take a look at this issue which hasn't been fixed yet?

[Helixhorned]

LeoD, on 14 November 2015 - 11:25 AM, said:

No big deal since I've been used to do this bisect-compile shit for years now. And I've made a script to automate some stuff. I just tend to forget to downgrade the compiler to an appropriate version. The oldest buildable version is r16 btw.

Wow!

Quote

Btw., could you please take a look at this issue which hasn't been fixed yet?

Yup, done.

[LeoD]

Helixhorned, on 14 November 2015 - 11:57 AM, said:

Yup, done.

Thanks. Building on Raspbian gives some warnings you might want to fix:

make RELEASE=0 LTO=0 NOASM=1 RENDERTYPE=SDL SDL_TARGET=1 USE_OPENGL=1 POLYMER=0 LINKED_GTK=1

Spoiler

source/startgtk.game.c: In function 'GdkPixbuf* load_banner()':
source/startgtk.game.c:261:12: warning: 'GdkPixbuf* gdk_pixbuf_from_pixdata(const GdkPixdata*, gboolean, GError**)' is deprecated [-Wdeprecated-declarations]
     return gdk_pixbuf_from_pixdata((GdkPixdata*)&startbanner_pixdata, FALSE, NULL);
            ^
In file included from build/include/gtkpixdata.h:1:0,
                 from source/startgtk.game.c:23:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixdata.h:119:12: note: declared here
 GdkPixbuf* gdk_pixbuf_from_pixdata (const GdkPixdata *pixdata,
            ^
source/startgtk.game.c:261:12: warning: 'GdkPixbuf* gdk_pixbuf_from_pixdata(const GdkPixdata*, gboolean, GError**)' is deprecated [-Wdeprecated-declarations]
     return gdk_pixbuf_from_pixdata((GdkPixdata*)&startbanner_pixdata, FALSE, NULL);
            ^
In file included from build/include/gtkpixdata.h:1:0,
                 from source/startgtk.game.c:23:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixdata.h:119:12: note: declared here
 GdkPixbuf* gdk_pixbuf_from_pixdata (const GdkPixdata *pixdata,
            ^
source/startgtk.game.c:261:82: warning: 'GdkPixbuf* gdk_pixbuf_from_pixdata(const GdkPixdata*, gboolean, GError**)' is deprecated [-Wdeprecated-declarations]
     return gdk_pixbuf_from_pixdata((GdkPixdata*)&startbanner_pixdata, FALSE, NULL);
                                                                                  ^
In file included from build/include/gtkpixdata.h:1:0,
                 from source/startgtk.game.c:23:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixdata.h:119:12: note: declared here
 GdkPixbuf* gdk_pixbuf_from_pixdata (const GdkPixdata *pixdata,
            ^
Built object source/obj/startgtk.game.o

Spoiler

build/src/startgtk.editor.c: In function 'GdkPixbuf* load_banner()':
build/src/startgtk.editor.c:139:12: warning: 'GdkPixbuf* gdk_pixbuf_from_pixdata(const GdkPixdata*, gboolean, GError**)' is deprecated [-Wdeprecated-declarations]
     return gdk_pixbuf_from_pixdata((GdkPixdata*)&startbanner_pixdata, FALSE, NULL);
            ^
In file included from build/include/gtkpixdata.h:1:0,
                 from build/src/startgtk.editor.c:2:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixdata.h:119:12: note: declared here
 GdkPixbuf* gdk_pixbuf_from_pixdata (const GdkPixdata *pixdata,
            ^
build/src/startgtk.editor.c:139:12: warning: 'GdkPixbuf* gdk_pixbuf_from_pixdata(const GdkPixdata*, gboolean, GError**)' is deprecated [-Wdeprecated-declarations]
     return gdk_pixbuf_from_pixdata((GdkPixdata*)&startbanner_pixdata, FALSE, NULL);
            ^
In file included from build/include/gtkpixdata.h:1:0,
                 from build/src/startgtk.editor.c:2:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixdata.h:119:12: note: declared here
 GdkPixbuf* gdk_pixbuf_from_pixdata (const GdkPixdata *pixdata,
            ^
build/src/startgtk.editor.c:139:82: warning: 'GdkPixbuf* gdk_pixbuf_from_pixdata(const GdkPixdata*, gboolean, GError**)' is deprecated [-Wdeprecated-declarations]
     return gdk_pixbuf_from_pixdata((GdkPixdata*)&startbanner_pixdata, FALSE, NULL);
                                                                                  ^
In file included from build/include/gtkpixdata.h:1:0,
                 from build/src/startgtk.editor.c:2:
/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixdata.h:119:12: note: declared here
 GdkPixbuf* gdk_pixbuf_from_pixdata (const GdkPixdata *pixdata,
            ^
Built object build/obj/startgtk.editor.o