Official forums for BZFlag.org

I'm thinking of setting up a development environment to develop a plug-in for throwing the team flag.

The idea behind this is to allow for a method of passing a team flag to another player.

It would work in the following way:
The drop position would be calculated based on the current tank position and the current velocity.
There will be a config parameter for maxFlagThrowDistance.
A stationary tank will drop in the current location, while a tank going at full speed will drop the flag maxFlagThrowDistance in front and a reversing tank will drop the flag some distance behind. Only the tank's X & Y movement and current location are considered, while the tank's orientation is ignored.

If the calculated drop location is not safe (and the tank is moving) then locations will be tested in a linear fashion in a finite number of steps each getting closer to the tank position. This of course could mean that a valid drop zone might have been overlooked, but if you can't pass accurately, then it's your own fault. For example, if you try to pass the flag outside the map, then the flag would instead end up at the wall, but not necessarily right up against the wall, rather at the first location within the map that was tested and considered safe.

A quick look at the sources shows me that I can get the bz_eFlagDroppedEvent and there seems to be enough parameters in the bz_FlagDroppedEventData for me to perform my calculation. I realise that the FlagDrop has already been handled by the time I get this event, but it looks like that will not be a problem, since I can get the initial drop location and tank's velocity from the playerID.

I noticed that sendFlagUpdate()...broadcastMessage(MsgFlagUpdate) will have already been called before I get the event. I'm hoping to prevent a scenario where the players see the flag fly back to base and then fly again to my newly calculated location. Is there a way to prevent this scenario?

Anyway, before I go ahead with this, I'd like to hear from someone experienced in development with BZFlag as to whether this is in fact feasible.
Also, will it still work with the imminent release of version 3?
Would I be best waiting until this is released and provide the plug-in for that instead?

I very much enjoy playing BZFlag, and being a developer, I feel a little guilty that I haven't contributed to the development in any way. I generally play to get a break from work so I hope you will forgive my reluctance. Anyway, this seemed like a reasonably simple first step and it might encourage me to be more active in the development in the future, so anything you can contribute to make this easier for me would be much appreciated.

Also assuming I develop this plug-in, what happens then?
How do I go about advertising it and making it available to server owners?

Looking forward to hearing your responses.

- FiringSquad

Well for the release and advertisement of this plug-in, you would put it in the "Plug-in Releases" topic (which is under Servers). I am curious though, as to how you are going to place the team flag somewhere else on the map on flag drop. I understand the flag drop event, as it is used in the thief control plug-in. But as far as placing the flag at a specific position, don't think I have ever seen that done except through using zones. Not saying that it can't be done (and it may not, just don't know), just having an issue figuring out how.

bz_eFlagDroppedEvent and bz_moveFlag()?

Will this show the flag being dropped twice?
Ideally I'd like to see flag "fly" to the new location directly from the tank.
This might mean I would need to program a bz_eFlagDroppingEvent that would allow me to alter the drop position before the initial broadcastMessage(MsgFlagUpdate) which would mean an alteration to the server code (which, although it's an easy mod, I'm trying to avoid).

Well according to the wiki ( http://my.bzflag.org/w/Bz_moveFlag ) the flag will just be 'zapped' to the new position, no "Flying" involved.

Useful Wiki - Thx

It seems the "zapping" is an option in version 3, so I guess I'll just try it and see what happens, or step through with a debugger.

Anyway, my interest is piqued, so I'm definitely going to give it a try once I find the time. If I can't get to it in the next few weeks, then it will have to wait until August. Maybe version 3 will be out by then.

Anyway, thx for all the help. I expect I'll be back again soon with some silly noob question once I start.

Cool, good luck

Well I'm finally getting around to doing this and to prove it, I have some problems.

The flag position in the bz_FlagDroppedEventData is the position after dropping. I need the position of the player that dropped it so that I can calculate the correct landing position.
In the latest API there are the calls bz_getPlayerPosition() and bz_getPlayerVelocity(), but these are not available for BZ_API_VERSION=16, which is the current release build.
I can get the position from the bz_PlayerRecord after calling bz_getPlayerByIndex() and passing the in the playerID from the bz_FlagDroppedEventData, but what is the best way to get this player's current velocity?

Secondly, I need to test a particular drop location to see if it is safe. I was hoping to do this with something likebut these objects do not seem to be available to the plugins. What is the appropriate way to do this from within a plug-in?

I'm hoping one of you gurus can point me in the right direction and save me a few hours trawling through the code and putting together a nasty hack.
I assume there's an elegant way. Any guidance?

Thanks in advance.

FiringSquad wrote:I assume there's an elegant way.

I think you assume too much I believe it would be a horribly ugly hack...

The server does not track player positions over time in 2.0.x.In 3.0 it does a simple linear interpolation. There is no accurate way to get a player's position at any time. All you can do is get the last updated position.

The last updated position is fine. In fact I have that already from the bz_PlayerRecord. My problem is the current velocity. How do I get that?

Hmmm...

It would be so easy if I could make some small server mods.
What are my chances of getting the following mods into the standard trunk?

1) Add a bz_eFlagWillBeDroppedEvent event that will allow plugins to intervene before the flag is dropped. (not absolutely necessary)
2) Include the bz_getPlayerPosition() and bz_getPlayerVelocity() calls in "bzfsAPI.h" (along with possibly a few other useful calls available only in the latest API).
3) Add a GetCurrentWorld() and GetFlagInfoForFlag() to "bzfsAPI.h"

They would be relatively simple to implement and shouldn't cause any difficulties. (and would be useful for other developers)

If I was to make some server mods, I'd love to to give plugins the chance to change the characteristics of a bullet and include a lethal property , so that the bullets could be harmless until the plugin armed them.
That way it would be possible to do something like only allow bullets to kill after a rico, or even something as quirky as only after it passes through a tele.
But that's for another time.

I've just been told that with in Version 3, Lua scripts could allow the rico activation of bullets and lots of other stuff too. Cool
All the more reason to get it released soon

imho we need that release very soon!!!
with a HUGE thanks to trepan you can test that only-deadly-bullet-if-rico at
001.bzflag.fr:5198 > zeBestOf09 ::: lua-rule: only a rico-shot can kill ::: lua-script by trepan
and as it seems ::: this is just the very tiny small tip of the iceberg of all the lua possibilities!

but back to the subject and I can imagine that it is a difficult situation in working and spending time in developing a plugin and not knowing when and if the version 3 will be released. all the sweat would become obsolete when V.3 will be out because lua could do this very easily without moding the server.

but I would love so much to see the flag-passing possibility as a wished-for-a-long-time-feature for a new game-play and style (especially for the upcoming BzWorldCup ;)!


.

OK I've pretty much finished coding this and thanks to some advice from mrapple, I was able to achieve it without any server mods.
I'm just testing things now and when ready I will release it.
If you would like to see a very early version of the source, then you can see it here.
It's not quite ready for release, but you will certainly be able to get a feel for it, should you wish to compile and install it.

Essentially the flag flies in the direction you are traveling and the faster you go the further it flies. You can even send it backwards and through walls.
The distance the flag flies is configurable.
If you jump while dropping then it will fly even further. Of course, this is likely to result in you being shot as you land.
If the landing position of the flag is unsafe, then it is considered a fumble.
Depending on the configuration, the plugin may try to find a safe location closer to you.
If no safe location is found then a standard drop occurs.

It takes a bit of getting used to, but there is a definite skill in getting the flag to fly to where you want and it was this requirement for a level of skill that I was looking for.
I had considered options like locking on a player and passing to them, but that could result in instant caps etc. and I don't think that would add anything to gameplay.

Only two problems I can see right now.

1. You need #include <assert.h> at the top of the file

2. You can throw normal flags. Might want to do some checking to make sure its a team flag before the plugin flys it (throwing normal flags looks very cool)

Thanks mrapple,
It is intended that normal flags can be thrown. In particular this was written for the WorldCup league so that the tiny flag could be thrown.
I will add a configuration possibility /fpass allflags=[on|off] which will restrict it to teamflags only when allflags=off.
I've added the code in Servers:Plug-in Releases here http://my.bzflag.org/bb/viewtopic.php?f ... 97#p150597
Perhaps any further conversations about this plug-in could be done there.
Thanks again.

Version 1.0.0 is currently installed on 001.bzflag.fr:5157
You can get a feel for how the plug-in works there but to get the full effect you would need jumping too.

Thx Zaphod.

Pretty much finished with Version 1.0.2

Who's bright idea was it to was it to add an option to not pass the flag when the player was killed?
Wonderful idea but it was a nightmare to implement.

It seems that the client sends the flag drop message before it sends the reason it dropped it.

I've had to add a delay in processing the Drop Event to give time for the client to send more info.

Not being familiar with the API, I wonder if someone with more experience developing for BZFlag could take a look at my code.

I've added the complete code as an attachment, but if you are impatient, you can look at the c++ here and ReadMe.txt here.

In particular, I'd like to know if there is a better way.
Also, are there other times a flag will be dropped that I don't take account of?
And finally, advice on a standard "maxwait" value would be helpful (if it is still needed).

Thanks.

- F.S.

At the moment I discard "Drop the Flag" events that are too old, where I have not received any updates from the client to say why the flag was dropped.
I am going to change this to assume that the flag was passed once the event becomes old. From my investigations, in situations where the flag was dropped for some unusual reason, like "user kicked" or "user found antidote flag", the update comes relatively fast. Mainly because the client will send the messages one after the other before doing anything else.
It's only in situations such as when the user drops the flag while jumping that a big delay arises, in this case since nothing "extra" is happening there is no need to send an update.

This should allow the MaxWait value to be made smaller and provide a better user experience.
Anyone care to tell me I'm wrong before I make the modifications?

Well, I think this is the right place to post.

from BZWC as a League

FiringSquad wrote: Do i need to add an offside rule?

Yes, please.