kgsws

Pretty cool video. Very nice look at features of my demo WAD. * Yes, almost every location and scripted event is inspired by other game or other doom mod. (Even green-fog rooms are. Can you guess which Doom mod inspired those?) * Arch-viles can't resurrect gibbed enemies. Yes, they can resurrect each other. But not if you gib them - that is my counter-balance. Plus, you can gib corpses! * Interesting point about ammo balance. I did design ammo placement and respawn to be "just enough". But maybe "just enough" only for me since i know where everything is. (And there's a secret ammo stash at "The Unseen" map.) * Many weapons have alt-fire. Sometimes useful. You can load up to 4 rockets in rocket launcher and fire all at once. Or you can make plasma ball explode for much more splash damage. * Grenades are extremely powerful. * Enemies drop "demon essence" that powers all weapons at slot 8. All these weapons use no ammo and are extremely buffed when you pick up invulnerability. * Force field generator item could be useful. It blocks hitscan and reflects projectiles. * Super-Secret-Puzzle sequence is my idea. And to prevent "solution sharing" it is not randomized at the start of the map, but a bit later. Solution is shared in my youtube video. * MAP30, the last level, has different game play. You can't use rockets to win. * One commander keen is replaced with another ... game reference ... and it gives you a secret weapon.

I have not seen this animated yet. This is related to https://doomwiki.org/wiki/Picture_format It also shows how doom does not store transparent pixels at all.

It does not. But you can do limited, but still way more powerful than boom conveyor belts, scripting using DECORATE. Check demo wad, it uses that a lot.

What makes it even more funny or confusing is that i have actually released something with almost the same name ages ago. https://doomwiki.org/wiki/KGZDoom

No. UDMF as a format is one thing but various features are other thing. It is possible. At one point i had UDMF loader working. But it still only supported features of Hexen map format. So at that point UDMF was ... pointless ... and slower to load. Oh, and collisions were not working as UDMF does not provide BLOCKMAP. But yeah, no UDMF in ACE Engine.

That is GZdoom bug. This should work in ACE engine. ACE Engine does not support UDMF. It only supports Hexen and original Doom format. Visplane limit can be raised in WAD config lump. Yeah, that is not supported in ACE Engine. Hexen map format does not allow it. That's a bit tricky as it depends on what you actually want to do. You could start by using config lump from demo i released. It even has render limits risen.

I'm not sure what part are you referring to. Yes, software renderer in GZDoom is broken when 3D floors are used. I did not really see anything extreme that is not possible in ACE Engine already. Maybe i was not looking well. Can you post screenshot of the issue?

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)