

About the program
-----------------

BRUNHOST is a stand-alone program that can manage a CFS multiplayer session.  It does not
use any of the CFS dll's, and does not even require CFS to be on your system.

For those of you that are interested, I do not know EXACTLY how CFS works.  I have not taken
apart any CFS code to learn how it functions.  Because of this, my program does not behave
exactly like CFS does.  Packets are not sent in the proper order, and it does not even send
many of the packets that CFS normally does.  I only implemented the things I needed to to get
this thing to work.  Everything that I learned about how CFS functions was learned thru testing
in normal CFS multiplayer sessions, thru the use of a packet sniffer in the early stages, thru
the use of default switch statements and thru deduction.  Needless to say, it has been somewhat
hit and miss along the way.  Had I realized it would take this long to get to this point, I
probably never would have started this in the first place, but I have soooooo much time into
it now, that I almost feel obligated to get it out there.

I'd just like everyone to note that this program is much more complicated than many of the
ones currently available for CFS, primarily because I cannot just simply test this ofline.
Online play is REQUIRED for testing to make sure that it's all working correctly, and due
to the large number of variables involved, it is very difficult to ensure that everything
is working as it should.  Testing is not enjoyable for me because when there are problems,
all the people in the game are affected by it.  To make things even more difficult, I can't
see what is happening on everyone elses system, so it is difficult to know when there are
problems, and when there are problems, I can't see the other players' screens to help determine
what may be causing the problems.

I offer this as an apology for any bugs this program contains, and I will do my best to fix
any that are found.


Notes on features, problems and why I have set up this program in the way I have.
---------------------------------------------------------------------------------

1. Program can only host.

Most of the features of this program can only work when the program is host.  Originally
I had the program capable of joining because each object was managed by a separate instance
of the program.  When the program joins, it can only bring a target into the game.  I felt
that if allowed to join, troublemakers might try to disrupt a game by bring many objects
into a game, lagging it out.  By limiting the program to hosting only, it allows me to
manage multiple objects within a single instance of the program.


2. Teams set up by Brunhost, players cannot create new teams.

I chose to handle teams in this way for 2 reasons.  First, to make things easier, and second,
because it is neccessary in order to implement a possible new feature in the future.  This
feature has to do with the simulation of bombs being dropped.  The basic idea is for targets
to watch the bombers, and when a bomber reaches a certain distance from a target, it will
be assumed that bombs are dropped.  If the bombers heading is correct, then after a delay
based on the bombers altitude, the target will explode as tho hit by the bombs that were
'dropped'.  This allows the target to react as tho bombs are dropped in multiplay.  It is
just a possible way to get around the 'no bombs in multiplayer' problem.  If enough folks
like this idea, then I will try to implement it.


3. Can't change target aircraft.

Before I started using the .air files to adjust the altitude of target objects, I had to 
adjust the altitude in the configuration whenever I changed the target to a different 
aircraft.  Now that I use info from the .air files, changing target aircraft during a
session becomes feasable.  However, it will require some time too implement it.  If enough
people want this feature, then I will probably add it, but probably not.


4. Can eject players.

Since my program acts as host, this was pretty much a needed feature.  Works in the same
way as it does in CFS.  However, there is an autoboot feature that allows you to keep
problem players from joining your sessions.  One nice thing is that it allows you to eject
players without having to return to the Ready Room.


5. First player to destroy X not supported.

In my mind, this is only really useful in a FFA type of game.  With targets in the game,
all players have a mission goal, so first to destroy X doesn't really make sense.


6. When all players are in RR, targets return to RR too.

This is just one of the things I have done to try to automate the session as much
as possible.  Mainly, I want BRUNHOST to just be running in the background, without
the need of input by the person hosting the session.
 

7. Cannot change targets team.

This also has to do with the ideas mentioned in #2.


8. Players not allowed to join target team.

No explaination really needed here.


9. Primarily for straffing runs.

Since there are not yet bombs in multiplayer, Straffing runs and last alive team games have 
been the main use of this program.  I am aware of simulated bombs using downward pointed
groups of guns, but I have yet to see an example that works well.  I have already mentioned
one way that my program might simulate bombs in multiplayer.  There is another possibility
that might work as well.  It may be possible for this program to bring 'Bomb' type players
into the game.  These 'players' would be objects similar to the targets, except they would
track the host's bomber.  When the host presses the 'Bomb' key, they would appear in the
game, dropping from the host's bomber.  This would ONLY work for the host.  This would take 
quite a bit of work to implement, but I believe it to be possible.


10. DP is sent.

BRUNHOST sends a target objects .DP files just like CFS does.


11. Cannot change targets name.

Doesn't really seem to be the need to change the names of targets.


12. Teams only, no FFA.

FFA doesn't really make sense given in a bomb/straffing run.


13. Maximum of 8 target objects

Mainly to minimize lag.  This was bumped up from 4 to allow the use of dummy targets at team
starting locations to prevent warping in CFS2.


14. Scores not working correctly. (Currently disabled)

Scores are correct in HUD view.  When player dies, Final Tally scores are correct.  When
player Escapes to Ready Room, scores are not neccessarily correct.  Basically, I am having
problems with trying to manage the scores.  I am still working on this one.  Am NOT sure 
I will be able to fix it.


15. Even tho win criteria can be None or Last Alive, while in game, it is Last Alive.

In order to ensure that players always start at proper location and heading, win criteria
is always set to Last Alive while in the game to force players back to Ready Room when they
die.  They would respawn at the proper location if I allowed them to respawn, but the heading
when respawning in semi-random.  By forcing players to the Ready Room when they die, it allows
me to send the proper heading when they re-enter the game.


16. No fun info

This works by allowing players and targets to go into the game from a Waiting state instead
of the normal Ready state.  When players go directly from Waiting to In Game, CFS will not
allow those players to be locked onto, and they will not show up in radar.  This is why
players must return to the Waiting state after Readying up.  The Ready up state is needed
to make sure all players are in fact Ready before launching them into the game.
Note:  The 'NF Launch now' button can now be used to launch manually.




Some ideas for other possible features.
---------------------------------------

1. Death limits.

Could allow players more than 1 death in a Last Alive game.


2. Moving target objects.

This one is a bit tricky.  As described in the 'Bomb' players idea, requires a fair amount
of work to implement.  The main problem has to do with syncronization.  CFS uses a sync
packet sent every 5 seconds to try to syncronize all players in the game.  I assume this
is used by CFS to try an calculate player positions to compensate for latency effects.  I
have not fully figured out how the data in the sync packets are generated or used.  Therefore,
it would take some work to figure this out as it needs to be used for my program to implement
any moving targets or other objects.

My program would also have to calculate target positions continuously, which would complicate
the code further.

Moving objects would also require a list of waypoints in the object configuration.

Moving ground objects may require a significant number of waypoints since brunhost has no
idea where the ground is.  Therefore, the waypoints for these types of objects would require
altitudes, and the CHANGE in altitude between waypoints must be constant.

If an object is to change direction when it reaches a waypoint, I would probably have to in 
some way try to make the change in direction somewhat smooth and realistic looking.  Even 
more code.

Moving objects can be done, but as you can see, they will require some work.


3.  Shooting targets.

Having targets shoot is easy.  Having them shoot AT something is a different story.  Would
require tracking objects, determining alliance, calculating lead, etc.

On top of all this, it would require some form of collision detection, and it would require
detection with all HITBOXES IN THE GAME.  Ouch.

I could track and aim, and prolly even calc lead, so it would appear that a player is being
shot at.  I COULD just assume that some percentage of of the rounds hit, and just send
damage packets, but I do not wish to even consider trying to do real collision detection.

One other problem with this is that fact that it would require models to be modified.  In 
multiplayer, guns cannot change direction on other 'players' aircraft.  Guns are always shown
shooting in the direction defined in the DP.  They cannot swivel like AI guns do.  In order
to have guns shooting in different directions, the object would have to be turned in the proper
direction (to get the guns firing based on that direction) and the model would have to be rotated
back in the other direction to get it back to its proper orientation.  Ouch.  Since Brunhost
is intended to be used with default installations, I really don't wish to package a new object 
library with the program do deal with this.

