Eureka Keeps Corrupting My MAPs

[Moo Moo Armageddon]

it keeps saying "Map Validation Report: Found (number) lindefs with bad vertex references. These references have been replaced" and then it corrupts the map... I FUCKING HATE MY GODAMN LIFE I BUWIRSDILRDKUM. it keeps happening after I edit a MapInfo with slade. help? i just lost 9 hours of work I WANT TO FUCKING DIE

[printz]

Hi, I'm the new Eureka developer. Do you still have backup files? They're generated when you save (something with the .bak extension). If you do, can you please send one to me and tell me the steps you did that triggered the corruption?

 

Is MapInfo in the same WAD as the map? This would be good to know because then I'll try to reproduce it myself to pinpoint the problem.

[Moo Moo Armageddon]

 

 

0

 Advanced issue found

▲

 

1

1 minute ago, printz said:

 

 

0

 Advanced issue found

▲

 

 

1 minute ago, printz said:

 

Is MapInfo in the same WAD as the map? 

 yes

 

 

 

i think it happends when i save on slide then save on eureka

[printz]

OK, until I fix this, it would be best if you kept the level WAD (open with Eureka) separate from the resource WAD (open with SLADE). Really sorry for your loss, in case you didn't manage to recover by backup.

[smeghammer]

Yeah I found the same issue. My workaround was to do as @printz recommends, or simply make sure Eureka is closed when using Slade.

 

WRT backups - I highly recommend using github. It's free to use, with certain caveats. As long as you commit regularly to there, any losses are only as old as the last good commit.

[smeghammer]

Right, I dug into his a bit as it happened again (on Ubuntu). For me, it was because I did not have a node builder configured for Slade. Slade still saved map changes but did not build or insert nodebuilder data into the WAD. This lack of BSP data then killed Eureka. Fixed by configuring Slade to use a BSP CLI tool.

 

What happened was:

 

- Opened the map in Slade

- made a map change

- saved it, got a message about no node builder being found (but it saved it anyway)

- closed and re-opened in Eureka

- 5000 bad vertex refs...

 

I noticed that the filesize was now much reduced, and also that the OTHER maps of the same WAD still opened in Eureka, so it was clearly something to do with the map, not the WAD as a whole. 

 

To fix:

 

- Downloaded and deployed glbsp from here, and selected this from the Slade configuration.

- Made another change to the map in Slade

- saved and closed (filesize was back up to where I was expecting).

- NOW reopened in Eureka without problems.

 

 

Edited June 1, 2020 by smeghammer : specified platform

[Moo Moo Armageddon]

@smeghammer epic, is there a mac version?

Edited June 1, 2020 by Cut The Chit Chat YT : mac donaalds

[smeghammer]

Yes for both according to their respective homepages.

 

I'm not a mac guy, but looks like the .dmg files are what you want (https://slade.mancubus.net/index.php?page=downloads and https://sourceforge.net/projects/eureka-editor/files/Eureka/1.27/). Or you could build from the source if you want to compile the latest and greatest...

 

Cheers

[smeghammer]

Oh, you probably meant the BSP builder: Yes, seems to be. You may need to compile from source though:

 

https://www.macshareware.com/review/glbsp (by the original dev of Eureka I think - same name anyway...)

https://macintoshgarden.org/games/doom-editing-suite

http://glbsp.sourceforge.net/download.php

 

 

 

[andrewj]

12 hours ago, smeghammer said:

- Opened the map in Slade

- made a map change

- saved it, got a message about no node builder being found (but it saved it anyway)

- closed and re-opened in Eureka

- 5000 bad vertex refs...

To me this sounds like SLADE is corrupting the map when it cannot find the node builder.

 

If you could do that with a wad containing a single level, and post that wad on this forum after saving in SLADE but without opening it in Eureka, then I will have a look at it. 

[smeghammer]

7 hours ago, andrewj said:

If you could do that with a wad containing a single level

SLADE AND EUREKA BSP BUG

Definitely a reproducible bug.

Please find the test WADs on my github repo.

 

Seems to be an incompatibility between slade when a nodebuilder is not used and loading that un-bsp'ed WAD in Eureka.

 

base.wad:

• Unmodified reference from which all others copied

 

#disabled BSP in Slade

slade_vtxchange.wad: 

• altered a vertex,
• saved,
• played from within Slade OK,
• ALSO played OK normally.

slade_vtxchange_eureka.wad: 

• altered a vertex,
• saved,
• OPENED IN Eureka, got attached bug immediately on opening the map:
  
  
  
  
  • BUT this still played from within Slade OK,
  • ALSO played OK normally!!.
• Also, for this simple map, even with the attached corruption report, it PLAYED OK ON ctrl+t in Eureka., though the 3d view did show it fucked up:
  
   

#re-enabled BSP in Slade
slade_bsp_ok.wad:

• Same process, but now no sign of the corruption reported in Eureka.

So, there definitely seems to be an incompatibility when an un-bsp'ed WAD generated by Slade is opened in Eureka. Presumably, Eureka does not build nodes until you run the WAD (ctrl+t)? - perhaps un-BSP'ed nodes in Slade stored differently to un-BSP'ed nodes in Eureka? just guessing here... -  The WAD I got this error with yesterday was much bigger than this one and definitely did not play from within Slade or from CLI after it fucked up, but hopefully this simpler test exhibits the same issue.

 

The github repo includes the referred-to WAD files and the auto backups.

 

Hope this helps...

 

## update ##

Thought it might be to do with 3d floor or slope. Removed both and tested again. Still shows the same error :-(

 

 

Edited June 2, 2020 by smeghammer : more info

[andrewj]

Thanks smeghammer for that testing wad.

 

The issue is that Eureka looks for the BEHAVIOR lump at a fixed position of the map header, does not find it because SLADE has omitted the SEGS, SSECTORS and NODES lumps, so it assumes the map is Doom format and mis-interprets the LINEDEFS lump.

 

@printz the fix should be simple, adjust Wad_file::LevelFormat to test all the map lumps for presence of BEHAVIOR.  I could do it tomorrow if you're busy.

[printz]

Well, thanks a lot for the help. I'll see to this when I get to my PC.

[smeghammer]

Excellent news @andrewj. Glad it was useful. Cheers.

[smeghammer]

UPDATE

 

OK I discovered something else about this: 

 

 - create/open WAD in Eureka, make some edits

 - save and close

 - open same WAD in Slade

 - Add a SCRIPTS lump, edit and compile

 - Save and close

 - Open again Eureka - the WAD is automatically loaded...

 - Open tools/edit text lump/map scripts

   - the map script is EMPTY...

 

Essentially, Eureka seems not to test whether it's cached version is the same as the filesystem version originally opened. 

 

This would definitely explain apparently random corruptions.

[smeghammer]

An update to this:

 

I have also noticed that *sometimes* when you open a map in Slade that has been made in Hexen (in Doom) format in Eureka, Slade will change the map format to Doom. No idea why it does this though.

 

On re-opening the map in Eureka, making a change and saving will then destroy the map with the weird linedef/sector screwup I described above (presumably because it is trying to save Hexen format features into Doom format?). I did however find that in this specific case, it was sometimes reversible if the format was reset to Hexen and the nodes rebuilt. 

[boris]

Do your maps have a BEHAVIOR lump? That's usually used to distinguish Doom format maps from Hexen format maps.

[andrewj]

On 7/10/2020 at 12:34 AM, smeghammer said:

UPDATE

 

OK I discovered something else about this: 

 

 - create/open WAD in Eureka, make some edits

 - save and close

 - open same WAD in Slade

 - Add a SCRIPTS lump, edit and compile

 - Save and close

 - Open again Eureka - the WAD is automatically loaded...

 - Open tools/edit text lump/map scripts

   - the map script is EMPTY...

Can you post a wad after the step of saving in SLADE?  I will try to reproduce here.

 

P.S. Eureka only supports the map-specific SCRIPTS lump in a hexen format map -- it does not consider SCRIPTS in a doom format map to be valid (and I tend to doubt that it should allow that case).

 

As for your other post, if SLADE misidentifies a hexen map as Doom then that is SLADE's problem -- especially if the map works as hexen in ZDoom.

Edited September 1, 2020 by andrewj

[smeghammer]

@andrewj, I did have a play with this a while back, and the results are in this repo. The readme should give you ( @printz?? ) what you need. My tests suggested it was something to do with the nodebuilder (or lack of it in Slade). Probably not an issue if Eureka is used in isolation though. There was definitely an interaction with Slade. Note all the tests I did were on Ubuntu 18.04 LTS. There *might* be other examples in the git history of one of my levels as well, but hey, life's too short.... 

 

yes I think the second is an issue with Slade, not Eureka, because at no point have I noticed a corruption when using only Eureka. This is certainly different to the initial issue I raised in this thread (which was basically a result of having a map open in Slade and Eureka at the same time and getting the saves out of sync).

 

I have definitely noticed the second issue (much less frequently) when I have ensured that I do not have both editors open concurrently· 

 

12 hours ago, boris said:

Do your maps have a BEHAVIOR lump?

 

@boris, I *think* I know what the answer might be - You can create the scripts text lump in Eureka, but you cannot compile it. It is possible therefore that the following happens:

 

 - I create a map, in Hexen format, in Eureka

 - create a scripts lump (before any prior compiling, so no behaviour lump) in Eureka

 - Save, close

 - open it in Slade (which thinks it is Doom format because no behaviour lump)

     - I don't notice and don't change the format to Hexen in Slade

 - compile the script and save (map stays in Doom format?)

 - open in Eureka, Eureka thinks it is Doom format (because that is what it now is...) but Eureka tries to BSP as Hexen format

 = FUBAR...

 

I will test this sequence to see if it is correct. Bold steps I am not sure about without testing.

[andrewj]

18 hours ago, smeghammer said:

- I create a map, in Hexen format, in Eureka

 - create a scripts lump (before any prior compiling, so no behaviour lump) in Eureka

 - Save, close

To be clear, if the map is hexen format then there should always be a BEHAVIOR lump.  The default is to have it a small dummy lump which has no code in it but is otherwise valid.

 

Also when you talk about compiling the SCRIPTS lump, what exactly do you mean? Is that a SLADE command or a different program?

 

18 hours ago, smeghammer said:

open in Eureka, Eureka thinks it is Doom format (because that is what it now is...)

Well if the BEHAVIOR lump is removed somehow (without any conversion of the other lumps), then the format is considered to be Doom but the actual data is still in hexen mode inside the wad.  That should result in Eureka showing the map as complete garbage.  The nodes builder (BSP phase) has little do to with it.

 

P.S. I'm not suggesting there is not a bug here somewhere, actually there is at least one known one (regarding not testing for BEHAVIOR well enough when some lumps are absent), but it seems a bit llike you are messing with the raw lumps of a level and then wondering why things break.

[smeghammer]

@andrewj, thanks for the detailed answer.

 

4 hours ago, andrewj said:

To be clear, if the map is hexen format then there should always be a BEHAVIOR lump. 

 

4 hours ago, andrewj said:

bit llike you are messing with the raw lumps of a level and then wondering why things break

 

OK, I think that my earlier posts from a couple of months ago regarding this sort of odd behaviour could be explained by my not understanding that BEHAVIOR == Hexen format.

 

However, the weird 'conversion' I have seen when moving from Slade3 back to Eureka has definitely happened without any manual fiddling with lump order. It is also not consistent [well, there is very likely an underlying combination of factors, but I haven't been able to identify these] in that the times I have tried to reproduce this it has worked correctly.

 

 

4 hours ago, andrewj said:

Also when you talk about compiling the SCRIPTS lump, what exactly do you mean? Is that a SLADE command or a different program?

 

Slade proxies a separate command-line ACS compiler - 'settings -> Scripting -> ACS -> location of ACC executable'.

 

The location of ACC will depend obviously where you saved it and/or what OS you are using.

 

Then, in the Slade3 UI, you highlight the SCRIPTS source text lump and select 'compile ACS' from the script panel menu. An updated BEHAVIOR lump is thus generated.

 

4 hours ago, andrewj said:

Well if the BEHAVIOR lump is removed somehow (without any conversion of the other lumps), then the format is considered to be Doom but the actual data is still in hexen mode inside the wad.  That should result in Eureka showing the map as complete garbage

 

This is exactly the symptom I have seen.

 

If, on opening in Eureka, I do notice that the WAD has been opened as Doom format, I can change the format back into Hexen format from 'File -> manage project -> Source port' then everything is fine - because all the Hexen formatted data is again seen as hexen format.

 

Also, I did try the debugging sequence in my prior post to try and reproduce it and I did indeed see the stub BEHAVIOR lump prior to any compilation of ACS code. Of course, it did not show any odd behaviour...