Doom Builder 2.1.0.1356 released

Barely two weeks after the release of Doom Builder 2.1.0, CodeImp has put up a new version, bringing it to revision 1356. The highlights of this version include:

• Updated ZDBSP to fix some critical nodebuilding issues (which you noticed only in-game when testing)
  
• Fixed crash that occurred when sectors had insane amount of sidedefs
  
• Fixed some DECORATE support issues
  
• Added a bunch of features for plugins
  
• Proper compiler and syntax highlighting for Vanilla Hexen scripts
  
• Some minor Game Configuration updates

As always, you can get the new version at the downloads page, and a full list of changes can be viewed on the version changed page.

Very nice work.

boris said:

Proper compiler and syntax highlighting for Vanilla Hexen scripts

<3

Just tried it out with my son just now. Wow, its much easier to use that the version 1 build that I used long ago. Very nice.

This is a joy to use -very straight forward and slick.

Ok, this still doesn't seem to be working.

Vanilla Hexen scripting? I tested it myself and it worked fine.

Yeah, I ddi a test where I compiled the script and ran it with Hexen in Dosbox. Didn't run the script. I can't imagine what I could be doing wrong either. :/

Well I used Chocolate Hexen, not DosBox. But that would be odd if the problem is caused by that.

PROOF SHOWN ON VIDEO
 

Yeah I just tried Chocolate Hexen too. Didn't work there either. So I guess the problem must be with my set up... some how.

I would say check your launch parameters, but there isn't much you can mess up there (see the video, I kept everything at defaults, just selected chocolate-hexen.exe). I'm not sure if this is different on windows version other than XP, but you could try checking "Customize parameters" and then check "Use short paths and file names". And then you may also try removing the quotes from the parameters. If that doesn't help, I'm out of ideas.

Really strange. I tried re-installing DB2, but that did nothing.
I guess I'll just have to keep using the inconvenient method...

Wouldn't surprise me if this is all because I got Win7.

Here is another thing you could try: Compatibility settings. I'm not sure if this is possible in Win7, but in XP you can right-click an executable and change the comaptibility settings you wish to use on a program (for example, pretending it runs in Windows 2000). Try setting that to Windows XP on Builder.exe. Also try it on the DosBox or Chocolate Hexen executable.

Maybe it's the script itself that doesn't work, instead of the compiler?

Yeah, I've never experienced that doing any difference to anything I've ever tried it on. Besides. The problem isn't with Dosbox, Hexen or Chocolate Hexen. It's got to be with the behaviour lump. As the script works fine in Zdoom, but not in Doomsday, Vanilla or Chocolate Hexen. For some reason, it refuses to generate a proper Hexen script.

EDIT: Wait, not sure if it didn't work with Doomsday or not. It wouldn't run the map when I tried. -_- I'll test.

Gez said:

Maybe it's the script itself that doesn't work, instead of the compiler?

No, it works when I generate it manually with ACC from Zdoom using command lines and XWE to import the behaviour lump into the map.

EDIT: hmm. hang on.. I'm getting some problems I didn't use to have.

EDIT: Ok, I'm not sure what to think. But it seems I can no longer generate Hexen compatible ACS with the Zdoom ACC compiler. The only thing I can think of that could contribute to this is that I now use Win7 (64x) as opposed to a few months ago (mid July) where I were still on WinXP (32x).

So, I apologize to Codeimp for having been such a major pain in the ass about this.

I tried running the ACC program in Win2000 compatibility mode. But that didn't help (obviously, because it never works).

---

EDIT: For what it's worth. I tested the DOS version of ACC v 1.50 as well. I had to run it in Dosbox of course for it to work. But it gave me the same output as the Windows version. I'm quite perplexed right now, as I was sure that it was going to work.

Out of curiosity, I must ask, what does Lighting mode do? I've found no info anywhere regarding it.

There's a lighting mode?

It is my understanding that Vanilla HeXen (and hence HeXen in Doomsday) can't load a map with a 0 byte Behaviour Lump.

But yes, with regards to compatability, HeXen in Doomsday should be considered identical to Vanilla HeXen.

my maps load just fine in vanilla. doomsday however is an entirely different matter.

If the compiler does not generate Hexen bytecode, maybe you use functions not available in vanilla Hexen?

No that can't be it, I've tried with recompiling scripts that already has been tested to work with vanilla. :/ Plus, I am only using commands that I've got from other Vanilla Hexen projects. Like the original maps for instance.

footman said:

Out of curiosity, I must ask, what does Lighting mode do? I've found no info anywhere regarding it.

It allows you to quickly adjust the brightness levels in sectors by selecting them and using the right mouse button to "drag" the levels up or down. You can see the results on the screen immediately because it is textured (unless you set the view mode to Wireframe).

kristus said:

my maps load just fine in vanilla. doomsday however is an entirely different matter.

If it's an issue with the 1.9 Beta's, report it:
http://sourceforge.net/tracker/?group_id=74815&atid=542099

Issues with the conversion to Doomsday's new map format are to be expected at this stage; I recently reported a very specific issue with the 1.9 Beta's that would cause conversion of both Doom and HeXen format maps to fail for instance. I'd imagine that Deng team will want to see the map(s), either attached to the bug report, or sent to them privately.

If it's 1.8.6, all that can be said is that it probably should work, but if it doesn't, it won't be fixed (i.e. Deng team aren't going to work on 1.8.6 any more).

I'm curious, is it on purpose that performing an undo removes all current selections? I feel it being somewhat of a nuisance for me personally, as often reselecting stuff each time I make a mistake feels a bit unnecessary. But if it's indeed on purpose and there's a clear reason for the behavior, then never mind my personal headache with it.

Vermil said:

If it's an issue with the 1.9 Beta's,

I've not tried with that yet since it's so buggy still. But I've tried with 1.8 or whatever that version number is.

I suspect that ZDoom's ACS compiler is not producing Hexen-standard bytecode even when asked. Whether or not the produced bytecode works with vanilla is not really indicative of it working 'correctly', as the existing ops can be combined in various ways, producing new constructs that aren't actually part of the standard.

We'd definitely need to see the mod in question.

@Vermil - thats a completely unrelated regression (player 1 spawn spot required) and one which is unlikely to affect anyone, other than when making small test/demo maps. However, you are correct in that this is a prime spot for potential regression atm. Although its seen very little change in a year or so...

I was using Zennode.

Lets try and clarify - are we talking about the following combination?

Map built with DB2 in Hexen format, BEHAVIOR compiled with DB2's handoff to ZDoom's ACC and nodes built with Zennode (via DB2?) resulting in load failure in Doomsday 1.8.6 playing jHexen.

Not that it matters, Jdoom demands that the files are rebuilt using glBSP and creating .gwa files. Then the game bombs out with an memory allocation error. So, you set it up to allocate more memory, and you're greeted with an "Ethereal travel" screen, that seem to be there to stay.

Not to mention that it's only in Jdoom that it's not working.

I suppose that the problem I am having with the Behavior lump could be causing Jhexen to stop at loading. But if Vanilla don't care (EDIT: even when it doesn't accept the bytecode, all that result in is that the scripts don't run.), why would a port like Doomsday?

kristus said:

Not that it matters, Jdoom demands that the files are rebuilt using glBSP and creating .gwa files

Correction; older versions of Dday did require the GWA files to be built by an external version of GLBSP before Dday launched; this was actually handled by the Kickstart launcher, rather than the engine itself.

However, a version or two before 1.8.6, Dday got an internal node builder (based off GLBSP) allowing it to create the GWA files itself when it first loads the map in game.

The default options in the Kickstart launcher included with Dday 1.8.6 wern't erroneous GWA files by un-checking the "check if GLBSP needs to be ran" box on the misc tab of the launcher.

DaniJ said:

@Vermil - thats a completely unrelated regression (player 1 spawn spot required) and one which is unlikely to affect anyone, other than when making small test/demo maps. However, you are correct in that this is a prime spot for potential regression atm. Although its seen very little change in a year or so...

I never said it was related; I was just saying that there might be variables that the 1.9 Beta map converter can't yet handle.