Building the New Evolution

[CodeImp]

I will definitely make an option to show the Thing's square size, and even when not highlighted, because it matters indeed.

[Jonathan]

Like fuck it matters, but whatever... ;) Your choice of programming language (and platform) is exactly right, and I only wish your choices met with complete approval, far away from complaining voices.

By the way, what is the ear-clip triangulator mode for? I just don't get it!

[exp(x)]

Jonathan said:

Your choice of programming language (and platform) is exactly right

Exactly right for what?

[CodeImp]

Jonathan said:

what is the ear-clip triangulator mode for? I just don't get it!

It was my testing mode for the triangulator algorithm, it has no editing purpose and now that I finished my algorithm it will be removed.

[Jonathan]

exp(x) said:

Exactly right for what?

Uh... for Doom Builder 2?

[cycloid]

Request 1:

Ability to toggle flats and/or lighting on/off in the 2D editor, see Duke Nukem 3d's in-game map for an example of what this might look like: http://nukem.hut.ru/images/D3d_e1l2.gif etc.


Request 2:

Better thing filters for when working out difficulty levels, it's annoying for example to loose a bunch of things you inserted because they defaulted to UV and you're trying to edit in HMP.


Request 3:

Three-way autostitch toggle: none, <user preference set distance> and exact. Where the latter will only stitch if you manually place vertices on top of each other. That way i wont have to keep hitting undo when i'm doing something fiddly to overcome my usual 4-unit autostitch.


Bet there's tons more posts like this but I'm also a Win.Net C# coder so if there's anything I can help with i might be able to lend a hand. But y'know, it's your baby, I wont take offence at a flat "no thanks".

[printz]

As for another plea... What about granting access for a linedef's sidedef references? This way I could make a multi-face switch. Currently Doom Builder normalizes whatever compressed sidedefs so each line has its own sides.

[Graf Zahl]

Some ports automatically do that so your switch wouldn't work as expected.

On the other hand, what about automatic sidedef compression? That way the map size limit could be increased dramatically.

[Enjay]

Just as long as there are easy ways of making sure that specific sides are not compressed. The "all or nothing" approach of DeePsea's sidedef compressor has caused me unexpected problems in the past.

[CodeImp]

I don't see how it could cause problems (some sourceport's bug maybe?). What I actually wanted to do (when the map is saved) is check if the map can be saved without sidedefs compression, if it can't because there are too many sidedefs, then let it do complete sidedefs compression.

cycloid said:

I'm also a Win.Net C# coder so if there's anything I can help with i might be able to lend a hand.

Well most of the code I want to write myself because I am simply the only who knows how it all works and I really only like it when code is written my way :P However, there is this incomplete WadAuthor Editing Mode which I experimented with and maybe you'd like to finish it, or maybe come up with some original editing modes that would be usefull. (The WA editing mode is in the BuilderModes plugin for now, but will be taken out. It also shows how to make a custom popup-menu on mouseclick.)

[Graf Zahl]

If you want to be safe, just compress sidedefs without any special type. These are generally no problem in any port.

ZDoom uncompresses sidedefs when loading maps so for it and its derivatives you can do a full compression.

[SulfurOccult]

cycloid said:

Request 3:

Three-way autostitch toggle: none, <user preference set distance> and exact. Where the latter will only stitch if you manually place vertices on top of each other. That way i wont have to keep hitting undo when i'm doing something fiddly to overcome my usual 4-unit autostitch.

this would be very useful

[andrewj]

Graf Zahl said:

If you want to be safe, just compress sidedefs without any special type.

GLBSP does the same thing: keeps sidedefs separate on special lines (in case they are scrolling, etc).

These are generally no problem in any port.

The current 1.9 beta of Doomsday cannot handle shared sidedefs.

[Graf Zahl]

Then they have to fix that. There's some WADs out there that do use compressed sidedefs, even for Doom.exe (e.g. Cleimos IIRC.)

[LexiMax]

1. Eternity Extradata

2. Allow the user to specify a working directory for the testing executable, so Chocolate Doom will actually work.

3. Eternity Extradata

4. Eternity Extradata

5. Eternity Extradata

Seriously, other than that small little problem with Chocolate Doom, I have no need for new editor or any other new features. Native support by a map editor would do wonders for Eternity, and I think it's high time the ordinary mapper discovered some of its capabilities.

I'm also not a fan of the line anti-aliasing, and I also don't like the new 'button-like' look of THINGS either.

[Graf Zahl]

AlexMax said:

1. Eternity Extradata

2. Allow the user to specify a working directory for the testing executable, so Chocolate Doom will actually work.

3. Eternity Extradata

4. Eternity Extradata

5. Eternity Extradata

Seriously, other than that small little problem with Chocolate Doom, I have no need for new editor or any other new features. Native support by a map editor would do wonders for Eternity, and I think it's high time the ordinary mapper discovered some of its capabilities.

If any editor were to support Extradata natively you can bet that other ports would adopt it as well. In absence of a new enhanced map format it's certainly the best option around at the moment.

[Quasar]

CodeImp and I both agreed that ExtraData is too difficult to implement in comparison to a pure 100% textual map format, since the former requires hashing of records and doesn't have guarantees such as one record per map entity or data integrity.

A text map format would simply define all things, linedefs, sidedefs, sectors, and vertices in text format (the BSP, blockmap, and reject haven't been considered at all so far).

We ran into a sticking point where we do not agree as I was specifying the format. CodeImp wants binary flag values specific to the Eternity Engine, whereas I want text-format flags similar to those used by BEX, EDF, and ExtraData, where each flag is a symbolic name that can be translated to the appropriate binary value by the implementing source port. I would also like to do something similar with specials, having them given by name rather than number.

All of these things would involve relatively simple hash tables or linear lookup arrays for translation, information that is in some cases already part of the source port's DB configuration (and that which is not would be fairly trivial to add). They would remove implementation dependence from the map format.

This is similar to and is based off of some of the discussion that previously took place on the forums in the "32-bit map format draft" thread which, after appearing like it was making fantastic progress, devolved into religious arguments over crap like map lump names, C syntax vs. Windows CFG syntax, making it unnecessarily friendly for hand-editing, what kind of comments should be supported, how to specify RGB values (despite the fact that no fields in the basic specification require them for any purpose), etc.

I decided to stop pussy-footing around and implement something close to the specification that was put forward there before it rapidly disintegrated into something that I couldn't support using the libConfuse parser.

IF CodeImp and I can come to an agreement on names vs numbers and text flags vs binary bits, then this new text-based map format is as good as finished. If we cannot, then I'm afraid it's probably a dead avenue of discussion.

[printz]

Quasar said:

IF CodeImp and I can come to an agreement on names vs numbers and text flags vs binary bits

Perhaps you could send him the code for reading/writing Extradata.

[Quasar]

I made some changes to the specifications which make the syntax tighter than ExtraData, at his request. For example, semicolons are required for terminating assignment expressions. The idea is that with those changes, he can parse them using his existing parser.

In the event that's not possible, I could provide a library which reads the format, which would be useful not only to DB but to any other source port that wants to implement the map format. Caveat? The library would be in C++. I don't know C# and I have negative motivation to learn it. C# can call C++ code, however, quite simply.

I really think dialogue -- reasonable dialogue with input from people to whom this actually matters -- needs to start on this subject again.

[Graf Zahl]

Agreed. Anything that can produce some progress will be appreciated. The most important thing is that an editor programmer is in.

[RTC_Marine]

Quasar said:

textual map format

As in, xml based?

[Fredrik]

RTC_Marine said:

As in, xml based?

As in, overkill? I hope not. A simple csv or ini style format should do the job.

[Graf Zahl]

XML fails one of the most important requirements for a map format:

It's not easy to parse.

[CodeImp]

Quasar, if you care to write your own Map IO class in DB2 (here is an example for the standard Doom format, all the class basically does is construct a MapSet from file data or write it back) then I guess you can have your text-based format (but I still think binary would be better :P) then I don't have to deal with it :P

I am still willing to continue this new map format debate, but I really don't have time to sit down in an IRC channel and discuss this for hours. Discussing this on a forum would be nice, but it would have to be a closed one where only a few people are involved.

[Graf Zahl]

CodeImp said:

(but I still think binary would be better :P) then I don't have to deal with it :P

With a binary format we hit the next crippling limitation sooner rather than later. Text has the huge advantage of being completely open to extensions. Binary requires some data structure that eventually will impose its own limitations of what one can do.

[Yagisan]

Graf Zahl said:

Then they have to fix that. There's some WADs out there that do use compressed sidedefs, even for Doom.exe (e.g. Cleimos IIRC.)

I believe we did fix it. As I understand the new maploader it unpacks all the packed sidedefs. Its shaping into a very nice limitless loader.

As for a text based level format - you'll need to really sell it to me, as the only tools on my platform don't speak it, and as nice as DB2 is looking, it really doesn't build under mono in linux (that didn't stop me from trying).

[Graf Zahl]

To be honest, right now I don't care at all that DB doesn't work on Linux.

Development for this has to start somewhere and without an editor developer on board it won't go anywhere. One a framework has been developed that people can use to implement it that problem will resolve itself sooner or later.

And if both Eternity and ZDoom start supporting this other ports will follow so naysaying it outright just because you feel left out right now is somewhat shortsighted.

[Yagisan]

Graf Zahl said:

To be honest, right now I don't care at all that DB doesn't work on Linux.

Development for this has to start somewhere and without an editor developer on board it won't go anywhere. One a framework has been developed that people can use to implement it that problem will resolve itself sooner or later.

And if both Eternity and ZDoom start supporting this other ports will follow so naysaying it outright just because you feel left out right now is somewhat shortsighted.

No, I certainly don't have to follow. I certainly don't think the ZDoom way is the one true way. You want an editor developer on board, he needs to see the ports want to use it. I as a port author, don't want to use it.

As for DB2 building on Linux - I tried to see what it needs to actually work. Perhaps in future mono may implement the missing features that prevented it from building, until then, I have Slade and Deutex to work with.

[chilvence]

I don't know if theres much room to argue about DB being a windows app - I've pretty much accepted that from the beginning.

Its just a shame that by using Windows libraries, it has to be paralysed in windows territory, something that isn't an issue with any cross platform stuff.

So don't blame CodeImp, blame the culture.

As for the extended map format, its something that should be considered before the editor is even built, and by anyone who might be interested. Not just a few people with outspoken opinions on the subject. In the end, if you design it behind a wall of silence, then people who actually make maps are eventually going to think of something they wish they could have had, when it is again much to late.

[Graf Zahl]

chilvence said:

In the end, if you design it behind a wall of silence, then people who actually make maps are eventually going to think of something they wish they could have had, when it is again much to late.

Not necessarily. A properly designed text format can easily be extended by new information. And once the framework is in place, adding editor support is just a minor addition to the source for simple properties.

As for the whole Windows/Linux debate, can you please leave that nonsense out for now?

The fact is that this needs CodeImp's support if it is ever going to work out. Without him it's doomed to fail, regardless of which OS's his editor supports.