• Content count

  • Joined

  • Last visited

Community Reputation

188 Good

About Gez

  1. Well the simplest is to use a texture editor and redefine the SKY1 texture (you can change which patches it uses).
  2. You also can make it a 3D_middle_texture so that it is only blocking on the visible area but it doesn't block movement above the texture.
  3. It's not the editor that matters; you can't shoot and nothing blocks you in the editor. Tell which port you're using, because that's what determines what features are available to you.
  4. The "first map" when you start a game is the first map of the episode you selected. So what you want to do is to define an episode. It's perfectly possible to have an episode start at MAP33.
  5. If you use MAPINFO you can make the first level anything.
  6. I know you well enough to know that your "I don't want to think about it now" means "I will make sure this never happens". Yes, I did mention two possible approaches for namespacing extra keys, sub-blocks and prefixing. I also cited CSS as an example of language in which prefixes are used. But there needs to be a namespacing mechanism, I don't care which one.
  7. If we use sub-blocks like this: zdoom { blah zdoom options } Then what the engine must do when it reaches the { is skip until the }. It doesn't have to try to validate the content of a block it doesn't know about. Would it be possible that someone messes up in a sub-block and create error message in the port targeted by this sub-block? Sure; but how is that different from making a mistake in an EMAPINFO or ZMAPINFO lump? I remember that the first release of Doom: The Lost Episode had a bogus EMAPINFO definition. One thing to keep in mind is that if someone adds some port-specific fine-tuning, presumably, they should test that it works with that port. Think about what happens when you load something like Valiant in PrBoom+ right now: there is a ZMAPINFO lump that is ignored. PrBoom+ does not try to validate the syntax of ZMAPINFO. There is an EMAPINFO lump that is also ignored. PrBoom+ does not try to validate the syntax of EMAPINFO either. Here the point of UMAPINFO is that it allows to remove the need for work duplication by using the same, universal map definition for every port. There can still be some port-specific fine-tuning settings that will be needed, and for them we want to keep the existing behavior of having other ports just ignore it without needing to have duplicated effort by forcing modders to maintain three or more MAPINFO lumps. Take a community project, where up to the last minute some maps get shuffled between slots. Figure that someone forgot to update, say, the EMAPINFO lump and it goes out of sync with the rest, resulting in the wrong map information because it still says that MAP27 is "The Crushcible" while it has been replaced by "Cyberdrome" or whatever. Now add to this that with UMAPINFO in the picture the errors could go beyond just a wrong title and par time, but also include stuff like wrong boss death or wrong secret exit. TL;DR: without namespacing extra keys, redundant lumps are needed; redundant lumps increase the potential for errors. You're a coder, you know code duplication is bad!
  8. How so? A typo in a core key would be detected by any engine; a typo in a ZDoom section would be detected by ZDoom and ignored by other engines. Makes sense. Alright, let's go look at a real-world, Doom-related example. Editor_keys This is a mechanism by which map editors (DB2 & forks and SLADE 3 so far) can have extra data given to them in DECORATE code. The system uses comments so that these editor keys are skipped over by ZDoom. It's not the most elegant thing because it has to highjack the comment functionality, but it works. Do their existence mean that ZDoom has to handle them? Nope, the only handling needed is to skip them, which it does. Everyone is happy. Let me give you a good example for why extra keys need to be namespaced somehow: we'll go back to your example of a skybox property. There's one for ZDoom, where it's defined by listing the skybox textures in order, let's say, top, bottom, east, north, west, south. Now independently EE comes up with a skybox property as well, but it's an independent implementation that didn't even know there was one in ZDoom and the textures are listed in the order east, north, west, south, top, bottom. With namespacing the extra keys, you get Smart error checking Collision avoidance Infinite extensibility De-duplication of work Without namespacing the extra keys, you get Either no error checking or spurious error checking Potential collisions causing incompatibilities Frozen design or the need to maintain some sort of permanent standard committee Need for modders to maintain three or four separate map definitions instead of just one There are only good things to come from defining a namespacing mechanism for arbitrary extra keys, and only drawbacks from refusing to do so.
  9. 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.
  10. 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! 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.
  11. 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). 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. Yep, because otherwise it shouldn't be called UMAPINFO.
  12. 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. 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.
  13. 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.
  14. You're right, UDMF needs to be renamed into ZDoom Only Map Format. There are two cases here: Map works fine in other ports, and only need the ZDoom-specific options to work fine in ZDoom. 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.
  15. 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.