API function wishlist

Questions, comments, and news on the server side plug-ins and it's API
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

API function wishlist

Post by JeffM »

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.
ImageJeffM
User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

Post by A Meteorite »

This function would be nice...

Code: Select all

BZF_API int bz_getMaxTeamCount (bz_eTeamType team)
Which gets the maximum team count (so it couples with the current team count).
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

This has been added as

Code: Select all

BZF_API unsigned int bz_getTeamPlayerLimit ( bz_eTeamType team )
ImageJeffM
brad
Private First Class
Private First Class
Posts: 689
Joined: Sun May 08, 2005 12:26 pm
Location: UK
Contact:

Post by brad »

If a plugin changes the shot type of a player, and then that player tries to fire a GM, they will get kicked before end shot credit. Perhaps the server can check if the shot has been changed for booting a player for end shot credit? Hope this makes sense...
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by 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.
ImageJeffM
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

2.1 now has the ability to change the shot type of a tank at any time. 2.1 decouples the shot type from the actual flag.
ImageJeffM
Theme97
Private First Class
Private First Class
Posts: 221
Joined: Fri Nov 11, 2005 8:04 pm
Contact:

Post by Theme97 »

bz_eShotFiredEvent's brother, bz_eShotEndedEvent, would be nice to have.
Image
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

bz_eShotEndedEvent is done.
Docs at;
http://my.bzflag.org/bb/viewtopic.php?p=101623
ImageJeffM
User avatar
LouMan
Chief Sgt. of Cartography
Chief Sgt. of Cartography
Posts: 338
Joined: Mon Jan 31, 2005 3:05 am
Location: Michigan, USA

Post by LouMan »

It would be very interesting to generally affect tank physics (gravity, speed, etc.) from the API. Even better (but impossible as far as I know) would be to individually affect tank physics; you could create low gravity zones, etc.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by 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..
ImageJeffM
Thumper
Private First Class
Private First Class
Posts: 34
Joined: Tue Sep 28, 2004 9:22 pm
Location: Toronto, Ontario, Canada
Contact:

Banlist handling functions

Post by Thumper »

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.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

ImageJeffM
User avatar
Tropican8
Private First Class
Private First Class
Posts: 312
Joined: Fri Mar 18, 2005 11:51 pm
Location: As close to the grove as you can get

Post by Tropican8 »

It would be really nice to have a way to reset variables from a plugin too. (the /reset * command).

This would allow someone to make a plugin to restore vars at a set time once people are done messing with them.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

ImageJeffM
brad
Private First Class
Private First Class
Posts: 689
Joined: Sun May 08, 2005 12:26 pm
Location: UK
Contact:

Post by brad »

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.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

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.
ImageJeffM
Enigma
Private First Class
Private First Class
Posts: 212
Joined: Sat Apr 23, 2005 3:13 am

Post by Enigma »

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.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

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.
ImageJeffM
User avatar
macsforme
General
General
Posts: 2069
Joined: Wed Mar 01, 2006 5:43 am

Post by macsforme »

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.
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?
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

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.
ImageJeffM
User avatar
Links 2004
Private First Class
Private First Class
Posts: 85
Joined: Sat Jan 01, 2005 6:54 pm
Location: Ger
Contact:

Post by Links 2004 »

hi,
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
Events:

Code: Select all

bz_ePlayerDieTkEvent
bz_ePlayerNrEvent
so :)

hoppe the functions came in.

Links 2004
Clan: Links
Clan web: http://links-clan.net
ImageImageImageImageImageImageImageImageImageImage
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

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.
ImageJeffM
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

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.
Optimism is just a milder alternative to denial.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

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.
ImageJeffM
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

Cool. Also, what happens if more than one plug-in tries to handle the same command? being able to chain the calls could be useful for things like /poll. Order wouldn't matter that much as long as they were called before the default command.
Optimism is just a milder alternative to denial.
Post Reply