kb1

Members
  • Content count

    1405
  • Joined

  • Last visited

Community Reputation

66 Neutral

3 Followers

About kb1

  • Rank
    Ask me about my source port

Recent Profile Visitors

404 profile views
  1. I'm not in front of the source now, and my memory sucks. P_CheckSight?? But I'm pretty sure the module name is p_sight.c.
  2. It would be better for the spec I'm designing if ports restricted their use to 1000-2047, and left 2048-7999, 9000-12159, and, of course 32768-65535 free if possible. Otherwise, this matches what I've found. How about thing numbers? I don't imagine this will be quite as easy, but some standards have found themselves, like extra player starts, for example, and the infamous camera thing placed by MapBuilder.
  3. I think I misinterpreted what Graf was saying, and furthermore, I wasn't clear with my question. I know there's a "Z" in ZScript. I guess I was just surprised that Graf would consider adding yet-another script engine, for the sake of cross-port support. Naturally, I love the idea, but getting everyone to accept it seems like a pipe dream. On the idea of FraggleScript, from what I read, it seems like a pretty sweet language. I would definitely implement string support. There's a few schemes to minimize garbage collection: Literal constant strings can stay where they are Fixed-length strings could be implemented, avoiding GC altogether. I like allocating blocks of, say 256 bytes for strings. That allows a lot of concatenation of the sizes most likely used in a Doom script: "Player " & X & " did something..." will totally fit in that block, and allow plenty of extra manipulation. If your string grows beyond 256, allocate another block. It typically wastes a small amount of memory, but the GC becomes shit-easy: You don't even need to move the strings - just mark deleted string's blocks empty and available. It's also faster when concatenating if done that way. Defer GC till the end of the map (unless you're running out of memory, which might suggest too much string manipulation by a crazy set of scripts), avoiding the delay But, again, one of the joys of building an engine is in building a script engine to control it - it's something I've been thinking about for a long time. I imagine other devs feel the same. Regardless, however, a standard script language would be sweet...but, far away. EDIT: On second thought: Here's the problem with a universal script language (USL): All ports are different. In KBDoom, I have a thing flag STOP_BOUNCING_IN_WATER, or something (I can't remember right now). ZDoom may have a similar flag, or it may not. If so, it's almost definitely named differently. So, USL must only be able to manipulate the original flags. If you add a port-specific extension to get to the other flags, BAM! your script is incompatible. So, with USL, you're left with simple stuff: spawning a monster when crossing a line, triggering a door to open when a BOSS dies, playing sounds after some universal condition happens (like a monster death, line trigger, or so). Basically original ACS. You end up with a language watered down so much that it's not far ahead of voodoo doll scripting. A Doom script language should be able to utilize all the port's neat features, but a universal script just can't. Short of adding all features to all ports, I don't have a solution to this problem - unless we go for the simplistic language. It's too involved and far down the road for me to consider it just now. I am getting a bit overwhelmed, and need to focus on the first phase.
  4. The HTML Title property of forum pages shows the page number of the first page you visited, not the page you are on. This affects the filename browsers choose when saving a page to your hard drive. For example, this is page 29, and, if I do a Save As on this page, I get "Site and/or forum bugs or things not working - Page 29 - Everything Else - Doomworld.htm" But, if I then click on Page 26, and do a Save As on that page, it still says "...Page 29". This affects me a lot, cause I do my browsing at work, and bring pages home via USB thumb drive. The old forum put the page number at the end of the title, and it was always accurate. Thanks in advance, for your time and consideration. By the way, is there any way (and is it allowed) to mass-download the Doomworld forums?
  5. I'd like to see some info on Doom64's macros. Have a link? Got it: DoomWiki Macros - thanks traversd You're absolutely right: voodoo doll scripting is VERY hackish, and real scripting is the most logical approach. But, here's the rub: Voodoo dolls and conveyors exist, and we have to support them, and people use them for map logic. We have to support it. I have 3 thoughts on this: If a small set of new linedefs allow a Doom (or whatever) mapper, to do some new triggery-type voodoo doll tricks that are easy to implement, why not? Since we have to support dolls and conveyors anyway, it's a simple way to provide some low-level abilities. Some ports will never add scripting, so it's an important thing to support, hack or not. There is a specific case where things on conveyors get stuck (monsters and voodoo dolls mostly). Visually, this looks shitty, and, of course, causes problems, even if your not using voodoo dolls. I want to investigate this specific case, and see what can be done. Yes, messing with the game physics is a bad idea: comp levels, demo sync issues, game feel changes, etc. But, Boom fixed the "monsters get stuck in doorways" bug with a half-dozen lines of code, by randomly bouncing the monster in a different direction. Maybe the conveyor belt problem is similar. Maybe another option could be added: "monsters get stuck on conveyors", and maybe the bug could be fixed. I've seen this bug ruin maps that didn't have voodoo dolls, so it's worth investigating. Maybe a handful of new dedicated script actors could be created, that work like voodoo dolls, without the tie-in to a player. Each actor type could do something besides killing Player 1 when they die. Maybe these actors are invisible. Maybe they call codepointers that let them do stuff. It's not unreasonable to show a little love to the voodoo/conveyor scripters: If it's easy to do, and it allows some neat fun maps to be built with the technology the mapper knows, that's a good thing. Graf, you're absolutely right: Messing with the game physics is generally a very bad thing to do. But doing a bit a research on the "stuck on conveyors" issue is important, and a fix may be ridiculously easy to code. It's worth looking into. Voodoo doll scripting (VDS) is a form of programming, almost like electronic engineering. The voodoo doll is the electron, the conveyor belt is the wire, and the trigger is like an electrical switch. It's a neat concept! I believe it is a stepping stone to actual scripting. VDS is very limited in what you can do with it, which will entice mappers that need more to move on to scripting. It is amazing that it works as well as it does, and I intend to honor its functionality, and even improve it a bit, if possible. None of that interferes with any real scripting, so, why not?
  6. That's great. Let me ask: Is your parser self-contained, like in one module without dependencies? In other words, could I just drop a module into, say PrBoom+, and run with it, or do I need a bunch of modules/libraries as well? (I haven't researched it yet.) Self-contained would, of course, be the best scenario for wide adoption.
  7. I like the idea of using the same parser for most all text lump needs (I understand that DECORATE/LITE needs something more). On the "one size fits all" thing, let me be more clear: So you want to use the same parser, right? If we simply require a header line: type UMAPINFO { } type ANIMDEFS { } The data could *optionally* live in one lump, or in separate lumps, and the parser could handle either one. I suppose, if using single lumps, the lump name could serve as the header line. The data within each type can be formatted however necessary - no baggage. If the type exists, it gets parsed, otherwise not. It's of course easy to support both: A lump, called CONFIG or something, would look like the code box above. The one lump per type version would omit the header, and use the lump name to denote type. Treat this as just a suggestion, for maximum flexibility. This is the route I took with KBDoom, and it's worked out pretty good so far. What's nice is that, with one lump you can configure the whole game (for the most part). Cause, otherwise, we need to come up with different, unique names for all these lumps - all the good names have been taken! Please consider it. It's a logical result of using one parser, so it makes sense to me. It's up to you, though - I'll roll with whatever you think is best. User settings are one of the most unique things in ports. Trying to dictate what settings a port has is against the philosophy of this standard. And, what you describe would make that a necessity. The OPTIONS lump cannot be made generic - it will always be a port-specific thing. I guess what you meant was being able to change the automap colors to match your new palette scheme by using the OPTIONS lump. Personally, I find the idea of a WAD changing my user settings a bit repulsive, in most all cases, with a few exceptions. I could see a WAD dictating if jumping is allowed or not, for example. But I believe that could be done in a more straight-forward way, like a MAPINFO lump, for example. Regarding the palette, it is already user-configurable in a standard way. I do agree that tools to make it easier to work with would be nice, and I recognize that changing the palette affects a lot of things: The menu, for one. Also the automap. But both of those things are also extremely port-specific. This is something that requires a huge amount of planning, and careful execution. I am open to suggestions, but I must say that I am not comfortable trying to squeeze a palette remapping scheme into a Phase 1 spec. There's just too many things to research, and such a change would be difficult to gain universal acceptance for. It raises to many concerns: How would it work with true-color rendering? Custom colormaps? Translucency? Keeping the map and menu readable? Split-screen faked palette flashes? Real palette flashes? Ports that recalculate palette values? To make this universal requires an understanding of how *every* port's renderer works. Scripting is *way* down the line for this spec. Every port dev that wants to do scripting has their own ideas for what would be the ultimate script engine. I have my own plans. But ACS is actually a standard, at least the original Hexen version. To render Hexen, you need an ACS VM (or the ACS needs to be converted at runtime to your favorite script engine). @Graf Zahl Why would you switch away from ZScript? From what I read, it seemed to be rather fully featured. I must say that, to me, it seemed like it requires some pretty advanced programming skills to master, but, at the same time, extremely powerful. Just out of curiosity, did you build it from scratch, or was it a package that you tailored for Doom's specific needs? Either way, it's quite impressive. I believe that the choice of script engine will be the most difficult thing for us to agree on. I've been slowly working on my own language that resembles BASIC with some C syntax for convenience. Eventually it will expose an event model and a set of pre-defined objects. I currently have it working in runtime, interpreted mode, so it not real fast, but it does work. The next step is to modify the interpreter to output byte-code, and to build a VM to execute the code. Eventually I'm going to try to get it to output x86/x64 assembly to build .EXEs and .DLLs, but that's a long ways away, and it's not needed for Doom. A byte-code compiler/execution engine is plenty fast for Doom, and cross-OS compatible. My point is that fully-powerful scripting that has access to Doom's internal objects requires radical changes *everywhere* in a port, and I don't believe we will ever be able to define a spec that all ports will welcome. I could be wrong, though. I would like to study RTS and ZScript in detail though. I also want to see what Eternity is doing, but last time I looked, I think Quasar was switching to a new scripting engine, right? @wesleyjohnsonI can't speak for anyone else, but the only thing making me want to "jump down your throat" is that your taking the stance that your ideas have been rejected - they haven't. I have not put your ideas "down", I've put them into a spreadsheet, along with all of the other ideas in this 13 page thread, as well as the other 6-page thread, and the UMAPINFO threads, the UDMF threads, and a few ideas of my own. You are brainstorming on ways to get Legacy to do what you want, and you are sharing those ideas. This is good. But, please note that I am developing a spec that must not only work well in other enhanced Doom ports, it must also work in ports that support Heretic, Hexen, and Strife. That's the ideal type of solution. I mentioned Hexen, because, yes, it does manage animated switches, so there is a precedent. To be universally accepted, any animated switch spec had just better be able to seamlessly handle animated Doom switches, animated Heretic, Hexen, and Strife switches. Now, you may never want to add support for those other games in your port, and that's your prerogative, which will be respected by the spec. It is commendable that you've found a way to get animated switches to work without a configuration lump - that's a nice feature. But some other ports cannot use this method to satisfy all requirements to authentically, accurately render each game they support. For example, in some games, each switch can have a different sound. Your method does not allow per-switch sounds, right? Requiring the config lump also requires ports to add fields to their structures to support arbitrary, unlimited creation of animated switches with custom sounds, custom timing. But, best of all, the config lump lets ports exactly emulate Doom, Heretic, Hexen, and Strife switches completely, without needing any more solutions - everything is covered. Yes, it is a bit more complicated to have to get the info from a lump. But that parser is part of the spec, and it will be used for ALL text config needs, so it's a one-time cost, that provides access to animated switches, UMAPINFO, animated textures, custom sound definitions, ambient sounds, terrain definitions (for splashes), and everything else I can't think of right now. The idea is that you keep your core engine logic clean of special-case conditional logic, because, instead, everything is clearly defined in the config lump - you simply follow the parsed data as-is. It removes all restrictions on, say, lump naming schemes, hard-coded timings, etc. Everything is user-defined, which is what allows all ports to take advantage of the configuration. The default configuration allows ports, like Hexen ports, to render the switches in a demo-sync-compatible way. None of this prevents you from adding your animated switch scheme to your port. But, if you later accept the spec, you now have to handle 2 ways to define custom switches. Yes, once it is complete, the first rough-draft will be visible to all, in a new thread, available to be judged, picked apart, modified, tailored, and tweaked to perfection. But, this is going to take time: As I have mentioned before, this is a huge project. I am logging, sorting, and cleaning up all the viable ideas in these threads. I have downloaded the Doom, ZDoom, and Eternity Wikis, and studying them. I have downloaded the latest source of all the ports I can find. I am doing my best to study the source of all these ports. I am discussing ideas with developers. I am trying to boil all of this information down into an inviting, approachable spec that takes each ports innovations into account, avoids stepping on anyone's toes, avoids conflicts, repairs inevitable conflicts, etc. Furthermore, I will be implementing the first spec into my version of PrBoom+, to verify its correctness, and to provide a reference implementation. This reference implementation must maintain demo sync, both for old and new demos, and must preserve savegame compatibility. Once that is done and verified, I can confidently release the first rough draft of the spec, complete with fully-commented, working reference source, with key markers in the source making the spec-specific changes easy to find. Once again, your proposal is quite clever, and a good solution for some ports, but I am trying to reach a bigger audience, and provide a solution that works for any advanced port, the same way in each port. That justifies building the "two-ton sledgehammer" once, and then calling *everything* a nail. It's worth mentioning that, yes, ZDoom has excelled in capturing the needs of all of the idTech1 games, with a lot of their config structures. In other words, their methods have been proven to be solid, but some could claim that they were built hastily. We have an opportunity to build a clean method to handle all of the data needed by advanced ports. I don't just want you to implement the spec - I want you to want to implement it, because of the good things it will bring. The fact that you mention animated switches invokes me to realize that we need a universal way to handle them. I appreciate that you've done this. And the same appreciation goes to the linedef discussions, the "Doom2017" plans, etc. The spec will try to implement some of these ideas, if they can easily be supported universally. My hope is that, after implementing the spec, some ports will gain a lot of functionality. And other ports will be able to load those same maps that use that new functionality, even if they already supported those functions. I want you on board with this - I'm not trying to bash your ideas - quite the opposite. Some of the resistance is that your ideas need to be expanded to be sufficient enough to supply the needs for all ports. Do you understand?
  8. Heretic was actually built from Doom 1.2, and it shares some of Doom 1.2 bugs. It was also the source for the faster monster sight code that ZDoom uses, though ZDoom fixed the "diagonal" bug which caused the code to keep tracing out much further than necessary. Carmack added a max sight limit of 64 flat squares, to work around that bug, instead of fixing it!
  9. Ah, well, that's enough power to be able to get the job done, maybe with a bit of stress! I guess I still don't get it, so let me try a different approach by asking these questions: What is the exact result you are trying to achieve? Or, what is the thing you are trying to accomplish that cannot currently be accomplished with the existing combination of lines/actions/things? Please avoid the technical methods you would employ to make it work, and instead explain what you are trying to make happen in the first place! :) Are you stating that voodoo dolls cannot trigger all of the walkover lines that player can? If that's true, I wasn't aware of it.
  10. Here's my attempt at a better explanation: Sector visibility is conceptually a property of the sector, just like top, bottom, and lightlevel. Imagine if we needed a lump MLIGHT to set sector brightness: Everyone would hate it. Sure, it's a simple enough structure to understand, but it sucks to use. In the editor, you want to be able to set sector lightlevel in the same place you set sector top and bottom, right? You want sector lightlevel to come along for the ride when you cut a bunch of sectors, and paste them elsewhere, right? Sector visibility is no different. Inside the engine, maybe it does require edits to a different data structure. But, within a map editor, you want to abstract those details away from the map author, so he/she can concentrate on map making. Internally, using a tagging system, instead of raw sector numbers, allows the map editor program to generate sector numbers any way it sees fit. Internally, the map editor need only copy the data, it does not need to do lookups and fixups on the sector numbers. Furthermore, the map author just sets the appropriate tag numbers once, and those 2 sectors are automatically locked together, through just about any edit possible. And, if one of the sectors disappears, it is easy to check for missing tags, and it's easy for the map author to fix the problem in an intuitive way. You still get all the functionality you wanted, without the limitations - Does this makes sense?
  11. I must admit that, at first, I did not understand what Graf meant when he said that PrBoom was an obstacle, and I fought him about it tooth and nail. But, I now understand that he meant exactly what I've been saying all along: That we should work to standardize all of these differing ways to do the same things. That's the eventual goal of all of this Boom+ spec madness. It's nice that we actually agree - it's much better than fighting :) Again, we cannot make all ports do all of the same things, nor should we. But, thing definitions? There's no reason to have more than one way to define a thing. Switches? Animated walls? Same deal. We're working on it.
  12. Nope, not surprising :) You're right - it will be in the spec. We should consider where it should live: in it's own lump as ZDoom currently does it, or a spec-defined lump that handles all our config lump needs with one lump, one parser, one text editor, one text edit session, etc - that's what I would prefer, actually, but I'm open for suggestions as usual. It's easier for ZDoom to leave it as is, but, Graf, you did mention the prospect of improving ZDoom's config lump situation.
  13. id did the bare minimum to get their 27, then 68 maps on the shelf. The rest is up to us.
  14. Ok, I misinterpretted - sorry about that. I agree with you that reject editing is a useful thing. But your implementation forces the user, expert, or not, to do housekeeping that, with a better format, the editor can and should do. Using sector numbers is a hack. It forces the map author to do the reject stuff at the end, instead of during editing, where it should happen. There are simple mechanisms to make it work properly - why do you insist on making it work in a mickey-mouse fashion? And, yes, Doom (and Hexen) support is important to me, to the spec I'm building, and the only way to add tagging in Doom format is to hack it in. That's the price you pay when using Doom format. Having it impossible to do is worse than having to hack it in. Believe me, once support is in for UDMF (which can handle anything), the machanics for getting it in Doom format are just an exercise in mundaneness. There is precedent for having a need for a similar technology for Doom mapping.
  15. The same, logically, but not physically - they are different data formats, so they need to be considered as different. One parser cannot handle both, unless it's defined to do so. And, in some cases, there's no lump to parse - it's hard-coded logic. That doesn't matter so much to humans reading, but it matters within a spec.