eFalcon

De laatste stand van zaken

02-12:

Laatste bericht

Aan alles komt een einde. Ook aan de voortreffelijke eFalcon updates.
Maar ben gerust, want eFalcon zal voortbestaan in de SuperPAK versies.
Hallelluja, Amen.

Deze pagina zal dan ook stoppen met het vermelden van het laatste nieuws.
Hot op dot moment isde SuperPAK.
En alles hierover is te lezen op de F4UT site van Brownsnake. Als er wat te melden is, lees je het in de nieuws sectie.

Voorspoedige vlucht, Ice.

07-08:

1.10 released

eFalcon is vanacht om 01:00 uitgekomen.
Op de officiele eFalcon site had men het volgende te zeggen:

1.10 Released!

August 6, 2001

The eTeam proudly presents eFalcon 1.10.

This download is probably rather unique in the computer gaming business. This would never have been possible if it wasn't for great guys spending most of their spare time to refine this simulation software for you to enjoy. And entierly free of charge.

Send them a note of appreciation (through me) if you want to. They deserve it!

This version is the last in the eFalcon series. eFalcon 1.11 will probably be called Falcon V. ;)

What files should you download?

- eFalcon 1.10 Installer - One-click-Installer to go from 1.08 US to eFalcon 1.10 (For the basic installation, you don't need anything else)
-F4Patch 4.1 Standard and eFalcon 1.10 EXE - If you want to tweak your setup, install F4Patch 4.1 Standard onto a 1.08US and add the eFalcon.exe, then start patching (This allows maximum modularity, like adding of F4Patch Cockpits, Skins, Sounds and Standalone-Patches)
- eFalcon 1.10 Config Editor - Optional, can be used with both of the above installation methods. Allows easy configuration of eFalcon instead of Notepad-editing.

Download eFalcon 1.10 in the eFalcon downloads section, and don't forget to read the F.A.Q.

If the download is slow, please try our mirrors:

Frugal's World
Sim News
DogFighter
Check Six
Falcon 40
F4Community
F4Freeware

On behalf of the eTeam, the authors of this incredible program, the eFalcon beta testers, and the entire Falcon community that has been waiting for this incredible release of the new Falcon, thank you for supporting this great hobby and everyone's tireless work.

/eTeam

====================

1.10 Announcment

August 6, 2001

Falcon Pilots,
The eTeam is pleased to announce the release of the final version
V1.10 of the eFalcon series for Microprose's Falcon 4.0. Hundreds of
hours of dedicated work have been put into this release, a number of
innovations such as enhancements to the AI, superior avionics,
improved HUD symbology, new wingman commands, more realistic damage
simulation, support of aircraft carrier takeoff and landings,
superior multiplayer stability, a photo-realistic cockpit, better
support for new theaters, enhanced weather simulation and 3D sound
support makes you feel even more like sitting in a real cockpit of a
F-16 Fighting Falcon.

eFalcon v1.10 comes together with the known single-click installer
method which does all the required operations for installation and
lets you jump right into the cockpit of a new Falcon 4.0.

It is fully compatible with F4Patch V4.1 you will find released at
the same time as eFalcon v1.10.

The eFalcon v1.10 release will be available at most of your favorite
flight simulation web sites by 24:00 GMT tonight.

http://eteam.frugalsworld.com
http://www.frugalsworld.com
http://www.dogfighter.com
http://www.falcon40.com
http://www.f4community.com
http://www.f4freeware.com
http://www.checksix-fr.com

The eFalcon Team

Voor het ophalen van de patches op een Nederlandse server ga je naar de download sectie toe.

30-07:

1.10 nieuws

Op eFalcon heeft Brownsnake een verslag geschreven betreffende de vernieuwingen die het "Electronic Warefare System" krijgt/heeft in 1.10.
Het verslag.

15-06:

eFalcon start-up 1.10 sequence.

Ik was hem helemaal vergeten.
Jagstag heeft en nieuwe start-up sequence in Flash gemaakt voor de eFalcon v2 pit die in eFalcon1.10 zal zitten. Sorry

Hier is hij:
jagstags_110_rampguide.zip (1515kB)

10-06:

1.10 is hot

Wat 1.10 specificaties die er zeker niet om liegen.

http://www.sim-news.com/features/2001/weapons_shop_0506/index.shtml

09-06:

eFalcon cockpit v 2.0

Naast dat deze maand de eFalcon v1.10 uit zal komen, komt eFalcon ook met de vernieuwde versie van hun cockpit. Versie 2.0 is hopenlijk klaar voor de 18^e van deze maand. Men zal er in iedergeval alles aan doen om de pit klaar te krijgen.
Vandaar dat Jagstag ook mee werkt aan het project. Naast de screenshot van de pit die hij had, zijn er vandaag nog 3 vrijgegeven.

Brownsnake EWS verslag  30-07-"01
Brownsnake Multiplayer Code update  07-05-'01
Frugals Report  13-04-'00
Multiplayer verslag  11-04-'01
Multiplayer Code update  08-04-'01

eFalcon is naast de patches van de Realism Group, de manier om meer uit je Falcon game te halen. eRazor, de code schrijver en de rest van zijn team, hebben het voornemen om Falcon vanaf de code die gebruikt werd in de 107 update, te herschrijven en nieuwe code toevoegen, om zo een beter Falcon 4 te creëren.

eFalcon maakt voor de 1.09 ook een nieuwe cockpit.
Wat screenshots:

top

EWS (Electronic Warefare Systems). 30-07-2001

Een verslag van Brownsnake.

OK, it's time for some real 1.10 information. This time I will try to cover some of the new features of the EWS (Electronic Warfare System) in eFalcon 1.10. Most of this is from the 1.10 manual.

What's the EWS?
The EWS is working together with the RWR to automatically release countermeasures upon spike detection on the RWR. It is also possible to release pre-programmed sequences of Chaffs/Flares and have the Jammer turned on automatically.

The EWS panel is located just below the landing gear lever on the left side of your cockpit. (see this picture)

Modes
The EWS has five main modes:

OFF - The system is shut off. No Chaffs or Flares can be released.
STBY - This mode must be selected to re-program any of the default programs through the ICP.
MAN - Used to manually launch the selected Chaff/Flare sequence.
SEMI - When a radar spike is detected by the RWR, Betty calls out "Jammer" to ask you if you want to turn the Jammer on (only if the REQJMR Option in the ICP is set to ON). If so, turn it on manually. When a missile launch is detected by the RWR, Chaff/Flares are automatically released according to the currently selected program on the PRGM switch.
AUTO - When a radar spike is detected by the RWR, the Jammer is turned on automatically (only if the REQJMR Option in the ICP is set to ON). When a missile launch is detected by the RWR, Chaff/Flares are released automatically according to the currently selected PRGM.

PRGM
The program selector controls which one of four pre-programmed counter-measure programs will be used in SEMI and AUTO mode. The pilot can choose between 4 different programs, each optimized for a certain task. By default, the 4 programs are defined as follows:

Program 1: High-Med Alt SAM Evasion
This program is optimized to deal with RDR launches from SAMS and SARH missiles. The 3 Chaff drop every 2 seconds gives the pilot a maneuver time between salvos to jink and change heading.

Chaff BQ:3 Flare BQ:0

BI:0.5 BI:0

SQ:3 SQ:0

SI:2 SI:0

Program 2: Merge program, Enemy with IR missiles
This is optimized to deal with the Archer-HMS combo. At the first turn, the Pilot dispenses this program (6 flares in 6 seconds per press, as suggested in the RP4 manual)

Chaff BQ:1 Flare BQ:3

BI:0.5 BI:0.25

SQ:3 SQ:2

SI:3 SI:3

Program 3: Popup AG sequence, Chaff only
To confuse enemy radar, as the ingressing fighter begins his pull-up into the SAM envelopes this program dumps 8 bundles of chaff.

Chaff BQ:2 Flare BQ:0

BI:0.5 BI:0

SQ:4 SQ:0

SI:3 SI:0

Program 4: Popup AG sequence, Chaff-Flare
With the possibility of SA7 or SA8 over the target area, this sequence adds in the protective measure of 6 flares.

Chaff BQ:2 Flare BQ:2

BI:0.5 BI:0.5

SQ:4 SQ:3

SI:3 SI:3

The EWS system is closely related to the ICP. The pilot can change each program as he likes it to be. To do so, he accesses the "LIST" page and switches to the EWS selection. Dobbering right will call the Chaff and Flare program pages. There the pilot can change the various values.

Details on EWS programming is in the 1.10 manual.

More to come...

/BrownSnake

top

Multiplayer codes, een update. 07-05-2001

Een verslag van Brownsnake.

A few months back I posted an article by mirv on how the network code in Falcon 4.0 works in 108i2 and how eTeam would like it to work in the future. (If you missed it, read it here) The code was supposed to make it into 1.09, but there were too many issues at the time of release, so it was postponed.

It's been a bit quiet since and as one of the most frequent questions I get is about the new Multiplayer code, I thought I'd provide a report on the progress...

Ok, according to the info I got the code is working as advertised in the article mentioned above, with all the pros and cons mentioned there. The code is stable and performing well, and most of the CTDs are eliminated.

Most of the testing have been made with only three people, but recently larger scale testing have been made. 4, 5, 6 and 7 player missions have been flown without problems. Not a single CTD and performance is great. And yesterday a 10(!) player TE took place. Despite a few minor glitches, things worked fine. No warp or lag whatsoever. It's looking really promising...

The reason this has taken a bit longer than planned, is the problems of testing and debugging over long geographical distances. But the team seems to be on top of it now.

A few issues remain but according to the lead tester, things are looking great!

More info as soon as I get my hands on it.

/BrownSnake

top

Multiplayer verslag van 69th Werewolfs 11-04-'01

Een verslag van Nighthawk.

On 11 April 2001 the 69th VFS Werewolves online squadron tested out a new build of eFalcon 1.09, as we have been testing 1.09 for some time now. I am happy to report that our results were amazing, so let me explain.

The mission was a fairly simple Tactical Engagement mission which contained a package of two flights: a SEAD Escort and an OCA Strike. The SEAD Escort was tasked with providing air support and ground threat suppression during the mission – they were faced with a pair of SAM sites and AAA at the primary target site. The OCA Strike was tasked to hit a single runway at a DPRK airbase. The SEAD was composed of two human pilots and the OCA contained three plus one AI pilot.

After coordinating on our Roger Wilco server, we all jumped into the lobby at a 33.6 connection for the clients and a Cable connection for the host where we waited until the mission was setup. At this point, we entered one-by-one into the mission and awaited the remaining pilots to join. After all pilots had called “in,” we did a quick run-down of the mission and proceeded to commit. We bypassed our normally lengthy brief this time in order to get in the air quickly and since it is possible that waiting in the lobby/mission briefing screen can cause problems.

Once both flights were on the tarmac, we ran through standard taxiway/takeoff procedures of the 69^th VFS. Once we were airborne and formed up it was time to do a short brief for each flight including contracts, planning, and weapons parameters. From here the SEAD Escort proceeded to destroy two radars at the two DPRK SAM sites, which allowed the Deep Strike to execute their attack profile without disruption.

Throughout the entire flight there was no lag at all! This was with five pilots running eFalcon 1.09 (and two running eFalcon 1.0799). From past rigorous multiplayer testing all the way back through 1.07, we have all agreed that this flight definitely went smoother than any previous Tactical Engagement with five pilots than any of us had flown! We also proceeded to have the host exit BEFORE the other pilots to see if a crash-to-desktop occurred as it had before almost every time -- nope! Absolute perfection! Another crash-to-desktop that was experienced frequently in previous versions of Falcon 4 was when people would enter and exit the lobby while others were in flight – this is also completely gone!

In this report I have only focused on a five-player Tactical Engagement mission in 1.09, yet we have had excellent experiences in campaigns with two human pilots (that is the most we’ve tried so far) as well as with two in Tactical Engagements. The 69th VFS and myself believe that it is safe to say that you will be surprised at the awesome stability that 1.09 has to offer in single player and multiplayer sessions.

top

Multiplayer Code 08-04-'01

Een verslag van Mirv.

Since build n108, the multiplay code was updated to try host/client code. This means that multiplayer will be much more stable and much smoother with many players.

The host is the computer that starts the game! (Enters the TE/CAMP/DF first, not the one who sets 0.0.0.0 in the IP.)

The host needs bandwidth!!
The higher the host bandwidth, the more smooth it will be and the more players will be possible. As a general rule, one client uses 33.6 baud so if there's 4 players (3 clients) the host needs to be able to produce 33.6 * 3 = 100.8 baud.

If a host with enough bandwidth is not available, you can still fly but the position update rate will suffer.

How did the original code work?

The old code was not really built for low bandwidth internet gaming, but meant more for LAN play. The big difference between LAN and for instance a modem connection to the internet is the amount of data that you can transfer per second obviously. On a 33.6 baud modem connection you can transfer a maximum of 40 position updates per second. In a LAN connection, F4 would send over 1000 updates per second.

In the old code the host's job was to check all the vehicles in the sim for movement and send updates to the clients about the most important changes in the F4 world.

The host realized that it didn't have the bandwidth to send all the necessary updates to keep the world absolutely true, so it picked the most important ones.

What it failed to realize though (in the old code), was that not all objects are as important to all players. For instance, one player who's dogfighting with an Su-27 would need a lot of updates on that object, but another player 200nm away from that fight would not really care about it, so he would just need a few updates on that Su-27 object.

The old code also didn't realize that if someone was close to an object, everyone would get lots of updates on that object.

The result was that some players were bombarded with position updates on objects which were hundred of miles away while only a few getting a few on the Mig-29 10nm ahead of them. This results in what we all know as warps.

The new code realizes that not all objects are as important for all players and will send specific updates to specific players about the objects which are of importance to them. It will not waste bandwidth on updates on objects which are of no importance (as the old code did). This will reduce the lag very much especially when more players are in the game.

In the old code the host would not take care of sending position updates on the other players in the sim. They would have to take care of this themselves. This meant that if we, for instance, have a game with 6 players, one client would have to send updates about his own position to all the other 5 players in the sim. Let's see how much bandwidth he would use just for sending:

With pf 100 you would send an update 10 times a sec. 5 players * 10 = 50 updates per sec! Well, with a 33.6 conection you only have 40 available. So trying to send 50 would make you CTD and/or definitely not give you much bandwidth to receive updates from the host and other players. As the example illustrates, this method eat up a lot of bandwidth and basicly a modem guy would use all his bandwidth just to send his updates to the others and would have no bandwidth left to receive.

What does the new code do?
In the new code, a client only sends to the host and therefore does not care how many players that are conected to the game. It also doesn't waste valuable bandwidth which could have been used for receiving updates.

Works as a true host/client making huge sessions possible with many players online even with low bandwidth connections.

The new code also makes sure that noone is flooded with position updates. This means that you do not have to set your bandwidth to 33.6 if your real bandwidth is higher. It will greatly increase stability and reduce CTDs. The host with a high bandwidth connection will be able to provide games with very little lag to many players.

Code that picks the most interesting objects and differentiates between which objects are interesting to which players.

The new code will adjust the position update tolerance continuously and adjusts according to the action in the game.

So is this all good?
No, not quite. Since position updates now have to travel through the host and not directly from client to client the data will have a further distance to travel (unless the routing is better THRU the host - it kind of varies on routing). This means that it will possibly be delayed a little more than with the other system. F4 does not take latency into account (yet) so this might be noticeable. (This is why other players look like they are a little behind when compared to where they are on their own screen.)

The code is still under developement and currently it will assume that all clients are connected with a 33.6 bandwidth conection, so you will not get more updates even though you have more bandwith available for real. This is only true for the clients! The host will use all the bandwidth he's got available.

In future updates, the host will constantly check how the network conditions are and will adjust the throughput accordingly.

/Mirv

top