ZDaemon Forum Index ZDaemon
Client/Server DOOM
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

MBF style codepointers vs true parameterized

 
Post new topic   Reply to topic    ZDaemon Forum Index -> ZDaemon Development
View previous topic :: View next topic  
Author Message
MidnightWolf
has entered the game!


Joined: 24 Nov 2011
Location: Hungary

PostPosted: Fri Nov 25, 2011 2:10 pm    Post subject: MBF style codepointers vs true parameterized Reply with quote

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.
Back to top
View user's profile Send private message
EarthQuake
Wicked Sick!


Joined: 02 Apr 2004
Location: Athens, Ohio. Dieblieber gonna getcha!

PostPosted: Fri Nov 25, 2011 4:46 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
MidnightWolf
has entered the game!


Joined: 24 Nov 2011
Location: Hungary

PostPosted: Fri Nov 25, 2011 6:14 pm    Post subject: Reply with quote

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:

Code:
Frame 105
Arg1 = 33
Arg2 = 43
Arg3 = 53
Arg4 = 63
Arg5 = 73
Duration = 5
Sprite number = 133

[CODEPTR]
Frame 105 = ACSExecute


This is more flexible than using unknown1 and unknown2, since at weapon frames they are used for sprite offsetting.
Back to top
View user's profile Send private message
EarthQuake
Wicked Sick!


Joined: 02 Apr 2004
Location: Athens, Ohio. Dieblieber gonna getcha!

PostPosted: Fri Nov 25, 2011 11:48 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ZDaemon Forum Index -> ZDaemon Development All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group