"UMAPINFO" discussion

If I could add a suggestion; would it be too against the spirit of this to add an option for a map to begin as a pistol start regardless of how the previous map ended? "pistolstart = true" or something to that effect.

Share this post


Link to post

I have already noticed that EMAPINFO has some restrictions where I didn't really understand why they are even there, so I went entirely by seeing what was doable easily. A few ideas that didn't turn out to be without problems were tossed out to keep things simple. One of these things was enabling 'nointermission' between maps instead of just in the final one.

 

BTW, there's one thing I'd still like to add, and that is a 'tallsky' property, so a port can choose between regular and tall sky, depending on which they can display. Having seen that BTSX uses different skies for basic ports and ZDoom/Eternity makes this a reasonable addition, so that both sets can be defined in the same lump.

 

 

Share this post


Link to post
11 minutes ago, Death Egg said:

If I could add a suggestion; would it be too against the spirit of this to add an option for a map to begin as a pistol start regardless of how the previous map ended? "pistolstart = true" or something to that effect.

Theoretically yes, but this goes beyond 'trivial changes' so it got skipped.

 

Share this post


Link to post
3 minutes ago, Bauul said:

Things like music, sky, next-level-progression, name, intermission screens etc. are all things that exist in the vanilla game, they're simply hard to manipulate.

Some of them are impossible to manipulate. Secret exits are a classic example, and I think the main reason people started talking about UMAPINFO.

 

If you don't allow such changes, then there's not much point in UMAPINFO. You can already DEHACKED new intermission texts and map titles, and the skies can be manipulated with transfers.

 

Okay, the last one is pretty inconvenient, but still.

 

And I'd argue that "boss death" behavior is pretty vanilla. It's just that, as with the secret exits, it was all hardcoded.

1 person likes this

Share this post


Link to post

@Da Werecat @esselfortium Good points well made.  And having a boss-death function without needing to resort to something that supports ACS (or equivalent) would be pretty wonderful!  I was getting hung-up on the idea of making UMAPINFO non-gameplay changing, but in hindsight I'm not entirely sure why.  Seemed neater I guess?

 

But yes, I agree about the inclusion of the boss-deaths.  Still don't think source-port specific effects should be included though. :)

Edited by Bauul

Posted (edited)

Share this post


Link to post

Hmm, while I have the usual bout of feature suggestions looming on the tip of my tongue (as everyone does), I must say, just the ability to define secret exits alone makes this 110% worth it. I mean, damn.

3 people like this

Share this post


Link to post
38 minutes ago, Bauul said:

Still don't think source-port specific effects should be included though. :)

Once more, with feelings:

 

IF PORT SPECIFIC OPTIONS CANNOT BE SET, THEN IT IS NOT A UNIVERSAL MAPINFO

 

Without the ability to specify port-specific options, what you get is nothing more than a PrBoom+ MAPINFO. It will not allow you to get rid of work duplication as you will still need to include ZMAPINFO and EMAPINFO and DD_DEFNS and who knows what else. Without a mechanism to specify port-specific options, it is not universal because you explicitly exclude any port with its own options.

 

"New! Universal MAPINFO! For every port except ZDoom!"

 

 

 

Makes about as much sense as having a universal map format and not allowing it to include port-specific effects. Or how about a universal character encoding and not allowing it to have language-specific glyphs? If it's universal it's gotta encompass the universe. Anything less is a lie.

Share this post


Link to post

Alternatively, how can it be universal if half the features only work in ZDoom?

Share this post


Link to post

Universal means that every port reads it. Ideally, all the major features you can specify in the lump should work everywhere. Which means you'll probably have to exclude some advanced stuff (and also add some new stuff in the more conservative engines, which is an important reason for this very discussion).

Share this post


Link to post
4 hours ago, Quasar said:

Just gonna note that some of the semantics aren't currently compatible with how EE handles some things, so we'd have to make various changes to fully support it to spec (as opposed to just being able to parse/load it, with some things not behaving in a compliant fashion). I don't have time to sum that up right now but hopefully I can do it later.

Yes, please, when you can do it.

1 hour ago, Bauul said:

@Da Werecat @esselfortium Good points well made.  And having a boss-death function without needing to resort to something that supports ACS (or equivalent) would be pretty wonderful!  I was getting hung-up on the idea of making UMAPINFO non-gameplay changing, but in hindsight I'm not entirely sure why.  Seemed neater I guess?

 

But yes, I agree about the inclusion of the boss-deaths.  Still don't think source-port specific effects should be included though. :)

Don't worry: UMAPINFO does not change gameplay...when you put it in a new map, and play it in a port that reads UMAPINFO. It just helps define that new map's gameplay. But, yes, if you edit an old WAD and add lumps like UMAPINFO to it, it'll probably play different, just as if you added a different map, you know? We can't add functionality without the possibility of it being used in a detrimental way. It just requires some understanding to know when to use it, and how to use its features.

 

Also, everyone please note: This is a bare-minimum, ground-level spec designed for mass adoption. Cool new features can happen, but they will happen when and if we can achieve getting it adopted in the major ports - that's what's most important first. It does no good if port devs do not plan to support it, and in minimal form, there's no technical reason why it cannot be adopted. We don't want to universally define a feature that causes conflicts.

 

Edited by kb1

Posted (edited)

Share this post


Link to post
10 minutes ago, Edward850 said:

Alternatively, how can it be universal if half the features only work in ZDoom?

You're right, UDMF needs to be renamed into ZDoom Only Map Format.

 

 

 

There are two cases here:

  1. Map works fine in other ports, and only need the ZDoom-specific options to work fine in ZDoom.
  2. Map requires the ZDoom-specific options and doesn't work correctly in other ports.

In the first case, it's still universal. In the second, it's a ZDoom-exclusive map that just makes use of the new MAPINFO format.

 

Share this post


Link to post
6 minutes ago, Gez said:

You're right, UDMF needs to be renamed into ZDoom Only Map Format.

 

Well to be frank, let's look at that adoption rate:

  • ZDoom/ZDoom 2.x based
  • Eternity (incomplete & no complete map editor support)
  • ...
  • Uhhhh...

 

You can't really complain about ZDoom being oppressed when it tries to juggle all the balls.

Edited by Edward850

Posted (edited)

Share this post


Link to post

@Gez  I think we're looking at this at different angles.  To me, a Universal mapinfo only contains variables that are universally relevant to all ports that use it.  That's the "universal" bit.  

 

In my (rather simplistic) impression, it'd be used in the following kind of way: I create a limit-removing mini-wad of 4 maps and a secret map.  I want to name the maps, give them music choices and custom skies, define the exits, and end the game after Map 4.  So I write a single UMAPINFO lump that specifies all that, and specify requirements as "any port that supports UMAPINFO".  The player can then choose PRBoom++, Eternity, GZDoom or any other port that supports it, and it works in all of them.  Nice and simple.

 

If I want to create, say, a map that is specifically for GZDoom and uses a load of GZDoom specific features, then I'll just write a GZDoom MAPINFO lump and won't bother with a UMAPINFO one, as it isn't necessary.  Likewise EMAPINFO for an Eternity map.

 

Essentially, UMAPINFO is a "lowest common denominator" lump.  Something so simple, and so vanilla, that every source port from Crispy to KBDoom could implement it without difficulty.  If they want to add custom, port-specific features into their own mapinfo formats, then all power to them, but UMAPINFO should remain simple, pure and straightforward.

 

I totally appreciate this is just how UMAPINFO makes most sense to me, but I'm a mapper, not a source-port author, so I'm not exactly an authority on the subject!

Share this post


Link to post
4 minutes ago, Gez said:

In the second, it's a ZDoom-exclusive map that just makes use of the new MAPINFO format.

You don't really need UMAPINFO for that. ZMAPINFO should be about enough.

 

Maybe you shouldn't compare UMAPINFO to UDMF. The reasons for their existence are different. UDMF was conceived because people needed a map format they could extend in any direction and as much as they want. UMAPINFO brings some sensible extensions to conservative ports, providing a better lowest common denominator.

Share this post


Link to post

I think port-related stuff in UMAPINFO would be pretty universal, anyway, just not as universal. Stuff like nojump and nocrouch could be pretty useful in a multitude of ports, even if not all UMAPINFO adopters would include jumping or crouching. Various other compat options would likely also fit, like the lost soul limit or ghost monsters or other stuff that wouldn't be weird to remove for standard play.

 

There's certainly a point where you'd just start making a port-specific MAPINFO for stuff, but I don't think that's the same point as defining stuff that isn't relevant to all UMAPINFO-supporting ports.

Share this post


Link to post
20 minutes ago, Gez said:

Once more, with feelings:

 

IF PORT SPECIFIC OPTIONS CANNOT BE SET, THEN IT IS NOT A UNIVERSAL MAPINFO

 

Without the ability to specify port-specific options, what you get is nothing more than a PrBoom+ MAPINFO. It will not allow you to get rid of work duplication as you will still need to include ZMAPINFO and EMAPINFO and DD_DEFNS and who knows what else. Without a mechanism to specify port-specific options, it is not universal because you explicitly exclude any port with its own options.

 

"New! Universal MAPINFO! For every port except ZDoom!"

 

 

 

Makes about as much sense as having a universal map format and not allowing it to include port-specific effects. Or how about a universal character encoding and not allowing it to have language-specific glyphs? If it's universal it's gotta encompass the universe. Anything less is a lie.

Gez, don't worry: port-specific stuff is of the utmost importance, and, we will find a way to eventually handle them. But, it should be done properly, which means in an inclusive way, after good research, planning, brain-storming, etc. We're not ready to design the technical specifics of how that support will be handled, though.

 

Many ports have forged ahead, and developed their own solutions (which is good). For compatibility, those ports need to keep that functionality. Now, with Graf's minimal UMAPINFO support, all the other ports can also do some of what ZDoom and Eternity can do...and they will be compatible with each other! This is huge! But it leaves one big issue that you are describing. Yes, it's a problem. Yes, it needs a solution. And, yes, we will collectively figure out what to do, and, whatever that is, will eventually make it into the new specification.

 

Please note, the eventual goal (for me, anyway), is widespread compatibility in the methods of specifying advanced mapping features. Phase 1 will not produce engines that can all do everything. Instead, we are trying to bump up the number of features you can expect ALL enhanced ports to support. In Phase 1, that will include only a few new features. It's a long road, with many obstacles. The question is, "How far can we go?"  :)

Share this post


Link to post

EDIT: I was trying to add to a post, but somehow, I created 2 posts at the same time, but they didn't both get placed at the end. I screwed something up. Oh well, please see both posts.

Share this post


Link to post

Since it doesn't seem clear -- I'm not asking for PrBoom+ to support ZDoom options or vice-versa. I'm asking for a simple, clean way to have ports extending UMAPINFO according to their needs without colliding with other ports.

 

If you have a map that requires an option set in ZDoom, and you cannot set that option through UMAPINFO, then you have to duplicate UMAPINFO by adding a ZMAPINFO lump in addition. And if that happens, then it's a wasted opportunity. It's not UMAPINFO, it's PMAPINFO or whatever.

 

Having a clean way to mark options as belonging to a port allows other ports to skip them harmlessly. The "core" set of feature remains the minimal lowest common denominator stuff, the port-specific options merely allow to avoid having to duplicate the metadata in several redundant dialects.

 

It's like you're opposed to the idea of having something that would be convenient and extensible.

Share this post


Link to post
9 minutes ago, kb1 said:

Gez, don't worry: port-specific stuff is of the utmost importance, and, we will find a way to eventually handle them. But, it should be done properly, which means in an inclusive way, after good research, planning, brain-storming, etc. We're not ready to design the technical specifics of how that support will be handled, though.

Translation: let's not think about it while it's still time to design the syntactic hook, let's come back to it only after things have been set in stone and nobody will be interested in addressing the issue anymore because everyone will have had to grow accustomed to writing one more MAPINFO lump.

 

standards.png

 

I believe we have the opportunity right here and now to avoid the above from becoming true. All it requires is to answer a simple question:

Sub-block, prefix, or something else?

 

It's not like I'm asking you to devise a cure for cancer or design an interstellar probe. I'm just asking for which method will be used to mark extensions. Once this method is chosen, it'll be infinitely reusable.

 

Let's suppose for the sake of argument we go with prefixes. So sure we can have zdoom_foo or eternity_bar, but suppose we get a "Boom 3" standard defined, then it could get also boom3_baz. Stuff that starts as port-specific could become standardized later, without hampering backward compatibility or cross-port compatibility.

Share this post


Link to post

Compatibility stuff is an exception. You can't get more port-specific than that, but it solves differences in behavior rather than creating them.

 

3 minutes ago, Gez said:

It's like you're opposed to the idea of having something that would be convenient and extensible.

Obviously.

 

Well, at least we've established early that UMAPINFO should be the ultimate MAPINFO format eventually superceding EMAPINFO, ZMAPINFO, and everything related. Better safe than sorry.

Share this post


Link to post
3 minutes ago, Arctangent said:

I think port-related stuff in UMAPINFO would be pretty universal, anyway, just not as universal. Stuff like nojump and nocrouch could be pretty useful in a multitude of ports, even if not all UMAPINFO adopters would include jumping or crouching. Various other compat options would likely also fit, like the lost soul limit or ghost monsters or other stuff that wouldn't be weird to remove for standard play.

 

There's certainly a point where you'd just start making a port-specific MAPINFO for stuff, but I don't think that's the same point as defining stuff that isn't relevant to all UMAPINFO-supporting ports.

Ah, hell - I made 3 posts back to back. Oops.

 

@Arctangent: Yes - it may be that some ports simply ignore MAPINFO lines that they don't understand, and, for some fields, that may be ok. It really depends on what each field does. It's going to require lots of research, and maybe the weighing of pros and cons.

 

Here's a bad possible scenario:

Imagine a setting that, your port of choice doesn't understand. It would really suck if a setting allowed a switch to operate, say, a door, that is required for you to proceed. If your engine doesn't understand the setting, the map becomes unfinishable (without cheating). Maybe that's not worse-case, but it's bad. But this could be obvious to the player.

 

I'm sure we could imagine worse possible problems. In support of your idea, if we treat UMAPINFO, and the proposed Boom+ standard as a set of requirements, most of those settings you described are going to be available options in all Boom ports. It's an idea to consider.

 

It's really a moving target: Ports are adding features. New maps are being made. Whatever system we use needs to be robust enough to be aware of these issues, and be extensible. You know, the HTML protocol was designed so you can have, say, an image, but for text-only browsers, they set it up so you could show text where the image would be.

 

Maybe, for port-specific UMAPINFO settings, the map dev can add a fallback setting to use, ,if the engine cannot handle the special feature. Maybe, the fallback is to pop up an error message: "Some map features are not supported in xDoom. Play anyway?". I am hoping my research, and our discussions will provide some ideas. Good points.

Share this post


Link to post

So given we all agree that there will always be unique, changing, port-specific variables that are only relevant to the specific ports that support them, this it seems it really comes down to this.

 

Should these port-specific variables be defined in:

 

A: Their own section of the UMAPINFO lump

B: Their own lump

 

As a mapper, I don't mind which we use.  B somehow seems safer - if you fuck up writing the port-specific lump at least it doesn't fuck up the UMAPINFO too - but really as long as it's clear where the divide is between the lowest-common-denominator UMAPINFO universal variables and the port-specific stuff, then either works.

Share this post


Link to post

Again, all I'm asking for is a mechanism to allow ports to safely ignore certain keys, rather than just silently ignoring all unknown keys (which is not a good thing) or complaining about them all the time (which is also not a good thing).

 

9 minutes ago, Da Werecat said:

Compatibility stuff is an exception. You can't get more port-specific than that, but it solves differences in behavior rather than creating them.

And so PrBoom should be encumbered by the full list of all of ZDoom's compatibility options so that it can know which stuff to skip? No, the solution is a general syntax to have port-specific options.

 

10 minutes ago, Da Werecat said:

Well, at least we've established early that UMAPINFO should be the ultimate MAPINFO format eventually superceding EMAPINFO, ZMAPINFO, and everything related. Better safe than sorry.

Yep, because otherwise it shouldn't be called UMAPINFO.

Share this post


Link to post
2 minutes ago, Gez said:

And so PrBoom should be encumbered by the full list of all of ZDoom's compatibility options so that it can know which stuff to skip?

I don't really care how it would skip the foreign stuff, and I don't remember proposing anything in this regard.

Share this post


Link to post
1 hour ago, Gez said:

Yep, because otherwise it shouldn't be called UMAPINFO.

Perhaps if we'd proposed it was called Basic MAPINFO (BMAPINFO?) or Lowest-Common-Denominator MAPINFO (LCDMAPINFO?), that might have helped us be more aligned?

 

In my mind the universal bit simply means it covers only variables that are universally true of all source-ports, so essentially vanilla things.  Down the line if it truly could be a single place for all MAPINFO variables, then that'd be awesome!  I think just at this point we should nail the universal stuff (i.e. the stuff that's universal to all ports) first, and then look into merging in the port-specific stuff perhaps next?

Edited by Bauul

Posted (edited)

Share this post


Link to post
52 minutes ago, Gez said:

Since it doesn't seem clear -- I'm not asking for PrBoom+ to support ZDoom options or vice-versa. I'm asking for a simple, clean way to have ports extending UMAPINFO according to their needs without colliding with other ports.

 

If you have a map that requires an option set in ZDoom, and you cannot set that option through UMAPINFO, then you have to duplicate UMAPINFO by adding a ZMAPINFO lump in addition. And if that happens, then it's a wasted opportunity. It's not UMAPINFO, it's PMAPINFO or whatever.

 

Having a clean way to mark options as belonging to a port allows other ports to skip them harmlessly. The "core" set of feature remains the minimal lowest common denominator stuff, the port-specific options merely allow to avoid having to duplicate the metadata in several redundant dialects.

 

It's like you're opposed to the idea of having something that would be convenient and extensible.

Fuck, I lost my whole post...somehow I hit the wrong button.

 

Anyway, yes, thanks for clearing that up. I do agree mostly. Please see below.

41 minutes ago, Gez said:

Translation: let's not think about it while it's still time to design the syntactic hook, let's come back to it only after things have been set in stone and nobody will be interested in addressing the issue anymore because everyone will have had to grow accustomed to writing one more MAPINFO lump.

 

standards.png

 

I believe we have the opportunity right here and now to avoid the above from becoming true. All it requires is to answer a simple question:

Sub-block, prefix, or something else?

 

It's not like I'm asking you to devise a cure for cancer or design an interstellar probe. I'm just asking for which method will be used to mark extensions. Once this method is chosen, it'll be infinitely reusable.

 

Let's suppose for the sake of argument we go with prefixes. So sure we can have zdoom_foo or eternity_bar, but suppose we get a "Boom 3" standard defined, then it could get also boom3_baz. Stuff that starts as port-specific could become standardized later, without hampering backward compatibility or cross-port compatibility.

Heh - funny image, and oh so true. I like the block idea. I understand that your concern is "Where do I put my ZDoom-specific mapinfo stuff into UMAPINFO, without having to also create ZMAPINFO?". This is an important point, and maybe blocks will provide this ability. Note that "universal" suggests less to more advanced, and the opposite direction too.

 

Now, let me get this off my chest, and it's not directed at anyone in particular:

Please stop with the grandiose stuff, the sarcasm, and especially the implied accusations...putting words in my mouth - it's pissing me off lately. I AM NOT opposed to any ideas in these threads, and I have not suggested that I am. Please don't make it about me.

 

I am opposed to adding this and that half-baked idea, without studying the ramifications, researching how other ports do what they do, etc. I am opposed to short-term solutions that will cause more incompatibility down the road. I don't think that has specifically happened here.

 

There is a real need for what you are describing. But, please realize that port-specific features, by their very definition, is in stark opposition to the idea of universal support. "Port-specific" is for 1 port, and "universal" is for all, regardless of port. That is the source of any opposition you may have felt from the tone of my replies.

 

Having said that, ports will never agree on everything, and having a "ZDoom" or "Eternity" block allows those type of features to exist, alongside the universal features.

 

I would extend it to support an "Others" block. Something like:

[map01]
levelname = "My Level"
bla = "bla"

Port ZDoom
{
  ZDoom_Feature1 = "abc"
  ZDoom_Feature2 = "abc"
}

Port Eternity
{
  Eternity_Stuff = "1"
}

Port (others)
{
  message = "This map requires ZDoom or Eternity"
}

@Graf Zahl: My syntax sucks, but do you understand what Gez is describing, and do you have a problem with adding some form of this feature to the base UMAPINFO spec? Basically, in ZDoom, you'd pass all the name/value pairs from the "Port ZDoom" block directly into your ZMAPINFO parser, and Eternity would do the same with the "Port Eternity" block. Other ports would read the "Port (others)" block, and interpret those name/value pairs. And a special name/value pair "message" could be used to alert the player, or whatever.

 

Do you think this is a good idea, and can you add support for it, into your source? It will let ZDoom users move over to UMAPINFO, maybe, without having to also use ZMAPINFO, and it should not affect PrBoom and others.

 

34 minutes ago, Da Werecat said:

Compatibility stuff is an exception. You can't get more port-specific than that, but it solves differences in behavior rather than creating them.

 

Obviously.

 

Well, at least we've established early that UMAPINFO should be the ultimate MAPINFO format eventually superceding EMAPINFO, ZMAPINFO, and everything related. Better safe than sorry.

It is actually motivated from the other direction: "How can we get the other ports to do some of this stuff the advance ports can?" But, yes, eventually we want to work both ends, to meet in the middle, or close to.

1 person likes this

Share this post


Link to post

I still think that much of Gez's concerns are too early.

Right now my main concern is not to turn this in to the most versatile and adoptable MAPINFO standard but simply to get it ACCEPTED first.

That's why the current feature set is restricted to the bare minimum that can be safely supported by any port.

 

Once the whole thing has gained some momentum it is time to think about how to extend it.

The main problem with port specific sections is that this makes it hard to implement such options in another port later.

Say, ZDoom adds a 'skybox' property, but one year later Eternity also implements skyboxes. But the key is in the 'ZDoom' section. What now?

 

I think a better way is to have a public list of implemented keys, best grouped into categories by common prefixes, but not block any port from implementing specific stuff of other ports so that the map automatically adapts if a feature gets added later.

In any case, I do not think it's a good idea to expose the entire ZDoom MAPINFO feature set here. If people are out to use advanced ZDoom features, it will no longer be a universal map, thus has no need for a universal MAPINFO. There should be a selected group of isolated options that can be set, most importantly that'd be the compatibility options. But if the feature set explodes to require port specific handling, I think the format has entirely missed its purpose.

 

1 person likes this

Share this post


Link to post

Again: just ignore everything in a unknown sub-block. There. Done. All the port-specific stuff is supported to the extent it should be by all implementing ports.

 

Result: the feature set doesn't explode -- the port-specific stuff is simply not part of the specs, what is part of the specs is how it is delineated so as to be ignored.

 

You set that now and you don't have to think about it anymore ever after.

 

 

Now let's be serious one moment. By its very nature it will not be something that will be used with all the features available in EMAPINFO or ZMAPINFO anyway (e.g. it doesn't cover skill definitions for example), so worrying about that is pointless. However, trying to define a list of accepted specific feature for each port (compatibility options and gameplay-neutral cosmetic stuff) would bog down the standard in pointless enumeration, judgment calls, and soon-to-be-outdated lists. Something that just tells to ignore the following stuff unless you're Eternity or ZDoom or whatever else, on the other hand? Short, simple, to the point.

 

To use a specific example. Someone who makes a Boom map isn't going to use the RandomPlayerStart feature (which disables the traditional voodoo doll stuff and instead spawns the player at one of the many player starts, chosen randomly). Does this mean that if UMAPINFO parses zdoom_randomplayerstart it should error out? No, because that would mean it'd have to maintain a list of unacceptable ZDoom features! We don't want to bother with that! Any white list or black list will grow stale the moment they're implemented!

 

2 hours ago, Graf Zahl said:

Say, ZDoom adds a 'skybox' property, but one year later Eternity also implements skyboxes. But the key is in the 'ZDoom' section. What now?

Well, the EE devs will add the skybox property to their own section specs. If they want to handle existing maps, they may decide to parse ZDoom sections for the keys that they've implemented; that however wouldn't be something they need to do for spec compliance, just something they can decide to do to specifically increase their compatibility with ZDoom features. Eventually as more ports implement a compatible interpretation of the skybox property, it may be suggested to add it to an update of the general standard. For an analogy: in CSS, -moz-border-radius was introduced first, followed by -webkit-border-radius, and after that a border-radius property was added to the core specifications. So likewise there could be a -zdoom-skybox and then later an -ee-skybox and finally perhaps just skybox in a later version of the specs.

Share this post


Link to post

If you haven't noticed, the entire feature set is designed so that unknown keys can easily be skipped. In fact, my implementation just puts them into a global property list. At first I planned to parse everything into that list but it just turned out too inconvenient for frequently checked stuff.

 

These subblocks you propose will end up annoying clutter and only encourage the addition of non-standard features that will water down the whole thing to a pointless exercise. ZMAPINFO could make do without them as well. In fact, it was the addition of this very thing to original MAPINFO that prompted the rewrite. I'll not go the same route again.

 

Share this post


Link to post

If you just skip unknown keys, you remove an error checking mechanism. Suppose there's a "skytxeture" key, if it's ignored the user won't be told about the typo. A way to distinguish between skippable keys and core keys is needed.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now