Preparation: Player pointer selectors beyond 8

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Preparation: Player pointer selectors beyond 8

Re: Preparation: Player pointer selectors beyond 8

by Graf Zahl » Sat Sep 27, 2014 1:06 am

kevans91 wrote: Not a ZDoom developer, but judging from Major Cooke's recent efforts it would seem that pull requests on Github are more effective than posting here- understandably so.

Not only that, this currently looks like WIP. It really makes more sense if you finish your work in your own Github repo and then make a pull request when all is done. As I see it right now there is very little use adding this right now. It'd have a direct effect on the scripting branch, if it ever gets revived, and that only makes sense if something real can be gained from it.

Re: Preparation: Player pointer selectors beyond 8

by kevans91 » Fri Sep 26, 2014 4:00 pm

Hello there,

Not a ZDoom developer, but judging from Major Cooke's recent efforts it would seem that pull requests on Github are more effective than posting here- understandably so.

As for FxGlobalFunctionCall and ArgsList- the dtor does a SAFE_DELETE(ArgList), and ArgList is a TDeletingArray, so they should all get deleted then.

Preparation: Player pointer selectors beyond 8

by FDARI » Fri Sep 26, 2014 1:12 pm

Aaptr_playernum(int number): Create a player pointer selector. Aaptr_playernum(0)...Aaptr_playernum(7) can be used in place of AAPTR_PLAYER1...AAPTR_PLAYER8. Aaptr_playernum(8)...Aaptr_playernum(127) have no current purpose, but will automatically work if zdoom player limits are increased. Thus the pointer selection system for players can keep up until zdoom supports more than 128 players.

The function exists for Decorate and ACS.
The old constants (AAPTR_PLAYER#) work exactly as they always have.

It would be possible to raise the limit further than 128, but by the time that might be relevant, we'll all be bathing in milk and Doomscript.

Special notes:
Trying to generate a selector value that does not fit (playernumber < 0, playernumber >= 128) will result in the selector AAPTR_NULL being returned.
Trying to resolve a selector to a player-pointer that isn't in the game returns null, as it has always done.
A player that isn't supported (player 9/Aaptr_playernum(8) and upwards) isn't in the game.

Also: I think... I might have come far enough actually to create a pull-request on this one.

What's the preferred approach here? Do everything via Github and not bother with the code submissions forum? I haven't kept up with you guys.

EDIT: Oh... I missed the ACC patch, naturally. A single new zspecial entry. Too tired to fix now.
Question of memory management: When you delete a FxGlobalFunctionCall, is every expression in its ArgsList also deleted?
Attachments
moreplayerpointers.patch.txt
(5.82 KiB) Downloaded 82 times

Top