kb1

Ok, that makes sense. Heh, got you. Competitiveness is the whole idea around Deathmatch - that was Romero's influence on Carmack, to let people kick each other's asses :) Good stuff. See, I think that could translate to online ports, like Zandronum, as an example. I think your point about only 20% of players getting to a certain point could be helpful for mappers, so they can fix their maps. And the maintainers of the servers might get some use out of stats. I could see how it could be helpful. I didn't mention my full idea. I've been thinking about Compatible Player files. The idea is that, if source port devs get on board, we could design a compatible player file format: This file would probably be a PWAD, and it would include: Player's name Optional Skins Desired control setup, so if you like WASD, you can use WASD in each port you play, just by loading your Player file. Other player options (always run, freelook, etc.) Possibly: Unique player identifier hash, from the server, tied and hashed with user login info Achievements, encrypted, checksummed, and hashed with the unique player id The user selects one of his/her player files (maybe the server has some default files to choose from). Then, the player locally customizes their player profile file. This file is sent back and forth, as needed to sync with the server and other clients. Maybe the achievements stay on the server, in a database, or a folder with player files. This could work locally, or via internet. What's cool about it is that, once you setup your player, you can use that profile everywhere you go, in every port you play. I think it's possible to store some of those achievements locally, encrypted in a way that would make it very difficult to hack. And, of course, if the server holds a copy, the achievements can be checked, and tampering can be detected. I'm not sure what the entire scope of it is, but I think it could be a cool thing to do. Again, thoughts?

Everything I've seen of Joe Rogan tells me that he's an interesting, smart, knowledgeable guy. Why don't you like him? (Just curious). I'm really looking forward to this interview!

Very out-of-the-loop, unfortunately. For me, internet access is limited to my work, currently. So, yeah, I'm pretty clueless about it. That's why I asked :) At this point, I can't tell if the achievements are goofy, or something that's pretty cool. I could see them being interesting in a multiplayer web situation, where other's can see your achievements, but, in a local single-player, co-op, or even deathmatch mode, does anyone care? Most of the achievements are single-shot: Once you get the achievement, it never appears again. If achievements reoccurred, I suppose some point system could be attached,, showing everyone that your Billy Badass. I guess that could be cool. I don't see PWADs getting much achievement love. That's what bothers me about the whole approach. However, it could be possible to add achievements to PWADs, if the source port would read a lump...say ACHIEVE. This lump would let you define certain "alarms" that the source port would look for while you play. These alarms would trigger based on some condition: "Kill 2 monsters with a single barrel". The ACHIEVE script language would be a bit tricky - it would have to parse and understand lots of conditions, and the source port would have to be able to check for those conditions in real-time. Now, that might be interesting. A lot of work, but interesting. But, because I don't have any experience with the concept, I'm hoping that some people will comment, and maybe educate me on the subject. But, really, I just want to know if people find the idea interesting for PC ports

I kinda got that - that's why I said it like I did :) But, either way, the map 30 mandatory telestomp gets the victim out of the way, so the new monster can spawn without being stuck. Without mandatory telestomp, what's the alternative? Does the player get stuck inside a monster? Maybe this is more appropriate: if ((mobj.flags && MF_CAN_TELESTOMP) || (gamemap == 30))) { Stomp_em; } I suppose, as an alternative, you could just not spawn the monster. What I'm saying is that, in boss cube maps, you have to handle the stuck mobj issue in some manner...2 bodies cannot occupy the same space...or, at least, it sucks when it happens. Carmack's map==30 solution was flimsy and hard-coded, but it did solve the Doom2 map30 problem. So, I'm curious: What does k8vavoom do on map 30?

Can you elaborate? What kind of flag are you describing? What do you mean by that? Does the port prevent v1.9 demos from being recorded? Does it force PrBoom+ to write PrBoom+ demos only when the UMAPINFO flag is set? If so, that sounds like a solid plan. What we don't want are v1.9 demo files being generated that don't play in, say, vanilla, or Chocolate Doom, etc. In other words, if the demo is stamped "19", it must be compatible with some version of vanilla 1.9. The situation is already messed up, since a 1.9 demo could be from Final Doom, Ultimate Doom, etc. Id Software should have changed the version number when they altered the game logic, and released different versions of 1.9. So, it's already a mess...and we need to make sure that we don't create a bigger mess! PrBoom+ demos contain a footer that has lots of info about the loaded IWAD and PWADs, game settings, etc. Maybe the UMAPINFO flag could be added there (it's not strictly necessary, since the loaded PWAD contains the UMAPINFO lump.) KBDoom demos contain the loaded WADs, as well as MD5s for each WAD, which would ensure that the exact WADs are properly loaded. I don't know if PrBoom+ does this. Anyway, Graf, it sounds like a nice, proper implementation - good job! It would have been easy to implement badly. I appreciate your diligence and your approach.

No reason you can't have both checks. Useful if you support a "vanilla mode": if ((mobj.flags && MF_CAN_TELESTOMP) || (vanilla_mode && gamemap == 30))) { Stomp_em; } ...if you care about such things.

I guess I'm not hip... I assume Ling is being silly with these...or, does some port actually track these achievements and display them, somehow? And, is that something people would like to see in a source port? (especially in web multiplayer environments) I suppose that some image appears on the screen: "Achievement! bla bla", which updates either a local file, or an online player account. I suppose it could be cool, if done right. Thoughts? EDIT: I see the XBox Achievements page, and the DoomWiki Achievements page. Is it worth tracking achievements in PC ports? It looks messy, as it depends on which WAD you are playing, meaning that it could be possible for map makers to add achievements in their maps, if the source port supports that kind of thing. Again, thoughts?

Technically, PrBoom+ should not allow the recording of a Doom v1.9 demo when interpretting UMAPINFO. The idea is that a 1.9 version demo should be able to be played back in vanilla Doom. That provides 3 choices for PrBoom+: Record the demo, but apply a different version number. Disallow the creation of a 1.9 demo, and force a PrBoom+ demo. Record a v1.9 demo, and disable UMAPINFO. Entryway worked pretty hard to prevent the recording of v1.9 demos anytime a non-vanilla option is in effect, so that effort should probably be continued.

In vanilla, there is a check for map number, in PIT_StompThing.

Apparently, 29-33 is as fast as your PC can update the game state and render the screen. Switching to a lower resolution is the easiest way to increase the frame rate. Complex scenes can also slow down the renderer.

No apologies necessary. Please, take your time. For a few posts there, we were going back and forth frequently...so I was a bit thrown when you didn't reply - my bad. I don't envy you, chasing bugs. It's the type of system where it's tricky to even know that you have bugs, not to mention trying to track them down :)

Sorry Fraggle. I wouldn't have answered so completely, except that the fact that your smooth weapons mod works within a demo-compatible vanilla-compatible way, without requiring new frames, seems relevant. Knowing what it took for you to get it to work makes it that much more appreciated and interesting. Translation: Fraggle carefully scoured Doom's frame table, looking for the frames that were least likely to be missed, and re-purposed them as extra weapon frames, thereby providing smoother animations. Frame timings were also very carefully adjusted, so vanilla demos would stay in sync while also showing the smoother weapon frames. Finding these extra frames is non-trivial, and Fraggle also made a tool that can be used to make finding these frames easier. I'm not 100% sure, but I believe that the Smooth Weapons mod demonstrates the upper limit of what can be done with frames, while remaining in perfect demo sync. Nice job!

Well, the game is supposed to present a challenge, after all.

There is a specific space in the executable allocated for the states that were hard-coded in the info.c source file. On both sides of this table are other data structures and/or executable code. Now, in a source port, you can add as many states as you want to this structure. But DeHacked can only modify the original executables. *However*, if you're really good at machine language, it might be possible to relocate the table, either by hacking the DOS .exe file format, or by inserting a small bit of code that would copy the table elsewhere. Also, you'd have to update all pointers to the table, to allow the executable to find the data in the new location. If you could accomplish all that, you could then extend the table with new states. You'd also have to modify DeHacked to allow it to edit the data in it's new location, and to be ok with there being more states than usual. But, there's more than just frames. For completely new content, you'd want new space for frames, thingdefs, spritedefs, sounddefs, etc. It's a ton of work. It was reasonable to make a tool like DeHacked, to provide a way to edit these preexisting tables. DeHacked simply needs to know where the table starts in the executable, how big the table is, how big each variable in a frame is, and what its purpose is. DeHacked simply provides a GUI for editing this table (which involves simply changing the numbers in the table in a meaningful way.) But adding new space to the table would require everything after the table to be pushed to a new location, which messes up thousands of pointers that expect everything to be in its original place. Practically speaking, it's the job of a source port. Many ports have removed the hard-coded data table, and they read it in at run-time as data. Because the source code is aware of this, moving that table around in memory is not a problem. My home port, KBDoom reads the state data from KBDoom.WAD, for example. Other examples include Eternity and ZDoom, to name a few. ZDoom reads and parses Decorate lumps to build the frame table dynamically. These ports can add new frames at will. But, even if the source port retains the hard-coded data table, it's easy to simply add some new states to the end of the list. DeHacked was originally designed to make changes to Doom(2).exe. But, since the release of the source code, many source ports can read DeHacked data, and, instead of modify their executable files, they modify their in-memory copy of the frame data at run-time. These source ports could add a chunk of empty frame data at the end of their in-memory frame table, and then modify their DeHacked parsers to support higher frame numbers than usual, to access the additional frames. Of course, the question becomes "How many frames should be added?". If the port is not loading the frame table at runtime, it must hard-code a *reasonable* number of frames (and hopefully also thingdefs, spritedefs, sounddefs, etc). And, adding empty space does consume memory, so there's a bit of a conflict of interest. I think Doom II's frame table has about 1,000 frames. Monsters need somewhere around 25 frames for walking, fighting, pain, death, and xdeath frames. So, by adding 1,000 blank frames, you might have enough space for 40 new monsters or so. Of course, you also need 40 new thingdefs, 40 new spritedefs, a few dozen new sounddefs, etc. I was discussing this while considering CDEX (Compatible Doom EXtensions) - a protocol where port devs agree on a compatible way to extend Doom past Boom/MBF standards. Part of this was to consider a compatible way to define things/frames/sounds. Then I got bogged down, and I still have a nearly completed draft that I haven't been able to find the time to finish. But, I'm still convinced that the best way to extend the frame table is for source ports to build their frame tables dynamically, using a frame/thing definition language. I vote for a generalized Decorate-like syntax. Decorate has seen the most success of any thing/frame language in Doom. At one time, I too wanted to have ports add blank frames. But, since it won't work in vanilla, it seems like a half effort. Why not go all the way, and actually be able to define all the frames needed?

20+? All of them. Oh, since Quake 1? My statement didn't chop his career in half. Go play them and find out - we're talking about opinions here, anyway. Though, I strongly suspect that many of the responses in the thread have nothing to do with gameplay, or fun.