Falcon 4 iBeta patch 1.08i2 – README                                                           12/24/1999

 

-------------

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.

-------------

 

Patch Installation Instructions

 

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:

 

Falcon4-108i2.exe –pf 100

 

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:

 

C:\Microprose\falcon4\falcon4_108i2.exe –pf 100

 

(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