-------------
Thank you very much for your interest in
iBeta. The response regarding the Falcon 4.0 1.08i patches and FAQ has
been overwhelming. We appreciate your thoughts and good wishes.
iBeta is a
quality assurance and testing company, and our primary goal is to test products
on behalf of our clients. We do not give direct support to our client's
end products. Our support will be given through regular updates to the
FAQ, which can be found linked to our homepage at www.ibeta.com.
Unfortunately
because of the volume of email, we cannot offer support for Falcon 4.0
through email channels or via the phone.
If you have any
comments, feedback, or ideas for future FAQs, we'd love to hear about them, but
at this time we cannot guarantee a response to each email that is sent to
us.
Thank you again
for your interest in iBeta, and thank you for your understanding.
NOTE: This file is not a self-extracting or self-installing file. You must extract the file and manually place the EXE into your Microprose/falcon4 directory.
1 - Download the
falcon4_108i2.zip from www.ibeta.com
2 - Extract the
falcon4_108i2.exe and place it in the MICROPROSE/FALCON4 directory
3 - Create a shortcut for
the EXE and place it on your Windows desktop
4 - Right click on the new
desktop shortcut and select the shortcut’s PROPERTIES
5 - Add the “-pf” command to
the TARGET line so it becomes:
C:\Microprose\falcon4\falcon4_108i2.exe
–pf 100 <- (example)
6 – Choose OK
7 – Begin playing Falcon 4.0
**Although this is primarily
a multiplayer EXE, single players should use this EXE as well as it contains
some additional crash log fixes. Single
players do not have to use the –pf command (step 4 and 5 above) if they do not
ever expect to play multiplayer games, though it should not hurt if they choose
to include it.
**It is important that all
players who wish to use the falcon4_108i2 patch in multiplayer use the same
patch version and the same “–pf” settings.
More on the connection settings below.
----------------------
THIS IS AN UNOFFICIAL RELEASE. HASBRO TAKES NO RESPONSIBILITY TO
SUPPORT THIS EXECUTABLE.
The only support that this
executable will receive is the FAQ at www.ibeta.com.
iBeta will try to keep it as current and informative as possible.
----------------------
This is ANOTHER read-me
worth reading.
The last remaining Falcon4
programmer, in his final hours at MPS, had a little brainstorm. It was simple but powerful. He realized that with all the stability of
F4 these days, it had become a bandwidth-limited game in multiplayer. Everyone on the iBeta testing team shared
his personal goal - to make the game more stable for the single player folks
(he fixed a few more crashlogs in this version) and to be able to get more
players into a stable multiplayer game over the Internet. He knew that anything he fixed here would
easily translate to better LAN play as well.
So he gives us this truly
final version of Falcon 4 as a Christmas present from himself to all of
us. His name is Robin Heydon. Robin also did work on DI’s Apache sim and
Tornado. He is a seasoned veteran of flight sim programming to be sure. Thank you Robin and Merry Christmas to you
as well!
This patch (called 1.08i2)
is a simple executable swap. Simply
place this executable file in your Falcon 4 directory (that would be
c:\Microprose\Falcon4 for most of us).
It can safely and easily coincide with any other executable you may have
in your Falcon4 directory. It WILL NOT
have any adverse effects on any saved campaigns or TE missions you may already
have. So you can safely go back and
forth between the 1.08i and 1.08i2 executables without a problem. But we think you will want to move to
1.08i2. It has only 2 small but
important fixes. And by the way, the 108i and 108i2 executables will not link
in multiplayer. An internal code check prevents this from happening.
#1. Some more causes of crashes to desktop were
fixed. Not the DevCreate crash for D3D
cards however. Please continue to
follow our FAQ at www.ibeta.com for
possible solutions. This particular end
mission crash is associated with the use of GBUs in missions flown on machines
with TNT and other D3D cards and it occurs at the end of a mission when the
player hits escape and end mission. We
are finding work-arounds all the time, and hopefully, we will find a solution
for you. Keep your eye on the FAQ. Till then, read what we have for workarounds
in the FAQ right now.
#2. Multiplayer people. PAY VERY CLOSE
ATTENTION. This next part has proven to
allow up to at least 6 in campaign to fly over the net using modems. We can imagine that dogfight and TE will
hold even more, although we have not yet tested it. And I’ll bet you Dimes to Dollars it will also allow greater
numbers and more stable games on LANs as well.
This new fix puts YOU in almost total control of the bandwidth that
Falcon 4.0 uses and therefore, LAN and Internet squads with a little bit of
savvy and attention to detail, may find this new feature very appealing indeed.
But some explanation is in order first.
So bear with me and let me explain.
When a player went into
Falcon 4.0 to play a multiplayer game in the past (as in version 1.08i), he
could choose his bandwidth usage via the COMMS window. Choices such as 28.8, 33.6 and 56k Single
ISDN were just a few in that long list.
This feature was designed to let you control your OUTBOUND bandwidth
utilization. In other words, you could spill
more or less data per second (bytes per second) out to your Internet or LAN
buddies based on which of these you chose.
And this feature worked, sort of.
Falcon has many data types
that it sends out over the wire in a multiplayer game. And with all that goes on in the very
complex world of Falcon 4.0, these data types are wide and varied. The COMMS setting which you choose in the
comms window of multiplayer F4 limited all the data types EXCEPT FOR ONE -
positional data. Positional data was
designed to pour out more when the plane was doing wild maneuvering and less
when the plane was flying straight and level.
After all, when you are maneuvering, you need more data to spill out so
others can see all the yanking, banking, turning and rolling that you are
doing. The problem is that F4 did not
regulate the rate of POSITIONAL PACKET FREQUENCY very well. The entire missile, threat, campaign, radar
and ground war (etc.) data was very neatly regulated by your COMMS
setting. But the FREQUENCY OF POSITIONAL
DATA of planes and other moving objects were totally dependant on the type of
maneuver that plane was making. We now
have been given the ability to control this as well. And once you do, the
results are impressive. It allows the
other things that Falcon 4.0 needs to do to come alive. The positional data floods that were coming out
of F4 over the modems were essentially over riding the other potential uses for
the limited bandwidth, like ATC replies and bubble management by the host.
So enough about all this -
how do I set up a nice multiplayer game on the Internet with my buddies?
Well. This problem has many possible solutions,
but I will start by explaining one scenario. This is the most complex and
“Bandwidth Hungry” scenario - the campaign.
If you can follow this example and the rules behind it (and you read
this read me in its entirety), then you can experiment with other techniques
for you and your friends to get the most out of Falcon 4.0 online and over
LANs.
The new feature is a command
line called “-pf”. It stands for
“packet frequency” and it requires that you put a number, preceded by a space,
after this command line. This number
represents the milliseconds that will exist between positional packets. So for example: –pf 100 (note the space between the –pf and the 100) means that
outbound positional data will NOT exceed one packet every 100
milliseconds. This means it will be no
more frequent than 10 packets per second.
The net result of using the
packet frequency command line option will only be apparent to your multiplayer
buddies. YOUR in-game visuals will not
be DIRECTLY impacted by the –pf option.
You will see an indirect impact, as bandwidth is freed up for other
non-position duties – ATC, ground objects, and other HOST duties.
So in order to run you game
at a limit of 10 positional-packets per second coming out of your modem, you
must run the game by using your command line as follows:
Please note the space
between –pf and 100. Also, there is a
space after the exe and before the –pf.
Also, a common mistake is to write “-fp”. That is, of course, wrong.
In order to prevent us in iBeta from making that mistake, we simply
recall what –pf stands for. Packet frequency.
In order for players to
launch F4 with this command line in place, there are 2 possible techniques.
1. You can use the “run” command under the start
button. Simply select the start button
on the gray task bar. Then select the
“run” option. Use the “browse” button
to locate and select the “falcon4-108i2.exe” file from the Falcon 4 directory
(where you should have placed it). Then
add to the end of the line the –pf 100 part.
Or if you wish to test what the game looks like with 3 packets per
second, try –pf 333 (333 milliseconds between packets is about 3 packets per
second).
2. Or you can place a shortcut to the 108i2 executable
on your windows desktop. Right click on
the shortcut. Then select the
properties of the shortcut. When the
properties window pops up, select the “shortcut” tab. There you will see the executable name and path in the “target”
line. Simply add the –pf command to the
end of that line so it looks like:
(Or
whatever millisecond spacing you choose to add to your –pf command).
Each player in the game must do this. If one
player uses –pf 100 in a game, and his buddy forgets to do it, the net effect
of this oversight will be that the player who forgot will potentially flood the
other player’s modem with positional data at times. And when this happens, if the other player can handle that rate
of data, it will go unnoticed. But as
we add more and more players to the game, the flooding of data will cause
visible pausing and other ill effects on the game.
One of the side effects of
flooding a game with to many positional packets is that ATC calls and other
vital, non-positional packets can often get suppressed. This gives the appearance of a world with
less things going on. By limiting the
positional packets, other things that make the Falcon 4.0 world such a
compelling multiplayer world can get through.
Also, by limiting the positional packet rates, you can squeeze more
players into the world, because you are limiting the bandwidth it requires to
exist in the world.
Now for a solid
example. And a system for communicating
with others about the –pf command. This
is a terminology that needs to be adopted so that players who know how to use
the –pf command properly can check and confirm settings with each other, their
friends and their squad mates.
The host of the game, the
person who is running the campaign, TE or Dogfight, is always referred to
first. Also, the Host (or M-host for
Mission-host) needs to have the highest bandwidth setting of anyone in the game. On the Internet, however, if he is too hi,
he will flood players. So for Internet play,
we recommend that the host set his comms up for 33.6.
Now the guests, who do not
need to have such a high setting, can set their comms up at 14.4.
The best-tested numbers thus
far for campaign over the Internet (which is the most bandwidth intensive
module of all the multiplayer modules in Falcon 4.0) are as follows:
- The HOST selects 33.6 and also uses –pf 100
- The GUESTs all select 14.4 and also use –pf 100
So in order to communicate
this in chat, we like to say 336-100/144-100
This nomenclature is short
and to the point. The host, his comms
and his –pf setting are mentioned first.
The guests and their comms setting and –pf setting are mentioned last.
NOW LET ME BE CLEAR. This is what
some very hardworking guys on iBeta have born out to be an effective
combination. But other combinations may
very well be better. It totally depends
on how many players you want to have in the game and how much bandwidth the
SLOWEST player in that game has. You
are always accommodating the slowest player.
So if you have 5 cable modem players, but one 56k modem player, then
these settings in the example may be the exactly right ones for you.
If you have all 6 players on
cable modems, you may find higher settings in such a game will look and feel
even better. Although I have not yet
tried it, I would think that a 6-player cable-modem game (lots of bandwidth to
go around) might be able to use the following settings.
56k single ISDN-75/336-75
Or maybe even
112kdual idsn-50/336 –50
I'm just guessing. But I do want to tell you about a very
important pattern that you may have picked up from my examples thus far. I call them (shamelessly) Sleepdoc’s Rules of Bandwidth Management. And they are only 4 rules.
#1. Never send more data than absolutely
necessary to the host. In iBeta, we
called this the “Don’t slam the host”
rule. You can see this in my examples,
as you will always notice that the comms settings for guests are always one or
2 notches BELOW the comms settings for the host. This is because the host has many more game and bandwidth
responsibilities than any single guest.
So if he is flooded by tons of data from guests, then the host gets
bogged down.
#2. Always make sure the host has a setting in
COMMs commensurate with his available outbound bandwidth. In other words, don’t ask the host to send
out data at T1 or better rates if he is connected to the Internet by a 56k
modem. 33.6 is the highest Host setting
that should be allowed by a 56k modem user.
Obviously, faster modems can set faster. How much faster? It's
trial and error time.
#3. The slowest modem in the game must always be
accommodated. In other words, no matter
how many fancy cable modems and DSL connections you have in your game, if even
one single player is on a simple 56k modem, then you MUST respect his limited
inbound bandwidth. So if you want him
and all the players to have a nice, stutter free, flood free game, everyone
must respect his BW. If it were a 6-player campaign, I would recommend trying
336-100/144-100 for starters. If it is
a 4-player game, I would think those settings would be rock solid as well.
#4. It appears that after about 2 hours, the
game (multiplayer) will start pausing and stuttering. Memory leak? Maybe. But whatever it is, the host starts to fail
at transmitting ATC and other vital data and the game begins to stutter and
deteriorate. So we recommend that after
1 or 2 multiplayer missions in a row, that the host do a “save”, and then
everyone drop out of F4. Probably a
clean reboot is in order here as well.
Then start over again. 2
missions in a row is the maximum I would play before resetting in this fashion.
Because once the multiplayer stuttering sets in (about 2 hours into play) it
will not cure itself without this resetting.
Now when players play TE and
Dogfight, they need less bandwidth for all the complex background events that
are dominant in the campaign world. So
you may be able to get away with greater packet frequencies. I would love to hear back from the
Dogfighting crowd if they can get 10 players into dogfight using the settings
like:
336-100/144-100
Or maybe 28.8-75/144-75
I think it is very much
within the realm of possibility now.
The gestalt of all this is
that we encourage experimentation of settings.
You are now in control of bandwidth.
In fact, it may very well be that settings like 336-200/144-250 really
reduce the bandwidth in games and really allow the ATC and other host
responsibilities to shine. But of
course, the higher –pf numbers mean lower positional packet rates. So in
campaign, lower packets rates (higher –pf numbers) might lead to unacceptable
warping. This might occur because of the tons of aircraft in the air. More aircraft require lower –pf values. We just
don’t know. We haven’t tested all the
possible combinations. However, in TE, the higher –pf values may be quite
acceptable due to the lower numbers of aircraft. And by using higher –pf values
in TE, you have effectively reduced your bandwidth utilization. This will permit greater numbers of players
to enter the game. But in order to
insure that the guys you are experimenting with are on the same page as you, we
have devised the way of communicating the settings. We highly advise you use it.
This read me sets the standard means of communicating this data with our
nomenclature.
Host comms setting-host pf
value/guest comms setting-guest pf value.
We look forward to hearing
back from people about their successful combinations.
Also, for the LAN
people. I would recommend you stick to
the rules as well. But since you don’t
have a slow player in the bunch (rule #3) consider settings such as:
256k DSL-100/336-100 or 256k
dsl-50/336-50
or maybe even T1-50/112 dual
isdn-50
Who knows?
Now this section is called
Dewdog’s and Speeds performance tips.
These two iBeta testers
(DewDog and Speed) learned a few more things you can do to get the most frame
rate and performance out of online 108i2 F4. I imagine that this test helps
single player play as well. I have tested
them personally, and they work like a charm.
First, you go to your
falcon4.aii file, which you will find in your
C:\Microprose\falcon4\campaign\save directory.
Open this file with notepad. You
will find many interesting variables that can be set in there. We do not know what many of them are;
however the second to last one at the end of the list is called simbubbledata (or some such
thing). You will notice that it is set
to 300000. If you change this value to
150000 you will notice a pretty reasonable increase in performance and frame
rate. What you lose is the ability to
see planes on radar past 40 miles out.
What you gain is frame rate and performance. For my personal play style, this trade of is a no brainer. I liked it, so I stick with it.
Finally, the last
performance/play enhancer is the use of labels. We highly recommend that if you do use labels, that you keep near
labels and leave far labels off. Far
labels only confuse things, and near labels let’s you see you secondary cursor
bubble in action. If you don’t know
what this is, then go read about the secondary cursor bubble at www.ibeta.com in our FAQ about falcon 4.0. Understanding this concept can add a lot of
enjoyment to your multiplayer flights.
But remember the rule. Keep near
labels on and far labels off to really get a great feel for what is going on in
your game. Far labels create
confusion. Near labels generate clarity
and SA.
Enjoy! Merry Christmas and Happy Hanukah. Let the experimentation and multiplayer
cheer begin!!!
Please email me at Sleepdoc@ibeta.com and tell me what combinations
and numbers of players worked for you.
Thanks to all the
F4 iBeta Public Sector testers, without which this would not have been
possible!!
First Name |
Last Name
|
Callsign |
Joe |
Abramo |
SurfDog |
Robert |
Adams |
Voodoo |
Charles |
Allen |
Coolie |
Merle |
Antrim |
VFA69_Painter |
Joel |
Arrington |
Eviper |
Peter |
Austen |
Screw |
Jan |
Backlund |
Bajur |
Peter |
Baker |
Nzfalcon |
Jeff |
Barco |
Buzz |
Paul |
Bartelt |
LEO |
Peter |
Barton |
Faust |
Patrice |
Basquin |
Skypat |
Robert |
Borjesson |
TrakDah |
CHAD |
BORSHEIM |
CAT |
Kevin |
Brown |
Darkstar |
Herbert |
Brunner |
"Stormin"_VFC-13 |
Mark |
Bush |
Frugal |
Larry |
Busher |
Ripper |
David |
Carmeli |
Somo |
Michael |
Cavaluzzi |
MadDog |
Claude |
Cavanaugh |
Shadow |
Lloyd |
Cole |
HUNTER |
Nestor |
Colon |
Red-10 |
Rick |
Conkling |
Iceman |
Don |
Corbin |
Rapier |
Ric |
Couchman |
Harpy |
Ryan |
Cowley |
Kosmo |
Kenneth |
Crawford |
SideKick |
Marco |
Drioel |
Driekey |
Peter |
Eggen |
Gunhawk |
Tomas |
Eilsoe |
RIK |
B |
Elias |
Hammer-Time |
Jeff |
Euclide |
Terminator |
Troy |
Felix |
Mongoose |
Shane |
Felts |
Cat |
Joseph |
Fitzpatrick |
Scorpion |
Costas |
Gardias |
SHARK |
James |
Gerlach |
Kamikaze |
Bernie |
Godfrey |
Norad |
Jason |
Graefling |
Graf |
John |
Gray |
AVENGER |
Jonathan |
Green |
Bubba |
Burl |
Gregory |
Rama |
Roel |
Groot |
A^LiFe |
Craig |
Hagen |
NightLight |
Dave |
Hamilton |
Ham |
David |
Hankins |
AltFire |
Dr. Nicholas |
Hastings |
Mako |
Terry |
Hayward |
Turn'N'Burn |
Stuart |
Hetrick |
Headache |
David |
Hiebert |
Crankshaft |
David |
Higgins |
Tiger |
Kevin |
Hill |
Crash |
John |
Hirst |
Cleanur |
Andrew |
Hody |
Blocker |
Jimmy |
Holdaway |
cattleprod |
Eddie |
Hönig |
Hot Shot |
Guillaume |
Houdayer |
ghostrider29 |
Rob |
Hughes |
Narphous |
Jon |
Jessop |
Relic |
Börje |
Johansson |
Speed |
Tom |
Jordan |
JordanAir |
Vangelis |
Kazalis |
H-Thunder |
Rick |
Keller |
Talon |
Michael |
Kent |
Superman |
Tom |
Launder |
Saint |
Steve |
Lewis |
Wizard |
Rodrigo |
Lourenço |
Motor |
J. |
Luckie |
Cyanide |
David |
Macherey |
Mad Mac |
Rene |
Madsen |
Trapper |
Sascha |
Mangs |
Conan |
James |
Martin |
Razer |
Timothy |
McCall |
Tango |
Thomas |
McCauley |
TOMBOMB |
Kevin |
McLean |
BEAR 257th |
Roger |
Moeller |
FAULKEN |
Charles |
Monson |
I Inhaled |
Roger |
Morris |
Simian |
Larry |
Nissen |
Machinegun |
Paul |
North |
Topboy |
Anders |
Olandersson |
Swebeast |
Zac |
Olsen |
Vapor Trail |
Vernon |
Pellerin |
Seducer |
Gary |
Perry |
Ranger416th |
Aaron |
Pitts |
BitViper |
Bruce |
Ponder |
Eagle |
Bertrand |
PUECH |
Gazzz |
Brad |
Raulston |
The_GhostRider |
James "Dusty" |
Rhodes |
Redwolf |
JR |
Richards |
Steelcity |
Robert |
Roberge |
Ghostrider |
Bevan |
Roberts |
Coreviper |
Paul |
Robertshaw |
Wizard |
Leonardo |
Rogic |
Apollo11 |
John |
Sargent |
Makani |
Chris |
Schroeder |
Hawk |
Randall |
Sechler |
Mouse |
Kevin |
Shaw |
Lawndart |
Larry |
Siddens |
WrongWay |
James |
Simms Jr. |
Jahap |
John |
Simon |
NavlAV8r |
Alan |
Simpkins |
Doc |
Mike |
Snyder |
Buteo |
Leonard |
Stables |
StaMan |
LCDR. Robert |
Stanley |
Navy1 |
Scott |
Stephens |
Fanatik |
Arjen |
Stobbe |
Wolf |
Daniel |
Sullivan |
Ripper33 |
John |
Tasker |
=Jagr= |
Sim |
Taylor |
Gunner |
Geoffrey |
Trexler |
SkyNet |
Tom |
Velez |
Airdog |
Edwin |
Versijp |
RazorBlade |
Martin |
Vinther |
MAV |
Tony |
Vulpitta |
Racer x |
David |
Wagner |
DewDog |
Tony |
Walker |
Tone |
Charles |
Weems |
DirtDobber |
Daniel |
Wilson |
MakoByte |
Wilbur |
Winslow Jr. |
Spaceman |
Steve |
Wise |
Wiseman |
Leigh |
Woolley |
Anytime |
Eric |
Yale |
AlphaWizard |
Lawrence |
Young |
Foxbat |
Victor |
Zaveduk |
Duke |