kgsws

Eventually yes, i guess. It kinda seems to be a low priority thing since how many players are gonna try to "collect" negative frags. Once i can detect negative numbers, it does not really matter if i use minus sign or change colors. So, minus sign is a better choice.

Another bugfix release https://github.com/kgsws/doom_ace/releases/tag/v4 Yeah, sorry. I totally forgot about that. Now it works, but it can't show negative frags ... due to other changes i did in the past. Again, fixed. The issue was that if you used text without any space, last letter would get removed. Now i hope that's all. But still, report anything you find out broken. It is. But it is not gonna be as quick as these bugfixes. I might add this in the future though.

Ok, netgame bugfix is done: https://github.com/kgsws/doom_ace/releases/tag/v3 Done Done. You have type message as "cheat" and it will be sent as a message. There is no new "chat" key, there is only "cheat" key. If you want cheats in multiplayer (useful for testing), use ! as a first character. Also one extra thing. I have added support for colored player background to intermission. Original background is too dark though. If you are making a custom WAD, i recommend you to change patch STPB0 to something brighter. Just remember, it has to use player base color (green in default). (Now that i think about it, it's not exactly the best solution. It will break if you use more player classes with different base color.)

That's intentional. It was kinda easier than using old system. Yeah. These specifically are replaced with give and map cheats. Since maps can use any name (not just MAP01) and powerups use decorate names. It would be possible to add these cheats though. That's what GZDoom does. This is emulating GZDoom. That's kinda what GZDoom does. But GZDoom does modify heights in definitions. This is possible to address but requires some considerations, like use of DEHACKED and ProjectilePassHeight property. Not a bug. It's removed. Intentionally - like in Hexen and Heretic. These both use linear framebuffer like i do. Low detail mode is no longer CPU efficient. That was a bug i have already fixed in source code. I have yet to make binary release. You have to create new player class that has Player.JumpZ value set. Default DoomPlayer has zero, thus no jumping. Some of those are reasonable but not quick to code ... Actually yes. A bug. I have removed frag counting to get free space in player_t structure. But then i have never got to re-implement it again. Yeah, that's PowerMorph in GZDoom. I did not have time to implement this as it reached some limitations of my DECORATE handling. So. I am gonna try to make bugfix release this weekend which will address frags and already patched berserk palette.

That sounds like a bit of gray area to me. I am not sure if i would call what am i doing "linking". But i am certainly jumping to existing code. Well, i guess LGPL it is.

I will address that then. Well, once i figure out what license i should use. I am not sure what you mean. Just the fact that it runs in original DOOM memory and uses it's addresses? This project does not require original EXE to compile, but i do indeed provide a list of "random" addresses that are based on original EXE. Is that the issue?

Well, there are no updates and i don't plan any ... so far. But maybe someone is working on cool mods? I would like to see some.

Yes, some issues are indeed addressed and yes, even weapons and ammo could technically be added. Cumulative loading would be an issue since everything is indexed absolutely. You can't even have multiple DEHACKED lumps, or can you? Indeed. DECORATE is a nice format to have but it too intrusive to implement (i know that). Even weapon definition using inheritance would have to be a hack without major refactoring. I have proposed special property for weapon: "Slot". You can definitely add this to DEHACKED. Feel free to use my new weapon slot handling from example code. I see. Well, my idea was not to propose a set thing. As i mentioned, everything is a subject to change. Well, yes. Some subset of DECORATE in every source port would be nice to have. But i still think that DEHACKED / BEX is outdated format and should be obsoleted. It's like in DEHACKED - a state number. Except in my case it's relative index to states provided in this lump. Yes, like DEHACKED, these state numbers do not mean much if you are reading it. The power of this format is in tools that can create it. Like DecoHack is for DEHACKED right now. Well, cumulative loading. Like in ZDoom you can have multiple DECORATE lumps without issues. I am quite sure this could be hacked into BEX format, somehow. But i would still rather make it obsolete. Exactly. Yep. Having DECORATE in every source port would address this issue. I would not propose any new format if that was the case. But that format is very incompatible with original code base. ------------- Well then, lets change this format to something DECORATE-like which would be parsed directly in the engine? Even that would be far better than DEHACKED / BEX. (take a look at my pseudo-DECORATE source text files in example zip file)

That is actually true. It offers cumulative loading. It is internally structured in a specific way that you can load multiple DOOMHACK lumps without any collisions. Things are addressed by name instead of index to array. States are relative to specific DOOMHACK lump. As with DECORATE, you can load two independent mods at once. With DEHACKED/BEX you will probably get a ton of collisions with states and things. DEHACKED / BEX i just outdated thing, i think. Any new extensions seem like a format hacks to me. I agree that DECORATE would address this. It's just that it is too intrusive to implement. Exactly, editing is often done using external tools. So "binary" format should not be an issue. What is the issue with CBOR? What are supposed limitations? Dead end? CBOR is basically JSON in binary form. It offers everything what JSON does, but is easier to parse. There are no limitations like with BEX. Since it supports object with key / value, like JSON does, it can be extended with anything in the future. If you specifically don't like binary representation of tree-like structure, we can use JSON directly. CBOR->JSON or JSON->CBOR are (almost) directly convertable. (CBOR specifies 'binary string' which does not exist in JSON, but i do not use that in my proposal) So again. CBOR is basically JSON. If you think parsing JSON is somehow better then we can use JSON. Literally nothing about internal structure i proposed would change.

Oh, i have not realized that. Well, that really makes this kinda pointless. Yeah, i guess i did. It allows you to add new weapons and ammo types. It adds new code pointers with more flexibility, including sector movement. It also allows cumulative modding, so you can like create mod for other mod. It's much less complex and intrusive to support this than DECORATE. Obviously, DECORATE already provides flexibility and features i aim to add using this. Yes. I am actually attempting to propose a fresh start. Without old limitations but also something easily extendable in the future. And importantly, easy to implement. (though i hope my notion of "easy" is not too skewed) And yes, i am ready for this to be completely rejected. It would be cool if every source port supported DECORATE. Then i would not be proposing this.

That's not quite true anymore. Yes, original DEHACKED was used to modify DOS EXE. But nowadays DEHACKED is also used without even considering original DOS EXE. Besides, i can make it work in DOS EXE. I actually intend to do that in some or other manner. Well, there is a reason. Code pointers are addresses to code memory. However, code memory has random (different) address on each PC. To address this issue, there's a list of relocations. This list basically specifies where in the memory those addresses have to be fixed to point at correct code. This list has a set size and nobody bothered to address this issue. Yes, it is technically possible but it quickly goes beyond the scope of the original, simple, DEHACKED EXE patching.

Well, technically this is not a replacement as this can coexist with DEHACKED. Anyway. I am attempting to propose DEHACKED replacement that would allow greater flexibility without adding extra complexity to the code. I have already created proof-of-concept code for crispy-doom (if you want to compile this you have to use cmake). Attached zip file contains a demo WAD that can be run with modified crispy doom. Here's the video if you can't compile crispy doom yourself: Now about new specification - everything is up for discussion, even name DOOMHACK can be changed. new lump, called DOOMHACK it is cumulative, you can have multiple DOOMHACK lumps even across multiple WADs without any collisions it contains tree-like structure encoded using CBOR allows creation of new ammo things and weapons allows modification of existing ammo things and weapons allows addition of new sounds allows addition of new sprites it contains 5 main sections sounds array of strings each string is sound lump name DS prefix is included and currently required by the code duplicate sounds are not added ammos object containing one or more objects each key is new ammo type name allows access to ammo properties, including backpack maximum up to 16 unique ammo types (4 are built-in) weapons object containing one or more objects each key is new weapon name current implementation allows up to 32 unique weapons (9 are built-in) weapons can be put to slots 1 to 8 things object containing one or more objects each key is new thing type name states array of objects contains all new states provided by this lump sprite is encoded as uint32_t stop, or S_NULL for next state is used if no Next is specified setting Next to zero will trigger relative indexing and use first state in this lump! allows using custom code pointers, including new ones with custom arguments states are indexed relatively to this lump negative index specifies jump to original Doom state (from info.h) this applies to anything that requires state number this allows multiple DOOMHACK lumps ammo / weapon / thing names allows overriding of original stuff, like DEHACKED names are taken from ZDoom ammo / weapon / thing names are not connected in any way weapon pickup can have different name than weapon itself example: if you use name Archvile in things, the original MT_VILE will be modified instead of creation of new thing type things with SPECIAL flag can now use new state called Touch if present, thing will use this state instead of default (sprite-based) pickup handling toucher mobj (player) will be set as special->target weapon and ammo things are not connected to weapon and ammo types use new Touch state with A_PickupAmmo or A_PickupWeapon code pointer integer values are directly copied, there is no difference between int fixed_t angle_t it's up to generator tool how to handle this a new set of code pointers should be mandatory, for cross-compatibility Now some examples. Since CBOR is binary format, everything will be represented in pseudo-JSON instead. Some notes to my example code: inventory (weapon and ammo) was fit into existing space in player structure this limits weapons to 32 and ammo to 16 sprite names are not dynamic, artificial limit is 511 (but over 200 already exist) some modification were already done by crispy doom team most notably, handling PSPR code pointers - this is also required for my implementation to work properly this is only a demo i did not fix some crispy features, like weapon recoil many doom code pointers are not exported, yet What we need to think about: proposed format property names some names are ZDoom based some are just random, some have specific idea behind State prefix for state-based properties Sound prefix for sound-based properties capitalization my code is case-sensitive capitalization is not entirely consistent scripting from my demo you can see that my intention is to replace voodoo-doll scripting how much turing-complete does this have to be? default values for new stuff i have added a minimal amount of default values most properties start with zero generalising some built-in behavior boss explosion immunity Archvile notarget and instant retaliation lost soul is monster (+ISMONSTER flag does not exist) hardcoded player animations i have addressed some, but not all of them and probably more this would require extending FLAGs field to 64 bits it's easy to extend mobjinfo_t mobj_t is an issue though (save game) spawnpoint does not seem to use type anywhere this would give us 16 bits The real strength of this lump is in tools that can create it. I have included python script that can generate this lump from pseudo-DECORATE text files. Sources are included too. And now again. Nothing is set. Everything is only a proposal. We don't even need to call this DOOMHACK. Also, my code is freely available to any source port without any limitations. So, any interest or is this a dead end? doomhack_test.zip

That visplane leaking looks like some kind of bug. I am not sure why it happens on normal (non-3D) floors. If you are out of visplanes game should just crash like the original. But anyway, you can set visplane (and more) limit in mod config. Check ACE_CONF in demo wad. Here's documentation: https://github.com/kgsws/doom_ace/blob/master/doc/config.md

Jumping is up to mod authors. You can't enable jumping globally as it is property of player class. And this is intended behavior for old map "compatibility". You have to create new player class that has this property set to desired value. https://zdoom.org/wiki/Actor_properties#Player.JumpZ Also note that new player class has to be added using KEYCONF. https://zdoom.org/wiki/KEYCONF So yeah, you can't enable jumping if mod itself does not allow it in the first place.

That could be a fault of demo WAD. I have already changed this behavior in V2 release, but not i demo WAD. 1) Make sure your sound works in original Doom2 2) delete ACE.CFG 3) run demo WAD If your sound does not work in original Doom2, i can't help though.