Posted: Fri Nov 25, 2011 2:10 pm Post subject: MBF style codepointers vs true parameterized
Hi!
How much are you(devs) into implementing some more dehacked codepointers that use Unknown1 and Unknown2 state fields as codepointer parameters? I ask this because this method is still not as flexible as parameterizing all existing codepointers, I just don't know wether true-parameterized [eg. FireBullets(numbullets, useammo, spread_x, spread_y, damage)] codepointers are going to happen in dehacked here or not. I would make feature suggestions accordingly.
The only one I know of that currently works in ZDaemon is A_Spawn, which is from MBF. There are other parameterized codepointers from MBF, in detail here, but I think these will be as far as anyone is willing to take it. The adoption of most (all?) MBF features is probably the next logical step in creating a more powerful DeHackEd environment, but I doubt we're going to see anything remotly similar to DECORATE though.
There are some pretty nifty stuff on that page. There is no need to be decorate like definition, it can be eg. 5 new state parameters which are used by the codepointers, like:
Eternity's parameterized actor specials are based off of MBF's use of Unknown 1 and Unknown 2 fields, and is indeed a very flexible system. Eternity is also still quite in development, and it has never been ZDaemon's goal to increase compatibility with Eternity or form it's own unique editing features.
Compatibility with MBF, however, I think is a different case because ZDaemon already supports a lot of its features... so if we (using "we" loosely here, as I am not a developer) were to consider extending DeHackEd in the manner you're talking about, I believe the most sensical and feasible procedure would be implementing the rest of the MBF parameterized codepointers (including ones using the Unknown 1 and Unknown 2 fields).
Eternity is just one port with features only common to itself. MBF features are common to a lot more source ports, so by implementing all of it's features, we kill two birds with one stone: ZDaemon editing becomes more feature-rich, and crossport compatibility increases; all without too much effort. MBF is also no longer maintained, so it's feature set is set in stone, meaning we don't have to keep updating things like we would have to for DECORATE or Eternity's DeHackEd.
Again, only speaking for myself here. In my opinion, ZDaemon should have an attainable goal in regards to editing features, and that would be full Vanilla, Boom, MBF, and ZDoom 1.23b support. There are already features implemented that go beyond that goal, but I think it should be a priority to "fill in the gaps" before moving onto new feature systems, especially ones that are unique to ZDaemon itself.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum