Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

kb1

Members
  • Content count

    3030
  • Joined

  • Last visited

Everything posted by kb1

  1. kb1

    KBDoom Questions

    KBDoom is a source port I've been slowly working on for many years now. I have not yet arrived at the point where I am comfortable releasing it, but that is the eventual goal. Some people interpret that in imaginative ways, which is why Linguica wisely locked the "What is KBDoom?" topic quickly. Hopefully, he'll get this one too. I only created this thread, to provide a way to actually answer such questions - I hope that's ok. Please send me a PM if you're interested, and I'll try to answer any questions you might have. Here's a quick summary: Philosophies/Goals: KBDoom goals are mix between the various popular ports: PrBoom+, Eternity, GZDoom, Legacy, Retro, DelphiDoom, and others. Each of these ports are innovative, and have something good to offer. It is my hope that my eventual release will also provide something useful to my fellow devs. Some current features: Boom/MBF User-configurable things, frames, weapons, sounds, mapinfo, etc 3d floors Dynamic decals Dehacked/BEX Enhanced automap Strong multiplayer support/Enhanced Co-op Strong vanilla demo compatibility Powerful console Scripting language for game startup Release date: When it's doneTM, of course! :) Honestly, I have no idea. My free time is non-existent, and I have a lot of higher-priority projects to get done. Nowadays, there's not even enough time to get "in the zone", so it's difficult to get any momentum. Therefore, I'm dedicating all my time to completing the higher-priority projects. KBDoom does have some neat unique features, but nothing so important that you're really being deprived by it not being released yet. Today's ports are very capable, and fun to play, and they deliver. Therefore, I will strive to get KBDoom very stable, well commented, clean and polished before the first release. Again, please feel free to PM me with any comments or questions, and I'll do my best to respond quickly and accurately. Thanks for your interest!
  2. kb1

    New Doom port cheevo lists

    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?
  3. 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!
  4. kb1

    New Doom port cheevo lists

    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
  5. kb1

    Things about Doom you just found out

    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?
  6. kb1

    PrBoom+ 2.6.66 (Jun 20, 2023)

    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.
  7. kb1

    Things about Doom you just found out

    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.
  8. kb1

    New Doom port cheevo lists

    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?
  9. kb1

    PrBoom+ 2.6.66 (Jun 20, 2023)

    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.
  10. kb1

    Things about Doom you just found out

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

    PrBoom-Plus, ver. 2.5.1.4

    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.
  12. kb1

    AI research and Doom multiplayer

    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 :)
  13. kb1

    Vanilla Doom smooth monsters? (split)

    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!
  14. kb1

    What is your most hated demon in Doom?

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

    Vanilla Doom smooth monsters? (split)

    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?
  16. 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.
  17. kb1

    AI research and Doom multiplayer

    My new vice: technology excitement!
  18. No, you, Graf, and a few others mis-interpretted what I said...because of your bias. ReaperAA: You fell short of quoting the part of my text ("the man knows games") that explains why I expect most of Romero's games to rock. Here's what I keep hearing in these types of threads: "Dude, you kinda suck...but can we keep playing your video game?" or: "How come I didn't get rich and famous making cool games that everyone wants to play?" heh heh.
  19. kb1

    Vanilla Doom smooth monsters? (split)

    I thought that was first my idea...(not that there's much to the idea, of course) It's a Dehacked limit because it's an engine limit. There are only so many frames that can be changed. The number of frames available is the limit. Sprite animation is achieved when the monster, or shield, or candelabra switches to a different frame, causing a different image to show. Each monster step is a frame. Monsters also have attack, pain, and death frames, and sometimes a few others. Dehacked lets you re-purpose one or more of these frames. The Smooth Weapons project re-purposes a small number of rarely-used, less-important frames to add additional frames to the weapons. A Smooth Monsters mod would require many new frames...but DeHacked cannot provide more frames than are there originally.
  20. kb1

    (great idea) Doom Gun creator

    If you can pull it off, that would be great! And it could be used to generate weapons for many games, including games that use full models. Sorry for sounding discouraging. I just believe that, for high-quality results, it's going to be an incredible amount of work. But there's nothing wrong with that.
  21. kb1

    Your Favourite Doom title ?

    Wow, cool! I used to love these! In my youth, many times, I tried to make "Oblige" for text adventures. In my best version, it could make villages, with houses, shops, pubs, hotels, etc. It had different logic for large multi-room/multi-level structures like castles. Finally, forests, caves, rivers. Each of these used different logic to try to make maps that were laid out realistically. You could navigate these worlds logically (North to enter the building, south to exit, etc.). The big problem was when it tried to build the textual descriptions: glorified Mad-Libs. This technology is just starting to become possible. Anyway, I'll have to check this out. Playing them is almost as much fun as making them :)
  22. kb1

    AI research and Doom multiplayer

    Congratulations for typing the first shit-slinging, time-wasting post in this thread. Other than your post, all indications suggest that the original poster was having a fascinating discussion about a fascinating project, with everyone. You know, I was building systems that analyze incomplete, big datasets, often with opposing conclusions, and make pretty good educated guesses, before neural networks were even an established area of study. That doesn't make me an authority, but it does afford me the ability to speak on the subject at a level greater than an unsolicited "you're wasting my time." If sun_stealer had even hinted that I might be wasting his time with my "visions", I would, of course, respectfully stop posting in his thread. My hopes are that sun_stealer might appreciate some chit-chat about a subject that he was interested enough to post about...isn't that the main reason to post such topics on a public-facing forum? And, in my "vision" post, I finished it with the statement: "I hope that... you find some of this helpful...even if it's just for inspiration". Your post is not helpful, or inspiring. Wow, what a wicked thing to say - what did I do to you to deserve that??? @sun_stealer: Please feel free to reply, as bluntly as desired, in this thread, or by PM, if you'd rather I stop making observations, suggestions, or posting at all in your thread. I will completely understand - no hard feelings, no worries. I will continue to read your thread, however, and check out any source code you might produce, as I find it fascinating, both the concept, and the impressive results, especially considering the relatively short amount of time you've put into it. I do not presume to be knowledgeable of the inner workings of your source, or your methodology, other than what you've revealed in this thread. I have had experience with systems that iterate to make decisions, evaluate the amount of error in those decisions, then propagate the error back through to tweak the interpretation of the inputs used to collectively calculate the next decision. (what a mouthful!) In that model, I've found that the better you can calculate the amount of error, the faster the input bias can be tweaked, therefore, the quicker the AI "learns". I did presume that, because of the nature of your project, you would find such discussions interesting, and maybe inspiring (I know I would, if our roles were reversed). If not, by all means, please let me know. Likewise, please feel free to post, or PM me to discuss anything - if you want to bounce ideas by me, or need a second pair of eyes...whatever. I'm here. Take care.
  23. kb1

    AI research and Doom multiplayer

    @sun_stealer I was really hoping for some feedback on your thoughts about more comprehensive scoring.
  24. Regarding Sigil, sure, there's bias because Romero made it. But, it's also good because Romero made it. The man knows games.
  25. kb1

    (great idea) Doom Gun creator

    Not right now, you don't. The proposal is to split up pre-drawn rectangular chunks of weapon bits and randomly stick them together, with no consideration for centering, scaling, or color-matching, as if they were Legos. That will produce, at best, an MSPaint-looking 3 year-old's rendition of a BB gun. However, a very complex program could achieve better results. Instead of pre-rendered chunks, you could define a drawing language designed to automatically handle rotation, scaling, centering, and color-consistency. A drawing command for a barrel could render, in 3-D (it'd have to be 3-D to do hidden surface removal, handle refraction and shadows, etc), cylinders with small variations and deviations. But before that, you'd build skeletal definitions of how the various definitions should be joined in 3-space (the handle attaches to a trigger, and at least one barrel, further down, optionally with a scope attached. In lieu of really designing the program, let me just state that, essentially, you'd have to develop a program that, driven by a pseudo-random number generator, constructs rough blueprints of each element of the weapon within certain ranges (it can't be 10-feet long, but also it must be big enough to carry). Then the program must "manufacture" the weapon, voxel by voxel. Furthermore, moving parts must be accounted for, for animation, so you must define all possible acceptable movements for a random weapon with randomized moving parts. If you make it that far, you could render the final weapon using ray tracing, and create all animation frames by rotation, scaling, and animating the trigger and other moving parts. For this to be realistic, the program would have to be taught how to build a real-life weapon from scratch, including the ability to execute those plans in 3-space. We're talking about a team of very experienced programmers, artists, and gun building specialists, spending hundreds, if not thousands of man-hours to create a program that outputs a dozen sprite frames - a task that a good artist can do in a fraction of the time, and produce better results. Yes, it would be a great thing to have. It's just not practical to build. By the way, building the Decorate would be a walk in the park vs. the image generator. There's no reason you couldn't build a GUI that accepts certain choices, and generates perfect Decorate code from scratch - that's very do-able...a weekend project to produce v1.0 ready for initial testing.
×