API function wishlist
API function wishlist
I'd like to know what API functions people have been wanting/missing/wishing for as they work on plug-ins. So if you got something you've wanted or needed, let me know here.
Please note that there are many things that the API can not do, don't be afraid to ask, but just understand that if we say it' can't be done, that it can't easily be done.
Please note that there are many things that the API can not do, don't be afraid to ask, but just understand that if we say it' can't be done, that it can't easily be done.
JeffM
- A Meteorite
- Private First Class
- Posts: 1786
- Joined: Thu Apr 28, 2005 12:56 am
- Location: California, U.S.
- Contact:
This function would be nice...
Which gets the maximum team count (so it couples with the current team count).
Code: Select all
BZF_API int bz_getMaxTeamCount (bz_eTeamType team)
Owner @ BZFX
Core Admin @ CAN
Email me: bzmet…@gmail.com
This has been added as
Code: Select all
BZF_API unsigned int bz_getTeamPlayerLimit ( bz_eTeamType team )
JeffM
The core problem is one of changing shot types. The client isn't notified of the shot change, so the client and server get out of sync. The proper solution for this is to have the server tell the client what kind of shot it fires with each flag pickup. Then everything will be in sync. This can not happen in the 2.0.x protocol.
JeffM
We've talked about that a bit. It will take some reworking, but it will be more flexible. We basically were looking at making every tank parameter just be sent to the client from the server. So the client doesn't know WHY it's got these prams, it just does. This includes per tank gravity, speed, acceleration, etc..
JeffM
-
- Private First Class
- Posts: 34
- Joined: Tue Sep 28, 2004 9:22 pm
- Location: Toronto, Ontario, Canada
- Contact:
Banlist handling functions
It would be really helpful to have a way to reload the banlist and masterban lists (separately) from a plugin.
This would allow a plugin to reload a shared banlist efficiently instead of having to resort to using a bzadmin process or bzfscron to periodically do banlist reloads.
This would allow a plugin to reload a shared banlist efficiently instead of having to resort to using a bzadmin process or bzfscron to periodically do banlist reloads.
Would it be possible to add an extra arg to bz_killPlayer() to determine whether or not the person killed loses a life? I need to kill everyone on the map after each cap, and it seems unfair to punish people by taking away a point after every cap. It might even discourage team play if they know they are going to lose a life.
I'm not sure what you mean by "a life", as far as I know in bzflag, you can respawn as many times as you want.
if your talking about there score, in 2.1 you can set the score after you kill them, and give the point back if you want.
in 2.0.x the score is handled by the client and we can't change it remotely.
if your talking about there score, in 2.1 you can set the score after you kill them, and give the point back if you want.
in 2.0.x the score is handled by the client and we can't change it remotely.
JeffM
Is it possible to add a function that generates shot id's? Maybe something similar to int glGenLists(int range). I have had problems using bz_fireWorldWep with a range of id's that I am using (I'm using alot of world weapons); sometimes the server generates another shot with an id within that range. It would be great if I could reserve a range for the world weapons.
Also, whenever I pass a player id to the fromPlayer parameter of bz_fireWorldWep, the victim's client segfaults. Everything works ok when I pass BZ_SERVER instead of a player id .
What does float dt do?
BZF_API bool bz_fireWorldWep ( const char* flagType, float lifetime, int fromPlayer, float *pos, float tilt, float direction, int shotID , float dt );
Would it be possible to get a function like bz_removeWorldObject to accompany the bz_addWorldObject functions? What I mean is to be able to add an object and be able to remove it later on.
Also, whenever I pass a player id to the fromPlayer parameter of bz_fireWorldWep, the victim's client segfaults. Everything works ok when I pass BZ_SERVER instead of a player id .
What does float dt do?
BZF_API bool bz_fireWorldWep ( const char* flagType, float lifetime, int fromPlayer, float *pos, float tilt, float direction, int shotID , float dt );
Would it be possible to get a function like bz_removeWorldObject to accompany the bz_addWorldObject functions? What I mean is to be able to add an object and be able to remove it later on.
Shot IDs are interesting, but yes something can be made. You would not be able to "reserve" any, but simply ask for an ID each time you need one, in 2.0.x there may be a limit to how many can be "live" at any one time.
yeah the playerID must be the server for 2.0.x, the client won't accept anyone else. Enhancements to this can be made for 2.2, as it will be incompatible.
No, we can not remove world objects, after the server has started. BZFlag uses a static world, once the world is finalized, that's it, nothing can move, nothing can be added, and nothing can be removed.
yeah the playerID must be the server for 2.0.x, the client won't accept anyone else. Enhancements to this can be made for 2.2, as it will be incompatible.
No, we can not remove world objects, after the server has started. BZFlag uses a static world, once the world is finalized, that's it, nothing can move, nothing can be added, and nothing can be removed.
JeffM
Aw, but that would be really cool... is this completely out of the picture, or is it a possibility for a future release as time goes on and more features are added?JeffM2501 wrote:No, we can not remove world objects, after the server has started. BZFlag uses a static world, once the world is finalized, that's it, nothing can move, nothing can be added, and nothing can be removed.
Constitution
lots of things would be 'really cool' but bzflag just doesn't work that way right now.
anything is possible with enough work, you'd have to redo a huge chunk of the world handling stuff and have a way to perfectly sync with the server. If someone is willing to do the work to make it possible, and solve all the associated problems in other parts of the code, sure it can be done.
lots of things would be 'really cool' but bzflag just doesn't work that way right now.
anything is possible with enough work, you'd have to redo a huge chunk of the world handling stuff and have a way to perfectly sync with the server. If someone is willing to do the work to make it possible, and solve all the associated problems in other parts of the code, sure it can be done.
JeffM
- Links 2004
- Private First Class
- Posts: 85
- Joined: Sat Jan 01, 2005 6:54 pm
- Location: Ger
- Contact:
hi,
i have many wishs
Functionen:
Events:
so
hoppe the functions came in.
Links 2004
i have many wishs
Functionen:
Code: Select all
BZF_API bool bz_setPlayerTeam ( int playerId, bz_eTeamType team );
BZF_API bz_eTeamType bz_getPlayerTeam ( int playerId );
BZF_API bool bz_setHuntedPlayer ( int playerId );
BZF_API int bz_getHuntedPlayer ( );
BZF_API bool bz_unsetHuntedPlayer ( );
BZF_API bool bz_getPlayerNR( int playerId );
BZF_API bool bz_delFlag( int flag );
BZF_API int bz_addFlag( int flagtype ); //return flag id
Code: Select all
bz_ePlayerDieTkEvent
bz_ePlayerNrEvent
hoppe the functions came in.
Links 2004
BZF_API void bz_changeTeam( int player, bz_eTeamType team );
is in 2.1.x, it needed a protocol change to support so it can't be in 2.0.x.
you can get the team from the PlayerRecord returned by
BZF_API bz_BasePlayerRecord *bz_getPlayerByIndex ( int index );
the hunted players are set per client, not at the server, so they make no sense for a server side plug-in.
The NR stuff can probably be done with some changes on the server.
You can't realy change the number of flags at runtime, the internals for bzfs are not realy set up for that I think, so an add and delete is not really feasible at this time.
you can detect the TK on the existing death event when the team of the killer is the same as the team of the person killed, so you have that already.
is in 2.1.x, it needed a protocol change to support so it can't be in 2.0.x.
you can get the team from the PlayerRecord returned by
BZF_API bz_BasePlayerRecord *bz_getPlayerByIndex ( int index );
the hunted players are set per client, not at the server, so they make no sense for a server side plug-in.
The NR stuff can probably be done with some changes on the server.
You can't realy change the number of flags at runtime, the internals for bzfs are not realy set up for that I think, so an add and delete is not really feasible at this time.
you can detect the TK on the existing death event when the team of the killer is the same as the team of the person killed, so you have that already.
JeffM
I would like to be able to override standard server commands with plug-ins. For this to be useful, there would also have to be an "ignore" function in the API to not handle a command through the plug-in, but rather to pass it to BZFS to be handled in the default manner.
This would prove incredibly useful for adding new options to /poll, adding additional perms to /set, and general expansion of existing commands.
And, if it hasn't been done so already, an implementation of the entering and leaving zone events that are described in the API docs would be nice.
This would prove incredibly useful for adding new options to /poll, adding additional perms to /set, and general expansion of existing commands.
And, if it hasn't been done so already, an implementation of the entering and leaving zone events that are described in the API docs would be nice.
Optimism is just a milder alternative to denial.
so you'd want to be able to install a handler for an existing slash command, and then if you handle it, don't call the default, if you do then pass it allong?
the custom slash command handler already has a return type for that, we'd just have to change the call order, it's probably pretty easy to do.
the custom slash command handler already has a return type for that, we'd just have to change the call order, it's probably pretty easy to do.
JeffM