"UMAPINFO" discussion

[VGA]

As a user I believe basic ports should support MAPINFO and advanced ports should also support their proprietary formats, for dedicated port projects.

 

What is this talk about a new format? Did people ask for it? :D

And what about all the released projects that use the old MAPINFO? You'd still need to support that.

[kb1]

14 hours ago, Graf Zahl said:

So, seeing that the 'enhanced features' thread got talked to death by not focussing on the essentials and I received absolutely *ZERO* feedback on the entire UMAPINFO discussion after my last update, not to mention a profound display of disinterest by other port developers I'd like to ask if it makes even sense to continue with this.

 

I am a bit puzzled. There seems to be some interest among mappers to get a 'better Boom' but nobody who is in a good position to make it happen seems to want to do it and instead stick to the same ancient feature set from almost 20 years ago. It should be said clearly that in this situation it may all just be a waste of time.

 

No, I do not want to see this all go to waste but it's not something I can do all on my own.

 

No need to be puzzled: The developers are waiting on the spec. I am holding back the developers, because I have not yet presented a spec. You said it yourself: "Produce a spec." You're right. Without a spec, every idea is an open-ended, unbounded discussion. By definition, a spec lays out the "specifics", which is the realm where programmers become interested. That big thread served its purpose: To generate ideas. Not to define the spec. Those are two very different things, of course.

 

I am sorry about you not getting feedback. Last I heard, you were changing the format a bit, so you could use your generic parser to parse it. I did not know you had actually done that. But, even if you had, I've not been in a position to use it yet. I have been under the assumption that you would build it well, and that it would work, and be able to be part of my spec. In other words, I have already accepted it myself... :)

 

Let me say this: Nothing is going to waste! Just last night, I replied to you, asking you for some more patience. I told you that I was currently drowning with priority work, and that I am committed to getting this thing done. You don't have to do everything - in fact, I've taken it upon myself to design the spec, and present it, after having pre-vetted it, based on a successful implementation of the first draft, in a copy of PrBoom-Plus, including your UMAPINFO code.

 

I've asked for that thread to be closed, because it is chock-full of ideas, as well as some stinkers too :)

 

I will ask again: Please, please stop saying that you think it might be a waste. I will desperately need your help and support, once I release the spec. I will also need the support of the other devs. Lack of confidence can make this thing fail too, you know?

 

I have no right asking for your trust, but I'm asking...for a little faith, and some patience.

 

10 hours ago, Urthar said:

I've often refrained from posting in the enchanced features thread, since I had no expertise regarding implemention, and I was paranoid of derailing a thread that could possibly lead to 'good things' happening. And UMAPINFO would probably be the most important of those good things, from my own point of view.

 

I did feel the whole scripting discussion was going down a blind alley. Did any mappers actually come forward to ask for it? I have to suspect it's something that's best left to Hexen and UDMF formats.

 

It might be useful to start a private thread amongst source port developers to ask whats the minumum feature set, that everyone is willing to implement.

 

I agree on the private thread thing, but let's wait until I have a spec. This will guide the discussions and allow us to focus on each item better. Maybe I can start a private thread with only a partial spec, like when I have some questions holding back the completion of the rough draft.

 

@UrtharYes, refrain if you wish, but please continue to collect those ideas! I have been collecting and categorizing them. If nothing else, maybe you can PM them to me, if you wish.

 

Yes, the scripting thing got far-fetched. I haven't done enough with Doom voodoo dolls to even understand all the ways they are used. Because of that, I imagine that a very small number of add-on features could make them as strong as is feasible/practical/reasonable in Doom format as they should be. They could never replace real scripting languages, but, for some people, voodoo dolls are all the scripting they will ever do. Because of that, I thought it was worth asking how people use them, and asking for people to tell me what would make them a little bit easier to use. Of course, that blew up on me :)

 

9 hours ago, Graf Zahl said:

 

Agreed. That is, if the relevant ports' authors had even shown more than some superficial acknowledgement.

 

Like I said: The main problem with the whole thing is to get the major ports on board, not discuss theoretical features that ultimately only serve to keep those people away whose support is most needed.

When I made this thread, I decided to have no assumptions, and to promote free-flowing ideas. I wanted to give everyone a chance to get involved, without worrying about the feasibility or practicality of the ideas. This afforded us a few things:

• We now have a set of unrestricted ideas, telling us some of what people want.
• Most importantly, we validated that a compatible enhancement to Boom is a desirable, valid concept.

In my mind, this was Step 1. Because of that thread, I can build a relevant spec, with the confidence that I'm heading in the right direction. Without that thread, I'd produce "kb1's Big Spec of What He Thinks Would be Cool for Doom", right?

 

Programmers want the condensed version, without the hype. That's where the spec comes in. The way I see it, everything that has happened so far, is exactly what should have happened.

 

Having said all that, I think I understand some of your anxiety over such an open-idea-type thread. There are some dangers with this approach:

• Open idea discussion may set up expectations about features that cannot (or should not) be implemented.
• Design-by-committee can be a frustrating place.
• The spec must deal with compromise, to fit well within ports. Less understood is the fact that ports will have to make some compromises as well, to properly follow the spec.

What I take from all this is:

1. The next step for me is to build the spec. Got it.
2. The next step for everyone else is to please be patient, and give me a chance to finish the research, write a spec, write a test app implementing these ideas.
3. Get a private thread going, invite the port (and map editor) devs, and start the technical discussions.

Ok?

 

 

 

[Graf Zahl]

5 hours ago, kb1 said:

No need to be puzzled: The developers are waiting on the spec. I am holding back the developers, because I have not yet presented a spec. You said it yourself: "Produce a spec." You're right. Without a spec, every idea is an open-ended, unbounded discussion. By definition, a spec lays out the "specifics", which is the realm where programmers become interested. That big thread served its purpose: To generate ideas. Not to define the spec. Those are two very different things, of course.

 

Ok so far. But it still worries me that there's almost nothing coming from the Eternity camp. That's not only the case here, I encountered the same problem when compiling a joint ZDoom/Eternity UDMF spec. There was some initial acknowledgement but it seems to be completely on the back-burner.

Ok, I can accept if people do not have the time to deal with stuff (I am facing the same problem right now) but I'd really like to get an idea where things are standing.

 

And not a single word from Entryway what his stance on the whole idea is for PrBoom+. I only can guess that it's not on the schedule.

 

 

5 hours ago, kb1 said:

 

I am sorry about you not getting feedback. Last I heard, you were changing the format a bit, so you could use your generic parser to parse it. I did not know you had actually done that. But, even if you had, I've not been in a position to use it yet. I have been under the assumption that you would build it well, and that it would work, and be able to be part of my spec. In other words, I have already accepted it myself... :)

 

The format was changed to use curly brace syntax, but aside from that nothing has been altered. No new options or parameters. Unless there's bugs the feature should be complete now.

 

 

[TimeOfDeath666]

Graf Zahl said:

That's because I compiled them with the non-XP toolset which gets set by default on modern MS compilers. Will change for the next build.

Any update on this so I can make a wad designed for your pr+ umapinfo port?

[kb1]

14 hours ago, Graf Zahl said:

 

Ok so far. But it still worries me that there's almost nothing coming from the Eternity camp. That's not only the case here, I encountered the same problem when compiling a joint ZDoom/Eternity UDMF spec. There was some initial acknowledgement but it seems to be completely on the back-burner.

Ok, I can accept if people do not have the time to deal with stuff (I am facing the same problem right now) but I'd really like to get an idea where things are standing.

 

And not a single word from Entryway what his stance on the whole idea is for PrBoom+. I only can guess that it's not on the schedule.

 

The format was changed to use curly brace syntax, but aside from that nothing has been altered. No new options or parameters. Unless there's bugs the feature should be complete now.

Please don't worry. When the time comes, I'm pretty sure the right people will get involved. It's going to be a useful thing that mappers want, and ports will eventually be expected to understand the additions, especially for UMAPINFO. It needs to become real, first, which means, again, I need to get off my ass and release a spec.

 

Entryway gave me his blessing to hash out the Boom enhancements, as well as KBDoom functionality into PrBoom+, so UMAPINFO, and, hopefully Boom+ will make it in.

 

38 minutes ago, TimeOfDeath666 said:

Any update on this so I can make a wad designed for your pr+ umapinfo port?

I think what Graf means is that it's ready to roll. (But you might have to compile it...don't know if that's been done yet).

 

[Shadow Hog]

Honestly, the rest of the spec can wait; just getting UMAPINFO in place will already alleviate a lot of limitations, and would be a great start to work forward from.

[kb1]

UMAPINFO is pretty much the first line item requirement, after the prerequisite general Boom support, in my spec.

[Shadow Hog]

Fair enough; I'm just worried about the (alleged?) turmoil in the other thread over getting the rest of the spec going causing this to ultimately end up for naught. It'd really suck to lose UMAPINFO, something I've wanted for as long as I have, over disagreements on the scope for something unrelated, like scripting.

 

I'll just hope for the best overall, I suppose.

[Bauul]

I'm in agreement with the above. I wonder if we'd already have a working UMAPINFO across a range of ports by now if the other thread hadn't disappeared quite so much down the rabbit hole. :)

[kb1]

On 6/24/2017 at 2:05 AM, Shadow Hog said:

Fair enough; I'm just worried about the (alleged?) turmoil in the other thread over getting the rest of the spec going causing this to ultimately end up for naught. It'd really suck to lose UMAPINFO, something I've wanted for as long as I have, over disagreements on the scope for something unrelated, like scripting.

 

I'll just hope for the best overall, I suppose.

That thread was never supposed to spawn disagreements - it was supposed to be for ideas only. And scripting is clearly out-of-scope. This thing's going to happen. It might take a few months to iron out details, as I have limited time to work on it. As long as I don't get hit by a bus, it's going to happen. And, if I do, I can no longer give my word, but someone else can take over.

 

Can I count you in, for, at least, giving my up-and-coming spec a serious consideration, for implementation into your port? (Of course, everyone will be able to tweak it thoroughly).

 

 

On 6/24/2017 at 2:54 AM, Bauul said:

I'm in agreement with the above. I wonder if we'd already have a working UMAPINFO across a range of ports by now if the other thread hadn't disappeared quite so much down the rabbit hole. :)

What is up with all this worry about things not working out, and getting lost because of the big idea thread? I have to stop answering this question. But, since that thread is huge, I'll give it a quick shot, with bullet points:

 

• The spec's first line item is UMAPINFO - that's a guarantee.
• Scripting is nowhere in the spec, other than the slim possibility that voodoo doll "scripting" enhancement gets some manner of consideration.
• I have been culling and organizing the ideas from that thread, this thread, and a handful of other threads. Yet, most of that content will not appear in Phase 1 - maybe Phase 2 or later.
• This thing is happening, if I have any say in the matter.
• At least 2 ports will fully implement the spec: My version of PrBoom Plus, and my main port, KBDoom.
• The major goal of the spec is wide adoption, so if something is keeping that from happening, it will be excised. But UMAPINFO is mandatory.
• The spec may require some slight changes to UMAPINFO, but basically, UMAPINFO can now be used by mappers targetting Graf's version of PrBoom Plus. So, it's already a reality.

[Death Egg]

What else is left to tweak or debate about UMAPINFO? Why not consider that alone "Phase 0" so at least SOMETHING can be introduced that drastically improves both port parity and convenience for modders.

[Graf Zahl]

UMAPINFO is ready. There's a Github repo to test and check it. PrBoom+ could have this available in a day if Entryway just wanted.

 

What's completely missing here is any reaction or feedback from other source port developers. And this is the truly disappointing part. This could be out in a week or two, if there wasn't some profound apathy by the only people who could do something about it. Guess why I have stopped on DECORATE Lite. It's pointless to consider that if the situation remains like it is.

 

The thing is not to write a spec. The thing is to establish the spec as standard. That can only happen if specific people are in. They clearly are not.

 

[Misty]

26 minutes ago, Graf Zahl said:

UMAPINFO is ready. There's a Github repo to test and check it. PrBoom+ could have this available in a day if Entryway just wanted.

 

What's completely missing here is any reaction or feedback from other source port developers. And this is the truly disappointing part. This could be out in a week or two, if there wasn't some profound apathy by the only people who could do something about it. Guess why I have stopped on DECORATE Lite. It's pointless to consider that if the situation remains like it is.

 

The thing is not to write a spec. The thing is to establish the spec as standard. That can only happen if specific people are in. They clearly are not.

 

I would tag source port authors and ask them directly if they agree about new UMAPINFO lump and new standard, if not, we will be stucked in same old formula(and years) or they just decided to wait until something will come. Who knows, if you don't ask, you won't get a direct answer. 

[Xaser]

Send some PMs. I wouldn't be surprised if the only reason key port authors aren't responding promptly is because their eyes are naturally averted as threads in this subforum always turn to mush.

[Ribbiks]

any possibility of a linux/osx maestro taking a look at grafr-boom plus? Would be hype to toy around with the umapinfo additions, but fixing compilation errors is above my pay-grade.

 

Spoiler

Undefined symbols for architecture x86_64:

  "_A_Fall", referenced from:

      _deh_bexptrs in d_deh.o

      _states in info.o

      _A_KeenDie in p_enemy.o

      _A_PainDie in p_enemy.o

  "_FMI_Drawer", referenced from:

      _F_Drawer in f_finale.o

  "_FMI_StartFinale", referenced from:

      _F_StartFinale in f_finale.o

  "_FMI_Ticker", referenced from:

      _F_Ticker in f_finale.o

  "_Maps", referenced from:

      _G_LookupMapinfo in g_game.o

      _G_LookupMapinfoByName in g_game.o

  "_ParseDecoLite", referenced from:

      _D_DoomMainSetup in d_main.o

  "_ParseUMapInfo", referenced from:

      _D_DoomMainSetup in d_main.o

ld: symbol(s) not found for architecture x86_64

 

[Graf Zahl]

Sorry, fixing an autotools project is outside my field of expertise. Actually all that's missing is adding the new files to it but I can't run it.

When I find the time I'd like to convert all the multiple projects for different compilers to a single CMake project.

 

[Ribbiks]

well I got it running (on os x). just had to add AC_PROG_CXX to configure.ac, and all the new source files to COMMON_SRC in src/Makefile.am

 

there was some minor thing about clang not liking stricmp, so in scanner.cpp I replaced it with strcasecmp

 

 

[kb1]

12 hours ago, Graf Zahl said:

UMAPINFO is ready. There's a Github repo to test and check it. PrBoom+ could have this available in a day if Entryway just wanted.

 

What's completely missing here is any reaction or feedback from other source port developers. And this is the truly disappointing part. This could be out in a week or two, if there wasn't some profound apathy by the only people who could do something about it. Guess why I have stopped on DECORATE Lite. It's pointless to consider that if the situation remains like it is.

 

The thing is not to write a spec. The thing is to establish the spec as standard. That can only happen if specific people are in. They clearly are not.

 

Can I be of assistance?

[kb1]

36 minutes ago, Ribbiks said:

well I got it running (on os x). just had to add AC_PROG_CXX to configure.ac, and all the new source files to COMMON_SRC in src/Makefile.am

 

there was some minor thing about clang not liking stricmp, so in scanner.cpp I replaced it with strcasecmp

 

 

Did your changes made it back into the repository?

[Shadow Hog]

23 hours ago, kb1 said:

Can I count you in, for, at least, giving my up-and-coming spec a serious consideration, for implementation into your port? (Of course, everyone will be able to tweak it thoroughly).

 

If I had one, then sure, gladly! But I don't.

 

I guess I used to work on SRB2, but that's not really a Boom-compatible source port anyway. (And they already support their own variant of MAPINFO, so...)

[kb1]

3 hours ago, Shadow Hog said:

 

If I had one, then sure, gladly! But I don't.

 

I guess I used to work on SRB2, but that's not really a Boom-compatible source port anyway. (And they already support their own variant of MAPINFO, so...)

Got you. I could be done, though, you know? (with lots of effort, of course). But, I can respect that it has different goals. I think SRB2 could bring a lot of niceties to Doom, more than the other way around.

[Ladna]

On 6/28/2017 at 4:21 PM, Ribbiks said:

well I got it running (on os x). just had to add AC_PROG_CXX to configure.ac, and all the new source files to COMMON_SRC in src/Makefile.am

 

there was some minor thing about clang not liking stricmp, so in scanner.cpp I replaced it with strcasecmp

 

 

stricmp is windows, strcasecmp is POSIX.  In the build system you have to check for them and define one in terms of the other; you can't just replace it.

[Ribbiks]

yah I'm not an expert at this stuff so I probably shouldn't be poking around as much as I am. From a cursory glance it looks as though the configure script tests for one and (should?) replace it with the correct version based on your system, but it looked like that logic didn't percolate down into the new files.

[Graf Zahl]

The only issue here was a missing include that takes care of the system specifics which I quickly fixed when I tested that code.

 

[Quasar]

I had believed @printz and @Altazimuth were going to handle this stuff. I'm really busy given that I'm now a full-time dev for Nightdive so I've been avoiding these threads until they shifted from debate to a functional implementation. I'll have to talk to the other team members and make sure we're all on the same page.

[printz]

On 28.06.2017 at 11:02 AM, Graf Zahl said:

UMAPINFO is ready. There's a Github repo to test and check it. PrBoom+ could have this available in a day if Entryway just wanted.

 

What's completely missing here is any reaction or feedback from other source port developers. And this is the truly disappointing part. This could be out in a week or two, if there wasn't some profound apathy by the only people who could do something about it. Guess why I have stopped on DECORATE Lite. It's pointless to consider that if the situation remains like it is.

 

The thing is not to write a spec. The thing is to establish the spec as standard. That can only happen if specific people are in. They clearly are not.

 

Mostly not wanting to spend time on idle chatter about this until something concrete is done. You're saying UMAPINFO is done? Sorry for noobish internet question, but where is it linked? Are the fields and their behaviour listed anywhere?

[Ribbiks]

^^

 

https://github.com/coelckers/prboom-plus/blob/master/prboom2/doc/umapinfo.txt

[printz]

Nice. Looks like EMAPINFO so it should not be hard to add to Eternity.

[Altazimuth]

Seems good, I'll talk with the team, see if anything is in that we can't do. Providing feedback as soon as possible is of paramount importance.

[esselfortium]

Looks nice, it will be great to see this in some ports!

 

I have a couple questions:

• Which font is meant by the "HUD font"?
• Is there any plan for allowing sourceport-specific keys in this, so that users are less likely to feel the need to create 18 different mapinfos?