[Danukem]

Today I received this email from someone trying get my old DNWMD mod to work:

Quote

Hi Dan! Nice mod you made there a while back!

Anywho, I grabbed the latest version (from 2008), and tried to get it working with the latest EDuke, and I found that it would just throw errors and not launch. Determined to get it working, I looked at the line numbers of the errors (all reported in dtgame.con), and found that each one was a case statement. It turns out that at some point between your last release, and the newest EDuke, using the case statement with a colon is no longer allowed. I was able to get it working by just doing a find and replace, changing every instance of 'case:' to 'case'.

Colons after cases were allowed for quite a long time. Would it be too much trouble to allow them again, just so that compatibility with older mods is maintained?

[Helixhorned]

I made LunaCON allow a colon immediately following a 'case' and instructed synthesis to produce a Lunatic build. I don't consider myself a C-CON maintainer, but I'd certainly like to support old mods. However, the DNWMD CONs don't translate cleanly anyway. Three and a few problems need to be addressed (a patch is attached):

DNWMD/dnwmd_cons/dtstatesevents.con 3394:13: error: gamevar `headshot' is not per-player
DNWMD/dnwmd_cons/dtstatesevents.con 3394:13:        Definition is at DNWMD/dnwmd_cons/dtvars.con 153:7

This is fixed by changing the line

getplayervar[THISACTOR].headshot tempb

to

getactorvar[THISACTOR].headshot tempb

DNWMD/dnwmd_cons/dtstatesevents.con 7167:11: error: write access to player[].newowner is not available

Here, I need to research under which circumstances it would be safe for Lunatic to allow writing -1 into .newowner, i.e. which other invariants may have to be met and whether it would be easy to guarantee that. I have commented out the block doing that.

dnwmd_cons/dtgame.con 16507:6: error: action "EVIL_RISE" has disallowed viewtype -1
dnwmd_cons/dtgame.con 16507:6: warning: action "EVIL_RISE" has incval different from -1, 0 or 1

Instead of

action EVIL_RISE -2402 1 -1 36

you probably meant

action EVIL_RISE -2402 1 <some viewtype> -1 36

I have made <some viewtype> 1.


This still leaves a few warnings:

DNWMD/dnwmd_cons/dtvars.con 50:7: warning: per-actor session gamevar `locatorids': NYI, made non-session

Here's some related ranting. I don't know whether the not-implemented status of this one has an adverse effect.

dnwmd_cons/dtgame.con 16116:10: warning: setting member '.htowner' to -1 will fail at game time

This is similar to the earlier error, some research is needed here, too.

Attached File(s)

•  DNWMD_for_20150514.patch.txt (1.22K)
  Number of downloads: 210

[Hendricks266]

Helixhorned, on 14 May 2015 - 04:55 AM, said:

Here's some related ranting. I don't know whether the not-implemented status of this one has an adverse effect.

IIRC, the use of this flag was TX's original suggestion for implementing arrays in a hackish fashion by overloading the per-actor struct, before gamearrays were implemented.

[Helixhorned]

Helixhorned, on 14 May 2015 - 04:55 AM, said:

Here, I need to research under which circumstances it would be safe for Lunatic to allow writing -1 into .newowner

OK, this one is easy: writing -1 into it should be good -- and that earlier commented-out block is needed for DNWMD, as you end up in the sector with the camera after looking into the viewscreen in SKYCAR otherwise . The other one, actor[].owner, is not so straightforward. I can find nothing in the EDuke32 source to suggest that assigning it a negative value is legal, pretty much the opposite: when one wants to signal that a sprite is not the child of another one, its actor[].owner is set to its own sprite index.

[Helixhorned]

Hendricks266, on 14 May 2015 - 08:59 AM, said:

IIRC, the use of this flag was TX's original suggestion for implementing arrays in a hackish fashion by overloading the per-actor struct, before gamearrays were implemented.

Yup, that seems to be the case. DNWMD uses it to track LOCATORS lotag -> sprite index correspondence for the map after SKYCAR. See r5194.

Helixhorned, on 16 May 2015 - 04:32 AM, said:

and that earlier commented-out block is needed for DNWMD, as you end up in the sector with the camera after looking into the viewscreen in SKYCAR otherwise

That comment was apparently a bit premature, it's still happening here sometimes. Needs investigation.

[Danukem]

Thanks for your help, Helixhorned. Some features in DNWMD may have depended upon exploits (e.g. fake arrays because official ones didn't exist when it was coded) and other things that aren't allowed now. I'm not sure if it's worth trying to get it to work in the latest build -- the exe it is packed with it should run fine, although it means missing out on a lot of eduke32 improvement from the last several years.