• Content count

  • Joined

  • Last visited

Everything posted by Mordeth

  1. Holy fucking hell, it's prower. Welcome back, mate!
  2. Thing_Spawn: So the question is, are you mapping in UDMF format or not?
  3. Um, yeah, you can build a skyscraper with each floor having windows right above or below the one in the other plane. And you can attach different portals to the lower, middle and/or upper part of a linedef (using edge portals). Disclaimer: talking strictly about Eternity's original implementation. I don't know how zdoom does things. This is solid advice. Use the regular level geometry to your advantage. This is another advantage of portals: it's actual level geometry, with all the usual rules, while 3D Floors are placed afterwards in a sector already rendered (the overdraw issue mentioned above in the video link). But like said before: both have their uses and strength/weaknesses in a given situation.
  4. Why not? Not sure what you mean by 'windows', though.
  5. I've spent some time exploring the EE-UDMF mapping format. It offers some more options for polyobject portals in particular that EE-DOOM format just does not provide. While seeing this stuff in small test setups makes you all giddy, it mostly is still too iffy to use in actual maps. Too many random visual / gameplay glitches, especially near other portals. Still, this stuff looks promising especially for a WIP... I wonder where the EE devs will be able to take this.


    Part of the experimentation included the manual conversion of a smaller level to EE-UDMF format. Whelp. I sure do not look forward to the absolutely enormous task of doing the same for the other, much larger levels. Will probably have to write my own custom tool in order to keep myself sane during that process.


    Not that I'm switching right now. There's no reason, yet.

  6. The only limitation (EE) portals have is the available mapping space in your editor of choice. Moving polyobject-portals are currently still a bit iffy. For "open world" levels your best strategy is to approach the level as a cake. Each layer represents 128-192+ units of height, and you try to fit your map geometry in such a way that it makes the most use of these 'default' portal layers. The more layers you use, the smaller your level will have to be since you're using up the available mapping space. For details (mostly in buildings) you can use additional portals. For furniture-like details, you can use edge portals to great effect. Only geometry that requires lots of different 3D heights (such as 3D stairs) are much easier to set up with 3D Floors.
  7. What gzdoombuilder did for some stuff (eg action + argument), is to expand on the searchbox field in the search window (F3). So a proposed UI would be the ability to put in for the eg tag field "10" something more like ">=10 && <=15". Much more important is to ability to search for custom fields. This is now completely missing (in any editor) and can't be seen unless you bring up the editor box for each individual sector. So things like selecting all the sectors affected by portal id = 10 becomes an absolute nightmare in UDMF format. Although leaving this functionality to plugins is fine. In DBX, a highlighted sector is highlighted by a (default) yellow gloss over its bordering linedefs. GZDB does this yellow gloss for the entire sector surface, but only a linedef border highlight for a broken sector. Also: you mentioned GZDB visual mode and normal DBX visual mode. Despite setting the shortcut key ( Q vs W) the GZDB visual mode never activates (both in ee-doom as in ee-udmf map format) while normal visual mode works as expected.
  8. There's a program called "doomword" that let's you create graphics with words in doom-style font. It's what I use, at least.
  9. Same as gzdoombuilder then. Problem: gzdoombuilder used to compress similar sidedefs regardless of tag presence which, as you can imagine, broke a lot of stuff. Maxed added a flag to prevent it packing sidedefs containing any tag. Feature request: ability to search for linedefs/sectors with a certain tag range. Eg. select all linedefs with tags between 50 and 60. Feature request (UDMF): ability to search for values for a linedef or sector's custom fields. Feature request: when highlighting a sector in sector mode, use floodfill for the highlighted sector and a border highlight for a broken/unclosed sector. Yes, just like gzdoombuilder. This helps greatly to quickly find these kind of errors.
  10. Does DoomBuilderX also use sidedef packing, and does it take into account not to pack tagged sidedefs? See this issue.
  11. Mordeth E2 does not need to be revived, because it is still in active development. I occasionally mention what I'm currently working on in my status updates, if you're interested.
  12. Don't make a Doom level for other people. Make a Doom level that YOU want to play. Once you stop worrying about what other people might think, you won't feel this restricted.
  13. It's been a while since my last status update. Progress has been slow these last months. That's not to say nothing has happened. Some key areas in E2M3 are finished now; the final outdoors area is still waiting completion. You may have been the latest screenshot I posted on the "what are you working on? I wanna see your wads" thread.


    The rest of the time I've devoted to purely technical issues... like better textures; improvements in scripts, research... stuff like that.


    I will probably abandon E2M3 for a while, and focus on E2M2 next. That map needs some love desperately.


    My advice? Never do "filler" stuff, just for the sake of "being done". You know it's not up to par, and you will just end up replacing it anyway later on. Or worse: releasing it as is. If you don't feel creative enough, just don't open your map editor. It will still be there when the inspiration finally hits you.

    1. bzzrak


      How many maps will E2 have anyway?


      ...also sorry for sounding snarky, but you became a meme in the community for not doing filler stuff for the sake of being done

    2. Mordeth


      @bzzrak : There are currently six maps pretty much committed to inclusion for E2. In addition, there are lots of different map parts and other experiments lying about, which may or may not make it into new levels. At this point it's not likely that will happen: they are either being moved to a different episode for a better thematic fit, or they just don't bring a new idea or setup to the table that you haven't already seen used in the maps already committed.

  14. Really? @Tea Monsteris a professional, who needs to devote his time and skills to do this project right. Compensation is not a perk, but outright mandatory. Otherwise he's better off spending this time with his actual job. Have some respect for the guy.
  15. Yes, I would like high-resolution versions of the original sprites. But if you intend to commercialize that, Bethesda's lawyers would very likely step on this promptly. You might want to contact them beforehand to find out their stance with people trying to make money using their IP. In case you missed it: a few weeks ago the creator of Brutal Doom was also contacted by Bethesda about his Patreon. In his case, it was sufficient to rephrase his Patreon objective as seeking funding for modding, and not for actually selling a Doom mod.
  16. As long as you declare your array a certain size, those values are initialized at start. You can add values in-game with a script as usual, up to the declared size. But you cannot resize your array. Be careful: if you have more than one script updating/reading the same array, you will run the real risk of experiencing race conditions. You cannot control which script will run first within a given tic. If the values in your array are meant to convey information about a Thing, you're much better off storing those values in that Thing's COUNTx properties instead.
  17. A game's underlying theme tends to reflect the times it was created in. They comment on the current times, often without intent. Early midst Cold War games like Asteroids just featured endless waves of progressively more difficult enemies. The goal was to last as long as you could. But, in the end, you lost. Which kind of reflected the attitude of the times, that this Cold War had no other outcome than inevitable nuclear World War 3. Then came games that had an ending, and an end boss. You could defeat it, and actually win. Then came the games where you won, despite the world being a dystopian future. Current games still have an endgame, but have you question your own morality. Because the people who created those realized that, yeah, their nation might very well be the baddies.
  18. UDMF, the map format, doesn't do anything. It's up to the supporting engines to add new features. Before UDMF, new features often had to rely on crutches in order to implement them because the map format did not allow for some stuff. Eg. Eternity needs ExtraData to add info to things / linedefs that are not possible to add in your normal editor under normal Doom format. Changing from Doom to UDMF format simply allows the modder to skip those extra steps and WAD lumps and add this information to the map itself. The player will not know the difference. For example, if I want to open an door after a specific group of monsters die, I'll need to use CLED to assign a dummy flag to their specific editor sequence number which ExtraData can pick up and use to add a TID to that group. A script can then monitor that group and open the door if they are all dead. With UDMF, I can add that TID directly without the need for CLED or ExtraData. So what you are really complaining about, is the fact that source port keep adding advanced features that, in your own opinion, don't match Doom. And that's a completely different discussion.
  19. A while ago I removed stock Doom2 texture definitions from my M:E2 TEXTURE1 lump, since it got kinda big and cumbersome with these three different episodes in the making. PNAMES still contains everything. In this custom TEXTURE1, only modified or completely new textures are thus defined. There are also new graphic patches for stock vanilla textures. First there seemed to be no problems, as long as the first entry was still the dummy AASHITTY texture. A few weeks ago I noticed that some stock Doom2 textures (notably the brown ash walls in vanilla MAP01) were still missing in-game. But not all stock Doom2 textures, even if those textures were no longer defined in my custom TEXTURE1 lump. For example, the entire start area of MAP01 rendered just fine. GZDoombuilder also did not seem to have a problem. Just some textures went poof in-game. Perhaps the inclusion of new graphic patches for vanilla textures is somehow causing some problems in processing down the line..? Renaming my TEXTURE1 lump to TEXTURE2 solved this problem, and I can use/see both stock Doom2 textures as well as my new or modified ones. Using Eternity Engine, naturally. So basically, I do not see the issues @Linguica just mentioned. Unchanged TEXTURE1 stuff is still there; modified (in graphic/dimensions) TEXTURE1 textures now in TEXTURE2 also display fine.
  20. Just removed your flashing gifs from your posts and avatar. Please refrain from doing so again.
  21. After many, many iterations I've finally settled on this layout for connecting two parts of E2M3 together.
  22. There are zero EE Hexen maps, since its support is not finished. You may want to talk directly to the EE devs if you have questions about the udmf specs.
  23. I usually run a recent drd team development build. The recent Heimdal 2 release (3.42.03a) already had UDMF support, but the development builds had some kinks worked out and more features added.
  24. Your go-to wad here would be the Vaporware demo level.
  25. And here's an example level. Tested with PrBoom (2.5.0) and latest EE. The red floor sector is tagged secret; the blue floor sector is normal but turns red & secret after hitting the switch. Just tested with GZDoom g2.3pre-292-g747b612 (lol) and ZDoom 2.8.1 and the secret tag is not transferred there.