Graf Zahl

Members
  • Content count

    9816
  • Joined

  • Last visited

Community Reputation

122 Good

About Graf Zahl

  • Rank
    Won the popularity contest
  1. Let's cut this short: Doom format has very limited means to do stuff here because the line type encodes the trigger type, the action and all associated parameters. And with nothing else left, once it's used up, it's over. Only two solutions: - implement UDMF where the range of numbers can be upped to 32 bits, giving a lot more options. - implement Hexen specials (which are only useful with UDMF if extensions are the goal because the one-byte types are nearly used up, too, and need to be handled conservatively) Seeing that Hexen format is not that welcome, it seems like UDMF with Doom format special types remains the only option to get more types.
  2. I know. It was a typo but the forum wouldn't let me correct it because it was inside a [ code ] tag which got converted to something non-editable. Indeed. There seems to be something else preventing proper display. It will work if the proper assets are provided. The crash is simply the result of not finding them (quite unsurprisingly, indeed.) Actually, I haven't tested that particular case. This is owed to the crappy end of game code which doesn't work without a text. Any linedef type that can be activated as a switch or by crossing it should do, this actually worked for me as intended. The tag obviously needs to be the sector tag that should be triggered, like 666 in E1M8, but can be any number.
  3. @Fraggle: I fully agree with everything you said, which is why instead of engaging into those discussions I just implemented the MAPINFO part, and I think for other ideas the same approach is advised. The Github project is there, so anyone who actually is capable of implementing something worthwile is free to send a PR. If it's well designed it will be added. @Quasar: I had a look but I have to admit that I haven't fullly understood what most of this is supposed to do.
  4. It doesn't work like that. Allowing both to be read from the same mod and mixing their definition is the ultimate nightmare implementation. But my concern still stands: Not only is Gez's approach putting a lot more strain on the parser, but before thinking about such stuff we need to get the baseline working and getting accepted! Before that isn't complete it is utterly pointless to think up how to implement extensions.
  5. Obviously adding new actions to Doom format will be easier, the main problem here clearly is that the amount of free specials is finite - do too much or something too specialized and the numbers will be gone in no time. As for adding Hexen format support, I would do this by adding a second set of thinkers that is completely free of any backwards compatibility concerns. It's all those exceptions and special cases that make working with the code such a hassle. Even though this may sound like it is more work, I really don't think so. Such a parallel implementation is far easier to fix because unless there has been an actual release it can be tweaked until everything works. Of course that's stuff for the distant future.
  6. That was precisely my thought about that matter as well. In the end the property's parameters need to obey the same syntax as the basic keys so whether the parser skips a block or just the parameters of an unknown property will effectively be the same - but skipping just the parameters is a lot simpler because it can entirely build upon the base implementation, unlike the block!
  7. Can you please stop this unproductive discussion? In the current state it leads absolutely nowhere! You've been ranting on and on about a technicality here that needs to be addressed once the lump gets universal support. Until that point I won't waste any thought about how to best approach these things because it also requires input from the actual port developers that have to maintain this. Where precisely is your stake in the matter that you are so insistent on this particular way of solving the issue?
  8. Other ports still need to check the section for syntax errors instead of blanketly skipping it, so we're back to square one. The worst thing imaginable is a lump that works with port A and aborts with a syntax error in port B.
  9. 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.
  10. Check your PMs!

  11. OpenGL 2 is still being supported, but with a slightly reduced feature set (i.e. fullscreen color blends like invulnerability are not reproduced accurately. This was done for performance reasons as the accurate method is too slow on the integrated Intel chips that are still relevant when larger resources are being used.) OpenGL 1 was dropped with 1.8.3.
  12. 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.
  13. I was shooting for next weekend but there's a few things left to sort out first.