ACE Engine v2 - DOS Doom II [vanilla++?]

[Dexiaz]

2 hours ago, kgsws said:

How inconvenient? I find hexen-style lines way better than doom style lines.

 

They are way better than doom style parameters, but they are way worse than showed in UDMF, for example.

 

UDMF GUI in Doom Builder is the most convienient to create maps. Everything you want you can create/attach to sectors/lines by pressing Right Mouse Button. You even don't need to use ACS window to create 3D floors or colored lighting (I do remember that times when I had to write all 3D & lighting parameters by myself, and I always hated it).

 

And, as I suppose, @Professor Hastig got used to UDMF gui instead of Hexen gui. Me too, actually.

[kgsws]

53 minutes ago, Dexiaz said:

They are way better than doom style parameters, but they are way worse than showed in UDMF, for example.

 

UDMF GUI in Doom Builder is the most convienient to create maps. Everything you want you can create/attach to sectors/lines by pressing Right Mouse Button. You even don't need to use ACS window to create 3D floors or colored lighting (I do remember that times when I had to write all 3D & lighting parameters by myself, and I always hated it).

 

And, as I suppose, @Professor Hastig got used to UDMF gui instead of Hexen gui. Me too, actually.

That makes sense. Fortunately, format i had in mind works like UDMF in editor.

But never mind, there does not seem to be any need or interest for new stuff.

 

By the way, i am working on documentation. It's not quite done yet, but you can already read something here.

[Lobo]

Oh great, another new "standard"...

 

Just how many do we need?

[Graf Zahl]

1 hour ago, Dexiaz said:

They are way better than doom style parameters, but they are way worse than showed in UDMF, for example.

 

UDMF GUI in Doom Builder is the most convienient to create maps. Everything you want you can create/attach to sectors/lines by pressing Right Mouse Button. You even don't need to use ACS window to create 3D floors or colored lighting (I do remember that times when I had to write all 3D & lighting parameters by myself, and I always hated it).

 

And, as I suppose, @Professor Hastig got used to UDMF gui instead of Hexen gui. Me too, actually.

 

UDMF and Hexen line actions are essentially the same, except for the value range. Hexen only has byte parameters which forced a lot of compromises on the map format while UDMF extends all to full integers.

Regarding 'inconvenient', I'd say it's a poorly chosen term. What has happened in the past is that some vanilla mappers voiced the opinion that remembering one value was easier than all the parameters Hexen additionally needs.

 

1 hour ago, kgsws said:

But never mind, there does not seem to be any need or interest for new stuff.

 

Oh, you are wrong. There's always demand for new stuff. Where 'new' obviously means something that did not exist before.

That's really the problem with another map format. As things stand it's not something any current port may benefit from. Those which already support UDMF already have something equivalent, and the rest which hasn't adopted it yet is just as unlikely to adopt another different format because their intended scope is too different. I can't really see where this might fit in with ports like Crispy or Woof, for example.

 

[OpenRift]

3 minutes ago, Lobo said:

Oh, how bitchy. And irrelevant to the topic.

Well you were complaining about yet another standard being created, and if we wanna talk about unnecessary standards, EDGE is kind of a prime example of that because I can't think of anyone who actually utilizes EDGE's unique features.

 

I want to be clear, I don't think EDGE Classic is a bad port (as far as I'm concerned, you're still doing better than some other ports that I could name), and I don't have much of an opinion on it to be honest. But from what I do know about it, I think it's a bit hypocritical for you to complain about some new oddball standard coming about when EDGE is the king of oddball source ports and impractical standards. 

[dasho]

9 minutes ago, OpenRift said:

Well you were complaining about yet another standard being created, and if we wanna talk about unnecessary standards, EDGE is kind of a prime example of that because I can't think of anyone who actually utilizes EDGE's unique features.

 

I want to be clear, I don't think EDGE Classic is a bad port (as far as I'm concerned, you're still doing better than some other ports that I could name), and I don't have much of an opinion on it to be honest. But from what I do know about it, I think it's a bit hypocritical for you to complain about some new oddball standard coming about when EDGE is the king of oddball source ports and impractical standards. 

 

If you want a real answer:

 

1 - We aren't suggesting that our method IS a standard for anyone else; certain parts of it like COAL and DDF can be compiled as standalone libraries and so it is theoretically possible, but that would be like saying Eternity's EDF or k8vavoom's VavoomC is a standard.

 

2 - Implementing new 'universal' standards has a very real cost/benefit ratio for devs, ESPECIALLY ones for less popular ports like ours. This is why it is a waste of time for us to implement Hexen specials or ACS; it doesn't provide anything new for us and nobody would have a reason to use EC over (as an example) GZDoom for that type of content.

 

3 - Sometimes a 'universal' standard doesn't pan out in practice; UMAPINFO is the biggest offender here. I've had to add fallback parsing for MAPINFO/RMAPINFO, DMAPINFO, and ZMAPINFO because WADs are still made which choose to ship these lumps in lieu of UMAPINFO.

 

On the map format front for this proposed new standard, I'm not sure why existing UDMF map editors couldn't be extended to output the map to this CBOR format so that applicable engines could consume it. For the content definition front, I agree that Dehacked needs a universal successor but if I were also a betting man I would put my money on DECORATE being the outcome of that discussion, which kind of ties into point #2 above.

Edited June 9, 2023 by dasho

[Lobo]

What Dasho said.

 

EDGE is not a standard, has never been a standard, and never will be a standard. Nl idea what you are talking about there.

 

But everytime someone re-invents the wheel, devs have to (possibly) add support for yet another "standard": that's what I'm talking about.

How many *MAPINFO do we have now for example?

[DRON12261]

6 minutes ago, Lobo said:

But everytime someone re-invents the wheel, devs have to (possibly) add support for yet another "standard": that's what I'm talking about.

How many *MAPINFO do we have now for example?

If we are talking specifically about a universal standard, there is only one - UMAPINFO.

[hobomaster22]

9 minutes ago, dasho said:

 

If you want a real answer:

 

1 - We aren't suggesting that our method IS a standard for anyone else; certain parts of it like COAL and DDF can be compiled as standalone libraries and so it is theoretically possible, but that would be like saying Eternity's EDF or k8vavoom's VavoomC is a standard.

 

2 - Implementing new 'universal' standards has a very real cost/benefit ratio for devs, ESPECIALLY ones for less popular ports like ours. This is why it is a waste of time for us to implement Hexen specials or ACS; it doesn't provide anything new for us and nobody would have a reason to use EC over (as an example) GZDoom for that type of content. 

 

3 - Sometimes a 'universal' standard doesn't pan out in practice; UMAPINFO is the biggest offender here. I've had to add fallback parsing for MAPINFO/RMAPINFO, DMAPINFO, and ZMAPINFO because WADs are still made which choose to ship these lumps in lieu of UMAPINFO. 

 

On the map format front for this proposed new standard, I'm not sure why existing UDMF map editors couldn't be extended to output the map to this CBOR format so that applicable engines could consume it. For the content definition front, I agree that Dehacked needs a universal successor but if I were also a betting man I would put my money on DECORATE being the outcome of that discussion, which kind of ties into point #2 above. 

I agree with your first two points. I don't think decorate will beat out dehacked, especially since DECOHack is a thing. Implementing decorate was a huge pain for Helion. Adding dehacked support on top was also a massive effort so I don't think there is much incentive for ports to implement it.

[Lobo]

25 minutes ago, DRON12261 said:

If we are talking specifically about a universal standard, there is only one - UMAPINFO.

You're new here aren't you? :)

 

 

 

Sorry, not intentionally trying to get side-tracked. I'll stop now.

Edited June 9, 2023 by Lobo
moving on

[kgsws]

1 hour ago, Graf Zahl said:

Oh, you are wrong. There's always demand for new stuff. Where 'new' obviously means something that did not exist before.

That's really the problem with another map format. As things stand it's not something any current port may benefit from. Those which already support UDMF already have something equivalent, and the rest which hasn't adopted it yet is just as unlikely to adopt another different format because their intended scope is too different. I can't really see where this might fit in with ports like Crispy or Woof, for example.

Ok then. Maybe proposing new map format was not a best start.

 

43 minutes ago, dasho said:

On the map format front for this proposed new standard, I'm not sure why existing UDMF map editors couldn't be extended to output the map to this CBOR format so that applicable engines could consume it.

Basically that. I understand it would take some time, but my proposed CBOR format is quite close to UDMF.

 

43 minutes ago, dasho said:

For the content definition front, I agree that Dehacked needs a universal successor but if I were also a betting man I would put my money on DECORATE being the outcome of that discussion, which kind of ties into point #2 above.

I think this is what we should focus on. DEHACKED is outdated but simple, if not already implemented.

DECORATE is powerful and basically addresses desired outcome of my proposal, but is a way too big take to implement. I know that.

 

 

What i want to propose is something that would allow greater and universal addition of new states, things and other exiting DEHACKED stuff.

Simplest way, that i am not proposing but showing as an example, would be to load new, say XSTATES, lump containing array of state_t structures. Same for mobjinfo_t, etc ...

This is obviously very limiting for future extensions, thus i am proposing CBOR. Alternatively, if you don't like binary format and a requirement of compilation, JSON could be used.

(i am proposing CBOR because i have good experience parsing simple subset of it - it's easier to parse than text)

And technically, DECOHack could be easily extended to support these new lumps.

Also, should it be in multiple lumps? Should it be a single lump? There is so much to discuss.

 

The point is - "just load" new states and things to existing arrays.

 

I can easily code a reference implementation of this myself. But we need details.

Edited June 9, 2023 by kgsws

[DRON12261]

18 minutes ago, Lobo said:

You're new here aren't you?

No, not new (date of account registration is not an indicator). In any case, it has nothing to do with the current discussion.
 

Going back to UMAPINFO, today it is the only format which really became a standard and which supports the largest number of ports. When I create a new map and put UMAPINFO in it, I have full confidence that all modern ports which are updated even a little bit from time to time can support my wad. All other xMAPINFOs are specific to a particular port or family of ports and are used to leverage the unique features of those particular ports. Or they are used instead of UMAPINFO if I conditionally make a wad as exclusive to a certain port, totally relying on the unique features of that port, like ZDoom with ZMAPINFO or Eternity Engine with EMAPINFO.

[Lobo]

 5 years and it's still not completely supported.

[DRON12261]

4 minutes ago, Lobo said:

 5 years and it's still not completely supported.

But what you forgot is that it is much better supported today than any other xMAPINFO format ever proposed. Many mappers and modders already rely on it completely in their projects and find it an extremely useful tool. And definitely, though not at an incredible rate, it continues to be implemented and supported in other ports.

So all this skepticism today no longer makes any sense on this subject.

[Lobo]

Whatever, keep missing the point so.

[LuciferSam86]

Tbf would be nice having a talk in a hacker camp / congress about ACE. 

[RastaManGames]

I wish that Carmack can notice "ACE Engine", like Romero noticed "MyHouse.WAD"...

[Redneckerz]

On 6/9/2023 at 12:55 AM, kgsws said:

I understand, but it was pretty much required. DEHACKED alone was too limiting.

Now, the question is: do we need something better than constantly extending DEHACKED? Something that would be more on par with DECORATE, but much easier to parse and with clearly defined behavior?

It suffers from the same requirement: You need a group of veteran members that can support htis idea. By targetting DOS you are severely limiting yourself to one audience - The vanilla crowd and Choco crowd.

On 6/9/2023 at 12:55 AM, kgsws said:

I don't think i understand this.

What i am proposing is no longer ACE related. I am proposing new standard that goes beyond Boom and MBF. Closer to ZDoom, while making it easier to implement and with a fresh start to avoid compatibility bloat. (that does not mean i want to remove old features)

I just called it ACE-defined as a generic moniker. I understand you want to propose a new standard.

On 6/9/2023 at 12:55 AM, kgsws said:

So, basically, main question is: do we need DEHACKED successor?

Any ideas how to get opinions of veteran community?

See the aforementioend names.

On 6/9/2023 at 10:04 AM, Gez said:

If you want to define a standard, you need to convince everyone. That's the problem.

So yes, basically the same as what i think indeed. I do think it helps when you get some of the people responsible for earlier specs behind you. I am not saying MBF21 is universal, but a lot of known ports have support for it, which i consider good enough in practice.

 

15 hours ago, dasho said:

If you want a real answer:

That's a far better outline than what Lobo's initial reply was - Which at best was just provocative. ''Great, another standard'' is rather baity in nature.

 

I know EDGE has never been one to set standards, but rather, to achieve similar goals differently.

 

[Dexiaz]

@kgsws, you're a great programmer and mod maker! Well, I've managed to rework your demo wad to create a special patch for "Doom 64 for Doom 2" mod, which adds Unmaker weapon to the regular weaponset. This was impossible with Dehacked, yeah.

 

And now I understand much more about ACE Engine modding, because it took 2 hours to figure out how ACE Decorate lumps are working here. I mean, any mistake and the game crashes. This is a tough task, it need some time to get used for this.

 

 

[OpenRift]

48 minutes ago, Dexiaz said:

@kgsws, you're a great programmer and mod maker! Well, I've managed to rework your demo wad to create a special patch for "Doom 64 for Doom 2" mod, which adds Unmaker weapon to the regular weaponset. This was impossible with Dehacked, yeah.

 

And now I understand much more about ACE Engine modding, because it took 2 hours to figure out how ACE Decorate lumps are working here. I mean, any mistake and the game crashes. This is a tough task, it need some time to get used for this.

 

 

This is what you love to see my friend.

[Biz!]

Alright, so, this is just some magic that gets the code to work on the vanilla EXE, right?

[Bauul]

22 hours ago, kgsws said:

I think this is what we should focus on. DEHACKED is outdated but simple, if not already implemented.

DECORATE is powerful and basically addresses desired outcome of my proposal, but is a way too big take to implement. I know that.

 

 What i want to propose is something that would allow greater and universal addition of new states, things and other exiting DEHACKED stuff.

 

Isn't DSDHACKED with Decohack essentially the current middle ground between Dehacked and full-blown Decorate, like you describe?

 

Practically unlimited Things with unlimited states all written in a nice plain-text format that looks relatively similar to the example you posted. 

[Dexiaz]

9 minutes ago, Biz! said:

Alright, so, this is just some magic that gets the code to work on the vanilla EXE, right?

 

Yes.

[kgsws]

1 hour ago, Biz! said:

Alright, so, this is just some magic that gets the code to work on the vanilla EXE, right?

Pretty much.

 

1 hour ago, Bauul said:

Isn't DSDHACKED with Decohack essentially the current middle ground between Dehacked and full-blown Decorate, like you describe?

Practically unlimited Things with unlimited states all written in a nice plain-text format that looks relatively similar to the example you posted. 

Yea, it kinda. But it also is not. There are things missing i would like to address.

Also, my proposal would include a set of new action functions, and argument parser - which would allow special form of scripting.

 

3 hours ago, Dexiaz said:

And now I understand much more about ACE Engine modding, because it took 2 hours to figure out how ACE Decorate lumps are working here. I mean, any mistake and the game crashes. This is a tough task, it need some time to get used for this.

I hope it was pretty much stuff that would be invalid in GZDoom too.

Anyway, nice to see some modding for ACE Engine!

[kgsws]

OK. Official version 2 release: https://github.com/kgsws/doom_ace/releases/tag/v2

And documentation: https://github.com/kgsws/doom_ace/blob/master/doc/main.md

 

Release wad itself only contains ACE Engine. It is not a demo wad. Use this release as a basis for your mods.

Edited June 10, 2023 by kgsws

[THEBaratusII]

Very nice to see a demo is out, I'll have to check it out sometime.

 

Any possibility of adding support for SBARINFO allowing custom HUDs in the ACE Engine?

[Biz!]

Hey, I tried loading both the demo wad and the release wad, and they both crash Dosbox X and Dosbox staging when loading with Rocket Launcher 2, do I have to do some funky Dosbox magic with something similar to .bat files or is this just some mysterious settings thing when I don't change anything?

[OpenRift]

25 minutes ago, Biz! said:

Hey, I tried loading both the demo wad and the release wad, and they both crash Dosbox X and Dosbox staging when loading with Rocket Launcher 2, do I have to do some funky Dosbox magic with something similar to .bat files or is this just some mysterious settings thing when I don't change anything?

I was using DOSBox Staging and it worked perfectly fine. Here's my config.

[No-Man Baugh]

Forget Abritrary Code Execution, forget raised limits, forget Decorate, and forget the extra screenwipe options; MORE SOURCEPORTS NEED FAKE MOUSE AIM, IT'S THE BEST!!!

[Biz!]

9 minutes ago, OpenRift said:

I was using DOSBox Staging and it worked perfectly fine. Here's my config.

Unfortunately, it didn't work, even with your config, i'm assuming it has to do with either the iwad or exe, i'll set it to the ones that are in my steam folder.

EDIT: Unfortunately, still isn't working, maybe I need to update DOSBOX Staging.

EDIT 2: Unfortunately again, that didn't work, maybe I need to use some .bat file for it.

Edited June 11, 2023 by Biz!