Do modern editors still lack something important?

Something that somehow plugs into your brain through eating it and reads your ideas for map design, automatically generating a level exactly as you imagine it.

/goatlord

Kappes Buur said:

Has anybody tried a multi-monitor setup with GZDoom Builder, where one monitor is used for the map,
another for preview and a third for gameplay?

Is that even possible right now?

I have a multimon and if you use windowed mode for the testing it will remember the windows positions for the game and builder (so you can have them occupy different monitors) but I dont think you separate 3d view from the normal editing view. The real problem with 3d view is that it locks your mouse in making editing both 3d and 2d view at the same time is kinda difficult. Also I think you cant edit the map if you are testing.

illuknisaa said:

Also I think you cant edit the map if you are testing.

In GZDB, you can (but you won't be able to save the changes while the engine is runnung).

A "lasso selection tool".

Kinda related to the painting/megatexturing idea, but I was pondering for the last few days if you could support Quake-style lightmaps in Doom... There would need to be some way to define the lights (metadata for textures with lights on them maybe, or stuff like a "sun object"). Once the lightmaps have been created through whatever delightfully slow and beautiful path tracing/radiosity/photon mapping algorithm is chosen, there would need to be a separate process to "bake" the lightmaps into the level textures/map geometry. I'm thinking of something what would automatically create sectors for unique floor tiles with shadows, chop up lines, etc.

It seems plausible but it would have a lot of downsides:
1) The effect wouldn't mix well with dynamic lights in hardware ports
2) There would be a ton of extra sectors and textures, so it would probably be limited to carefully constructed maps
3) It's probably a one-way transform since the map might be a mess to edit afterwards
4) The 8-bit palette would really limit how good it looks
5) I'm not sure how it would mesh with Doom's existing lighting. It would be odd if your gun and all items were always fullbright, but how do you make nice looking gradient shadows across sectors with different light levels?

Anyway it's probably too much work for a janky output, but it would have been neat to see.

Sort of related to scifista's and 40oz's mention of managing dummy sectors, I was briefly working on an idea for a basic 'Boom script compiler'. The idea being that you could specify different voodoo/conveyor/effect setups in a text script, with precise timing and what-not included and easy to adjust.

The compiler would then build the required control sectors off in the void, populate them with the actors you specify, and handle the tags. I had a prototype mostly working last year but I kind of lost interest and now I can't find the code.

Not that it was terribly useful. It was sort of cool to be able to write a one-liner that would create a vending machine with a several hundred stimpacks that came out one at a time as you pressed a switch.

Mithran Denizen said:

I was briefly working on an idea for a basic 'Boom script compiler'. The idea being that you could specify different voodoo/conveyor/effect setups in a text script, with precise timing and what-not included and easy to adjust.

The compiler would then build the required control sectors off in the void, populate them with the actors you specify, and handle the tags. I had a prototype mostly working last year but I kind of lost interest and now I can't find the code.

Haha, I've had that idea before. I'm amazed you actually managed to make something out of it.

I would love to see it. I was dreaming of such a thing years ago. Also authors could include "source code" in the wad for other people to quickly understand how stuff works (try to figure out the scripts in Map30 of 1994 Tune-Up, it's insane).

gemini09 said:

A "lasso selection tool".

Would this suffice?
From the GZDoom Builder Reference Manual:

That's not lasso selection. GZDB doesn't have that. Instead, it has Paint selection. To use it, hold MMB while in Sectors/Linedefs/Things/Vertices mode and wave the mouse around :)

Thanks for both tips :)

The entire working field that we have at our disposal (65.000 unit large square grid area): will our node-builders ever catch up and allow us to use the entirety of that area?

I'm running into the same node-building problem I did now as I did in 2009 D:

It's not just a problem of node-building, because Doom uses fixed point values to compute distances between two points. Fixed point values are signed, even if a negative distance is logically impossible. So the maximum valid distance between two points, when that distance might be computed (e.g. one is the player and the other is a monster) must remain less than the largest positive fixed point value.

A way you could place a vertex on a line and instead of using it to bend the line, you could lock the vertex on rails with the line and slide it to where you want, so you don't have to carefully make sure you don't change the angle of the line if its not aligned with the grid.

And I just gave the stairbuilding tool a whack, which is cool for what it can do, but I still think an additional tool that can take one sector and divide it into equal slices would be just as useful as well. I usually do my flat layouts first then reserve some hallways to be used as stairs later. The stair building tool makes it kind of a hassle to fit stairs in an already built layout.

40oz said:

A way you could place a vertex on a line and instead of using it to bend the line, you could lock the vertex on rails with the line and slide it to where you want, so you don't have to carefully make sure you don't change the angle of the line if its not aligned with the grid.

I have a tough time trying to visualize what you described. :)
Perhaps, select the two adjacent linedefs and move them?

40oz said:

.... but I still think an additional tool that can take one sector and divide it into equal slices would be just as useful as well....

From that I take it that you are not using GZDoom Builder, which has such a facility with 'Draw Grid Mode'.

gemini09 said:

The entire working field that we have at our disposal (65.000 unit large square grid area): will our node-builders ever catch up and allow us to use the entirety of that area?

What, will a node builder refuse to build nodes for a 64000x64000 map?

I know the blockmap would overflow from trying to do that, but I don't see any reason why the nodes themselves wouldn't work fine.

Linguica said:

I know the blockmap would overflow from trying to do that, but I don't see any reason why the nodes themselves wouldn't work fine.

That entirely depends on the format the nodes get stored in and the map layout. The maximum distance that can be expressed in fixed point is 32768 map units so if anything in the nodes ends up larger than that it can't be stored without loss of data - not even in the engine structures.

And node lines are stored as an origin point and a distance vector, so any node line that ends up longer than 32768 map units will be effectively broken.

Right, but partition lines don't need to span the entire width of the child nodes they delineate. If you have a 64000x64000 map, the partition line can still only be 32000 units long (or, more likely, much shorter) and the math to determine which side a point is on still works fine.

See E1M1 for example. The partition line for the root node is much smaller than the bounding boxes:



The bounding boxes for nodes also use 4 shorts for each of the 4 corners, so no problems there either.

Basically I don't see anything in the standard node format that would prevent you from forming a proper node structure for a 64000x64000 map, so long as the node builder was smart enough to avoid trying to store any super long partition lines. Is there something I'm missing?

The only thing you are 'missing' is that the node builder has to pick an actual linedef. And if that happens to be too long, ugly things will happen. It's always possible to create such edge cases.

Ugly things will happen anyway because distance calculations will overflow if some actors are too far apart. The map may render properly but exhibit gameplay glitches.

The general advice still stands that no two points in a Doom map should be further apart than 32767 map units.

Is there some reason a node builder MUST split nodes by picking a linedef? It's not like the partition line in the node structure is in any way defined by the linedef, it just happens to share the same start/end coordinates. What's stopping the node builder from making its partition lines be any arbitrary lines it wants? (This is more of a general question, not related to the topic of huge maps.)

I'm pretty much here with everyone else. I have to make my new textures in Photoshop.

Well, it isn't all that bad to do really, just takes time and can sometimes be a little painstaking.

But then, if you want to make nice textures, you have to put in the time and effort. Labor of love, then, I should say. ;-)

One thing I would like to see, is a single editor that does it all. Right now, with the writing of my wad, I am having to use both Doom Builder 2 and Slade 3. I use Doom Builder to draw my maps, then Slade to import my textures. Kind of a jump-back-and-forth thing. If that could be eliminated, by say, the guys doing Doom Builder making a facility in it for wad-data manipulation, I would be in wad-building heaven!

Barefootstallion said:

One thing I would like to see, is a single editor that does it all. Right now, with the writing of my wad, I am having to use both Doom Builder 2 and Slade 3. I use Doom Builder to draw my maps, then Slade to import my textures. Kind of a jump-back-and-forth thing. If that could be eliminated, ....

Well, Slade3 is a lump editor and a map editor already.

Barefootstallion said:

.... by say, the guys doing Doom Builder making a facility in it for wad-data manipulation, I would be in wad-building heaven!

Never going to happen,
DB2 development ceased 2 1/2 years ago and for GZDB MaxED already said that he has no plans to include that side of mapping.

That aside, if you want to spent US$34.00 you could purchase Deepsea, which is a map editor and has multiple facilities to edit lumps. However, you would have to forgo UDMF.

BFS is making maps for Risen3D, so losing UDMF wouldn't be too much of a worry I think.

Note that SLADE 3 has an "open map in Doom Builder" feature.

Kappes Buur said:

Well, Slade3 is a lump editor and a map editor already.



Never going to happen,
DB2 development ceased 2 1/2 years ago and for GZDB MaxED already said that he has no plans to include that side of mapping.

That aside, if you want to spent US$34.00 you could purchase Deepsea, which is a map editor and has multiple facilities to edit lumps. However, you would have to forgo UDMF.

Question; what is 'UDMF'?

Also, tried Deapsea. Hated it. This 'project file' thing. What even is that? I wasn't able even to start my first wad! I binned the program right to the recycle bin on the first day of trying it, likely to never worry with it again.

And besides, who charges $30 for a program that is used to edit another program that is 22 years old, anyway? o.O

But yep, I'm in a minor love affair with Risen3D. The guys who wrote it may have stopped supporting it for now, but in my estimation, it's got a lot of stuff going for it. Hi-res textures, slopes and 3D lines. It takes Doom to places few other engines can. I love it. :-)

UDMF = Universal Doom Map Format. Other Doom map formats are "Doom format" and "Hexen format".

scifista42 said:

UDMF = Universal Doom Map Format

Ah, gotcha!

Thanks for the info! :-D

skillsaw said:

Total pipe dream but I'd love a multi-user mode. It would be fun to collaborate on a map simultaneously in real time.

I think I was reading Masters of DooM and there was some snippet in there about how they were doing that with the DooM level editor thanks to NextStep machines being cool at networking or something.

I think John Romero was saying he could edit some random walls or something while Tom Hall can place enemies, back when Tom Hall was still there, etc...