DSDhacked [unlimited everything]

[ChopBlock223]

3 hours ago, dew said:

I don't understand how the boom environment/pr+ with its backward compatability remains the same if dehacked is jettisoned in favour of an expansive decorate implementation. How many pieces of zdoom can you fix the Ship of Prboom with until it's just zdoom again?

I don't think anyone suggested to abandon DeHacked in its entirety, because people will want to keep it for compatibility, rather the notion was that instead of building on it, a specific format which is easier to read and write, and which is (apparently) less bothersome for other devs to implement, would be a more practical approach if one is going to continue to add features.

 

3 hours ago, Graf Zahl said:

If you get slopes working, a lot, actually.

Would that be problem free and kosher with demos? I know the Doom monsters don't work that well with stuff like 3D floors.

I guess it could be cool to play around with, though I think I would mostly end up using it for not-flat roofs on house exteriors.

 

3 hours ago, Graf Zahl said:

The places where the real problem starts is custom inventory items.

Like Heretic and Hexen stuff, potions and powerups you can carry with you?

 

 

[Graf Zahl]

9 minutes ago, ChopBlock223 said:

Would that be problem free and kosher with demos? I know the Doom monsters don't work that well with stuff like 3D floors.

I guess it could be cool to play around with, though I think I would mostly end up using it for not-flat roofs on house exteriors.

 

If you do it right it won't affect demos. The slope math functions just return the flat sector height for unsloped sectors so the only places to be careful is the movement and collision code which would need a bit more care to handle both options.

 

 

9 minutes ago, ChopBlock223 said:

 

Like Heretic and Hexen stuff, potions and powerups you can carry with you?

 

 

DSDA already has this for these games. The code could also be activated for Doom if needed. Since this is mostly on the UI side and not the play code it won't affect demos too badly. But obviously for a demo-centered port it needs to be done with a little more care to avoid breaking things.

 

As with most other things, it's not impossible to do but it's a lot of work.

 

 

[rfomin]

2 hours ago, MTrop said:

God help you if you try to implement DECOHack's flavor of DECORATE into your port, which I don't recommend at all, especially when I still have that "0" in front of the version number.

Completed or not, people are already starting to use it for MBF21 stuff. If we want to invent a new DECOLITE standard, why not take something already working. Could you please clarify why you are not recommending this?

[MTrop]

5 hours ago, rfomin said:

Completed or not, people are already starting to use it for MBF21 stuff. If we want to invent a new DECOLITE standard, why not take something already working. Could you please clarify why you are not recommending this?

 

DECOHack's final feature set is incomplete and it would be a moving target for implementors. It was really never meant to be anything more than just a different (and hopefully easier) way to make DeHackEd patches without a GUI slowing me (or anybody else) down.

 

Besides, even if DECOHack's exact DECORATE-inspired language were implemented in ports, you would have to emulate its logic for cobbling a patch together, and the results may not be 1-to-1 in terms of what it has to do regarding state allocation and all the other low-level stuff that needs to happen to create a functionally equivalent DeHackEd patch, not to mention implementing all of DECOHack's other procedural niceties like bulk-redefining fields and whatnot.

 

As stated before, DECORATE is high-level. DECOHack has to make concessions (and have additional supporting language) to make it as flexible as low-level DeHackEd, because its goal is to be a DeHackEd patch creator (its ultimate goal is to be as flexible as Fraggle's DEH9000). Every implementing port would have to ensure that their implementations of DECOHack have equivalent results just for safety's sake. You don't have to worry about all of that if it compiles to a singular common output that every port can already interpret unambiguously.

 

And if you wanted to use an uncompiled DECOHack-ish definition language for modding Doom in your favorite port family, why would you even want to care about the fine details of Thing table indices, State table indices, and so forth? It's a needless complication for a modder to endure when they want to just make stuff. That's why we have DECORATE!

 

To reiterate, DECOHack is for making DeHackEd patches (especially within the limiting confines of DeHackEd), and even if MBF21/DSDHACKED didn't exist, it would still have a use. Any other purpose would be a waste of time for port authors to implement to ensure some kind of consistency when they don't have to. And if a "New DeHackEd Language" or "DECOLITE" were made, it should be made in a vacuum, and not take DECOHack's lead as a strict basis for it. Adopting its forced anachronisms would be a mistake in the name of progress.

[Graf Zahl]

You are probably right. But start in a vacuum? I'm not sure about that, if the point is supposed to be running older ZDoom mods.

What probably makes the most sense would be to get a subset of DECORATE working to run that monster resource WAD from 2005. If you got that there'd be enough features for convenient definition of new monsters - this was before the implementation of custom states and overall still quite basic.

The needed code pointers would also all be of the kind that's painless to backport.

If that could be made to work within the framework of what MBF21 and DSDHacked provide it'd already be a huge win for everybody.

[MTrop]

"In a vacuum" was probably an exaggeration on my part, but yeah - a much simpler DECORATE from the '04-05 era would be a more ideal starting point. Weirdly enough though, I would probably still stay away from the merging of Things and Weapons into "Actors." That feels like a product of ZDoom's early actor code and inventory systems merging and not how Doom functionally separates the two, despite the shared state table.

 

At the moment, the only thing solid enough for the later-gen ports and easily accessible to the Boom-era-lineage ports is the DeHackEd format, and while it is painfully low-level, it is still a decent enough abstraction as an A-to-B mapping medium, even if the interpreting ports won't exactly implement it as such. The "unlimited" nature of DSDHACKED will already force implementing ports that already had a contiguous state table into needing to use a sparse index lookup at the very least.

[Graf Zahl]

32 minutes ago, MTrop said:

"In a vacuum" was probably an exaggeration on my part, but yeah - a much simpler DECORATE from the '04-05 era would be a more ideal starting point. Weirdly enough though, I would probably still stay away from the merging of Things and Weapons into "Actors." That feels like a product of ZDoom's early actor code and inventory systems merging and not how Doom functionally separates the two, despite the shared state table.

 

What do you mean with Things? Inventory items?

Like I said, I think everything up to ZDoom's inventory refactor (which was exposed to modding in 2.1.0) is fine, after that it will get tricky because the inventory stuff is so closely tied to ZDoom's implementation of an inventory system. I wouldn't start thinking about this until the rest - which is still a lot of work - has been ported.

 

Regarding weapons, in hindsight I have to agree. It was tempting back then but turned out to be a major mistake because there's no proper separation between weapon actor states and weapon player sprite states. Sadly it is far too late to fix this by now. While I think it can still be kept in the actor definition, the states need to be separate to make it robust.

 

 

 

32 minutes ago, MTrop said:

The "unlimited" nature of DSDHACKED will already force implementing ports that already had a contiguous state table into needing to use a sparse index lookup at the very least. 

 

If you want to do truly "unlimited", yeah - without using sparse tables or other means of non-linear lookup it may become tricky if it starts wasting too much memory for the linear tables.

[Giomancer]

Based on earlier talks with ketmar and following this thread, I would like to see a fork of Pooch that abandoned all DeHackEd support and implemented this theoretical DECOLITE system as well as a scripting language like RookScript or Scheme or Lua.. I bet people would go to town on that sort of thing. 

 

Too late for my birthday, but if anyone wants to shoot for Christmas..

[Gibbon]

On 10/1/2021 at 1:52 AM, Giomancer said:

Based on earlier talks with ketmar and following this thread, I would like to see a fork of Pooch that abandoned all DeHackEd support and implemented this theoretical DECOLITE system as well as a scripting language like RookScript or Scheme or Lua.. I bet people would go to town on that sort of thing. 

 

Too late for my birthday, but if anyone wants to shoot for Christmas..

Anyone can fork Pooch and add it.  But not me :)

 

[Redneckerz]

On 10/1/2021 at 1:52 AM, Giomancer said:

Based on earlier talks with ketmar and following this thread, I would like to see a fork of Pooch that abandoned all DeHackEd support and implemented this theoretical DECOLITE system as well as a scripting language like RookScript or Scheme or Lua.. I bet people would go to town on that sort of thing. 

I mean MTrop loves RookScript. But this theoretical DECOLITE first needs to be properly defined and furthermore, it should also be determined how much it adds/deviates from existing structures/

 

See, the thing is this. This year has been seeing several new standards introduced - from DSDHacked to DEHEXTRA to MBF21. There is some overlap in their features that are juxtaposed against eachother, but since they exist, and ports start to implement support for them, we have to deal with it.

 

What concerns me more is to explain what the features are. There aren't that many good examples yet in active use, so we have to play the wait game here. Nevertheless, it is also important that we can define the standard in short - If you take a look on the wiki, you will see that many of these standards as of today carry an empty Features section.

 

The reasons of this are obvious:

• As much as i love digging into things, i simply do not have enough knowledge to write a detailed summary. I have emplored upon the community, specifically those who actually are behind the spec, to step up forward in this
• The aforementioned lack of examples highlighting the obvious benefits of these new standards
• Ports are only just now starting to implement support for these standards

Inside this world DECOLITE is so far a theory - Not defined, not detailed. I simply do not find it sound to implore yet another theoretical spec when it does not meet any of the 3 points outlined above, let alone that the standards that we have are actually decently documented!

 

I am all up for boosting modder potential here through whatever standard that is made, but lets please just make sure the above 3 points get met.

Edited October 6, 2021 by Redneckerz

[MTrop]

1 hour ago, Redneckerz said:

I mean MTrop loves RookScript.

Of course I love it.

 

I made it. ;)

 

 

Also, any port that discards DeHackEd in favor of a better language is pretty unnecessary unless the port author just wants to shed the shackles of needing to keep an older spec up-to-date. For mod authors, this means nothing, since mixing DeHackEd and DECORATE outside of addressing compatibility issues leads to disaster.

 

We've got (G)ZDoom if you want a port with a better modding language, and solutions are out there for covering the gaps between DeHackEd and EDF and DECORATE and ZScript in terms of writing something legible and maintainable. We can't stop hobby projects, but an entirely new port would just introduce potential user fragmentation and divided effort when existing efforts should be concentrated on learning what each port's individual strengths are and addressing their weaknesses without losing their identities, at this point.

 

The current zeitgeist is backporting engine features that can feasibly be added to an existing chain of Boom-compatible ports (and their spiritual descendants), and I'm not above killing some high-horses to make the glue between them!

[Redneckerz]

24 minutes ago, MTrop said:

Of course I love it.

 

I made it. ;)

Your avatar fits you well sir, haha :) Joking aside, your tag is well deserved.

24 minutes ago, MTrop said:

We can't stop hobby projects, but an entirely new port would just introduce potential user fragmentation and divided effort when existing efforts should be concentrated on learning what each port's individual strengths are and addressing their weaknesses without losing their identities, at this point.

 

The current zeitgeist is backporting engine features that can feasibly be added to an existing chain of Boom-compatible ports (and their spiritual descendants), and I'm not above killing some high-horses to make the glue between them!

Emphasizing the bolded here. Alongside the string of new standards have come a metric ton of new ports, some of which turn out to implement these new and exciting features. Indeed, the last thing anyone should want is introduce a port that reinvents the wheel once more when it comes to scripting.

 

Personally i would only accept that if we get something that delivers dramatically on the visual front, like a universal standard for lightmaps. But even that is pushing it.

 

As far as i am concerned, lets go to work with the new tools that we currently have. That also means your DECOHack (and your tooling in general) should get into the limelight here.

[Giomancer]

 

4 hours ago, Redneckerz said:

Inside this world DECOLITE is so far a theory - Not defined, not detailed. I simply do not find it sound to implore yet another theoretical spec when it does not meet any of the 3 points outlined above, let alone that the standards that we have are actually decently documented!

Short version: you are absolutely correct.

Still, you're pointing at the exact reason I believe a port similar to the one I mentioned would be a good thing if it were made. Plenty of current Doom standards are de facto (Boom 2.02, MBF 2.04, DeHackEd, DECORATE, etc.); they only exist at all—as standards, at least—because they were copied/inherited by other ports: good (or popular, anyway) ideas tend to spread themselves around. @kraflab has taken the "implement first" route with DSDhacked; the main difference is that they have given us a spec instead of forcing programmers interested in the idea to dig through the DSDA-Doom source. Like I said, you're not wrong; without either a referential implementation or a serious discussion-with-intent, all of this is just a thought exercise.

[Gibbon]

For implement first, spec second implementations, to avoid others digging through the code there should be a single commit that implements it or at least a 'part' series of commits.  This is exactly why no source port has all Boom features unless derived from Boom, because there is no clear patch list of changes.

[jeremieh]

On 8/22/2021 at 12:04 PM, Redoom said:

 

But edge doesn’t have vanilla accuracy going for it

[Coraline]

Lmfao - that’s pretty much me in real life too :P 

[MTrop]

Hey, y'all - just posting here to let you know that the lastest version of DECOHack now supports DSDHacked!

 

More information here: 

 

[boris]

On 9/14/2021 at 12:05 AM, Graf Zahl said:

MBF21 was a lot of work replicating trivial stuff and Dsdhacked needed some gross hackery to work as intended with GZDoom. I have written the code but it isn't tested yet - and some of it is really shitty.

 

What's the current state of DSDHacked support in GZDoom? Sounds like you have working code, but 4.8-pre doesn't seem to support it.

 

On 9/16/2021 at 11:48 AM, Graf Zahl said:

BTW, I'd be interested to hear how Team Eternity thinks about all this, they have been quite absent from this discussion so far.

 

I asked about it on the EE Discord, and @printz didn't know about DSDHacked, but maybe @Altazimuth can say something about it?

 

IMO GZDoom and EE not supporting DSDHacked could slow down its success quite a bit.

[Altazimuth]

10 hours ago, boris said:

but maybe @Altazimuth can say something about it

Yeah, I'd discussed this, but not on forums, with kraflab and co. I had some concerns about this that, to my knowledge, have been remedied somewhat. I've been slowly plinking away at MBF21 support but work and depression has kept me from making progress at any sort of decent clip.

I'll be trying to tackle DSDhacked after MBF21 but I won't lie, I am still somewhat concerned about feasibility of implementing this into Eternity.

[printz]

@boris I was busy with other stuff at that time. When I download wads with DSDHacked I'll be more motivated to integrate it. 

[ChopBlock223]

On 11/7/2021 at 8:57 AM, boris said:

What's the current state of DSDHacked support in GZDoom? Sounds like you have working code, but 4.8-pre doesn't seem to support it.

In my experience, it's not yet complete. Weapons and monsters in Ad Mortem don't work (custom hitscan attacks and the new homing projectile functions do nothing, for instance). I'm sure it'll come eventually, however.

Also, isn't GzDoom still on v4.7.1?

 

 

[boris]

5 hours ago, ChopBlock223 said:

Also, isn't GzDoom still on v4.7.1?

 

The "pre" versions are the development versions. You can get them here: https://devbuilds.drdteam.org/gzdoom/