search

Realm667 / WolfenDoom

"WolfenDoom - Blade of Agony" | Important: This is only meant for development and testing purposes. You are NOT ALLOWED to use material from this repository for your own projects. Important: This repository is for development and testing purposes, you are NOT ALLOWED to use the copyrighted material for your own projects without our permission!
http://boa.realm667.com
259 stars 26 forks source link

[3.2] The legacy of DECORATE #785

Closed Username-N00b-is-not-available closed 2 years ago

Username-N00b-is-not-available commented 3 years ago

From the depths of the GitHub server HDDs... ...emerges the resurrected DECORATE issue.

When the code conversion was suggested in #470, a few very valid points were raised by the team members regarding further improvements of the translated code, i. e. rewriting DECORATE hacks that could be implemented much easier and cleaner in ZScript. This means only the ones that could be replaced while retaining the already-existing behaviour: if a feature could only be done in GZDoom by dirty means, it would be silly to remove it just for the code to become 'cleaner'. I seriously do not know how many of such messy code portions we currently have. If @Ozymandias81, @AFADoomer and @Talon1024 view the cleanup as necessary, this issue can serve as the headquarters for the rewriting initiative. I do not think I could participate myself as actively as it was with #470, but if we manage to implement a plan of work, I'll try to help.

Class diagrams As a starting point, here are some 'class diagrams' of everything ZScript in BoA (the tree was gathered yesterday), maybe they could be of some help while recording the progress, or at least building a picture of what is currently going on in those 100k lines of code. [CSV of all classes](https://github.com/Realm667/WolfenDoom/files/6616971/classes.zip) [.png with all classes (warning: 10MB)](https://github.com/Realm667/WolfenDoom/files/6616913/graph.zip) All descendants of ```Base```: ![graph_base](https://user-images.githubusercontent.com/59409713/121194517-797f9580-c877-11eb-997f-4b8e00f01d8e.png)

Ah, by the way: we still have version "3.7.2" in the ZScript file.

Edit (10 Jun 2021): list of files in /scripts/decorate that have already been inspected and de-hacked (pun intended)

/critters

/hazards

/items

/misc

/models

/monsters

/props

/sfx

/weapons

AFADoomer commented 3 years ago

A lot of the actor's will need minimal work; mostly consolidation into the correct file and some formatting cleanup.

Anything that uses complex Spawn state actions to set initial behavior, convoluted jump statements, or inventory-token-based checks probably should be cleaned up.

Username-N00b-is-not-available commented 3 years ago

Yeah, I forgot about the formatting, too, a lot of it was lost in the process of conversion... Let's not remember how :-) Definitely agree on the initializing and the jumps, where many copy-pasted lines can be combined into a single anonymous function. As for the inventory checks, most of them seem to be present on weapons, so hopefullly this would not be too much work.

By the way, @AFADoomer, what do you think about reducing the total class amount and simplifying the inheritance tree by merging similar decorative actors into one, CivilianZombie-style? If we use arg0/arg1/... instead of a custom user_variant field, we can avoid editing the maps to convert the actors, because thing arguments can be assigned to DoomEdNums right from MAPINFO. Even in the Base subtree from the 'class diagram' I can already see HelmetlessMarineXX and MarineXX classes, and the crows (which differ only by their spawn flags IIRC) that could benefit from this. Information on possible variants then would be put into GZDB tooltips, of course. I also had thoughts about the same for enemies alongside with decorative actors, though it could be a really bad idea.

AFADoomer commented 3 years ago

Yeah, that's the other main thing to look for. There are a lot weird inheritances and new actors with minor changes that can be consolidated.

The reason for using a user variable was to allow setting a variant while still allowing. A special to be set on the actor... but that could be a trade-off.

Ozymandias81 commented 3 years ago

Some inheritances were made with the old shadows method in mind, and to also exclude some certain actors from thinkers (NOINTERACTION ones) plus instead others to be slightly active (on CUTSCEN# maps). As of now though there should be also a "Fade" state that can be triggered via custom fields which needs to be removed, there was a plan for that to be used in game for the end sequence, where dead bodies should have "fade" away and then the cutscene continue. Thus there are also some peculiar inheritance to look onto models for example, atm a couple of them seems to behavior differently from past times and also even meals over tables too

Username-N00b-is-not-available commented 3 years ago

Damn, I'm no sniper.

Tormentor667 commented 3 years ago

I wonder: Is this something that still needs to be taken care of or not? And how much work is involved and how much outcome do we get from investing the effort? Sorry for asking so dumb, but I am simply not used to the code-department of our game.

Tormentor667 commented 2 years ago

No feedback so I guess we can close this for now.