killswitch

Actually, that problem most likely comes from the ofp server needing some older system libraries. The solution to that is described very well in benu's first post. You need to get the libraries, unpack them and edit the ofp start script, "ofpserver", as shown in the first post. Editing of the server config file is a later stage.

but like most things in life it isnt that simple as it doesnt seem to work... anyone able to tell me how to prevent a script executing in multiplayer? Korax and Terpentin each presented the correct solutions. Here's a variation: the pseudo-code <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? (mpgame): exitcorresponds to <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> @(time>1) ?{playersNumber _x>0}count[east,west,resistance,civilian]>0:exitin actual OFP code. The initial wait is there to have OFP be properly initialised on mission start. Wether or not the 1 second delay is enough has to be determined through testing.

The error messages tell us that you need two things: <ul>[*] The uudecode program, most often delivered in a package called "sharutils" [*] The GCC compiler package Tell me/us what Linux distribution you are using and someone might be able to tell you more in detail what you need to do.

The OFP Linux server works fine on a 64-bit system. What you need is a few older system libraries and some startup script "tricks" in order to have the OFP server use these instead of the default system ones (which are "too new", likely due to either 1) library ABI breakage or 2) bad assumptions made w/regards to system libraries during the ofp server compilation/build process 3) a bit of both) Forum member benu has summarised all this in a very nice thread which shows you exactly how to do it: Linux server setup howto Now, if we could only get the latest 1.96c server recompiled for more modern Linux systems...

Agree - having a new per-entity event (I'd call it "join" or possibly "joined", keeping with the current event type naming convention) would complement the per-mission onPlayerJoin.{sqs|sqf} system nicely and I can see uses for both. For comparison, consider how OFP allows you to use a (per-mission) onFlare.sqs script that detects flares being fired in a mission. This complements the (per-entity) "fired" event quite nicely. I will second the suggestion of being able to add playable units during a mission. (Say, by way of extending the createUnit command). That'd be just great. "Sir, we need reinforcements" "Ok, coming up" <Mission/side CO opens a dialog and adds a couple of squads, each led by a playable unit> Food for thought: currently, OFP uses certain markers (eg "respawn_east") to decide where people respawn. Imagine the optional "reinforce_west<number>" markers to designate the places where you may enter the game world after the mission has started. Oh man, the possibilities...

Phoenix Island might be acceptable to you - it's a well-made island and has a lake or two in the north east.

A normal BIS soldier (or vehicle) is needed in the misson to initialise ECP. Try this: start your mission editing by placing a civilian man somewhere. If you don't want a civvie, use any other standard BIS soldier somewhere. Just make sure he or she is placed first in the mission. Then move onto placing whatever GMER and other units you want and try playing. ECP effects should now be active on the rebels too.

So, while we dream of 102x102 km islands, let's talk about the 51 km ones. Are there any out there that aren't just scratch islands made for fun? (EDIT: I'm aware of the "PMC Euro" island.) Heck, we need more 25x25 islands too and not just ones with a small island in the middle (like Tonal...which is waaaay too small ) Yeah...larger islands and bridges the AI:s can actually drive across with more success. The Nogova bridge is a good example of how NOT EVER to model a bridge...(think: AI:s love lamp posts)

This expression will return the total number of magazines (including hand grenades and AT rounds) a soldier is carrying:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">count (magazines _unit) This is more difficult, since you need to know what muzzle the soldier is "using" at a given time. With stock BIS weapons though, the following expressions will work for normal rifle magazines, ie not grenade launchers nor rifle mortars:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_unit ammo (primaryWeapon _unit) Note that what I've given you are just expressions that return a number, not specific usage examples. If you don't understand the difference, it's time to find some basic scripting tutorials.

Reading material: Bedtime reading. Browse around. Also, grab "OFP Tools 1.0 (Linux)" from CR-OFP Enjoy!

By following up those errors, you would have found a lot of the issues that people are now reporting. For example, take the botched gunner proxies of many of the models. The output from binarize point you to those. While fixing them, you would probably also have noticed that the mounted machine guns were missing from many of the View Gunner LODs. Don't give up when binarize gives you errors - analyze the error messages and fix them instead.

There's a UAV among the Operation Frenchpoint addons, too.

There's a UAV among the Operation Frenchpoint addons, too.

Correct. To rephrase something that's been said in this thread over and over again: the killed event is only generated on the machine where the killed entity (vehicle/unit) is local. The killed event is not broadcast to any other machines. Therefore, the client will not recieve the killed event for the example situation you presented. Does this mean if server creates vehicle, publicvar the vehicle to the clients. And only one client adds a "getin" event....then I would assume just the client that added the event in the first place will see the getin event, RIGHT? Yes. Note however, that all machines will actually be informed of the "getin" event, but it's just one machine that has a handler attached to the vehicle in question. Yes.

Of course. I took that into account. Mission #9 started with five team members. Later, one of them babysits the rebel leader back and I'm left with four team members (including me) Enter mission #10 and I find myself and two other guys. #4 was...lost.

I've played this campaign through and I thorougly enjoyed it. I can only echo what others have said - this is a fine piece of work. The storytelling during the campaign using cutscenes is...just plain sweet. To KN and everyone involved: thanks for making this! The quirks I encountered were just small ones, but I'll list them here if you want to revisit it and/or polish it. * Some missions will give you an error dialog "Cannot load mission, missing addon <something>". Some cutscenes failed for the same reason. This occured for <ul>[*] "Rebel Tide" (Revolt05M) since it needs to have "jam_magazines" and "bn_tracers123" added to the mission.sqm's "addons[]" part. [*] "<Lorengau Traegdy>" (Revolt08CS) needs "bn_tracers123" listed. * The radio message recordings were almost impossible to decipher, since you seem to have added "radio static" to the samples beforehand. IIRC, OFP adds it's own static, rendering the radio comms to come out "doubly garbled". It's probably better to have the recordings in the clear and let OFP add the scratchy radio static to them by itself. * There seemed to be some trouble keeping track of the number of surviving team members from "Cutting the lead" (Revolt09M) and I ended up with one member less than I should have when starting "Restoration" (Revolt10M). Trouble with OFP's "saveVar" and "saveStatus", perhaps? Those issues aside, though, it's still one of if not the most well-made user campaign for OFP. Rock, rock on!

Make that JAM3 and I'm all for it

It is a bug indeed. The addon's config doesn't properly declare the dependencies it has on other addons. In short: The three KEGSW** addons are broken, like so many other addons out there... The solution? Use these: Kegetys S&W revolver pack, fixed. Replace any and all copies of the broken (ie old) ones with these. That goes for the server as well as any clients. Problem solved.

Yeah, that helps... I just loaded a correctly installed JAM3 and tried the supplied demo mission. It loads and plays fine. Make sure you don't have any old JAM2 addons left - replace them all with the JAM3 ones.

See my reply (third post) in this thread: ECP 1.085 and CoC CE2 missions

The ECP readme you have is fine. There's even an example of how to extend a fired event handler to call ECP and custom code. Study that and you'll figure it out.

Yes. If you open the text file @ECP\ECP_Settings.sqs and browse around, you'll soon find this part: What does that tell us? It shows that the infoshare setting is determined by the boolean variable in index 37 of ECP_public. The solution therefore becomes "determine if ECP 1.085+ is present and make sure ECP_AI_infoshare_enable is set to false. In short, add this to the mission's init.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?format["%1",ECP_Path]!=format["%1",nil]&&format["%1",count ECP_public]!="scalar":ECP_public set[37,false]

That error message stems from the island maker having used an older version of AGS Harbour kit than the current 1.3 version. Nothing else. There once was a "ags_portupd.pbo" addon, but the contents of that are nowadays covered by the "ags_port.pbo" of said 1.3 version of the harbour kit. The island, however, references a model in that old, obsolete addon. The island maker therefore needs to 1) Get rid of any and all copies of "ags_portupd.pbo" 2) Make sure he has the latest AGS Harbour kit (ie version 1.3) 3) Update his island, since it still tries to load a 3d model from ags_portupd.pbo, which, again, is obsolete. (Use ags_port\skc_crate.p3d instead)

1 - Everything. 2 - ECP_addUnitsArray actualy works in v1.085. ECP_EH_handler_init is rather useless on mission start - it stands there in case an unit is created during a mission. Ah. Thanks for clearing that up. Yeah, it struck me when I saw it - "Oooh, that'd be just so neat and magical and...well, working" This is me, in the post above: so, yes :-)

More guidance can be found in the ECP readme. If the "british APC" is the PUKF Warrior, you don't have to do anything - it is ECP compatible already. Actually, it should be less tricky, since they have at least made some kind of attempt at making the addons ECP compatible. One might say that half of the job is done alredy. That's CfgVehicles (english). Make sure you don't misspell or change that, since OFP will then not accept the addon. If that's how your CBT Humvee config looks, you have some odd, wrong or old version of it. Go to Combat! and get the HMMWV pack version <span style='color:green'>1.1</span>. In it, you will find this: Change that to Make sure the init=... is just one line. The forum might show it as two or more lines, but it's just one.Technically, with ECP 1.085, one could/should use (init=... is just one line here too, as always)Furthermore, it seems the online version of the ECP readme was recently (04/08/05) edited to say that the init event handler needs to have all of this added to it: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if(format[{%1},ECP_path]=={scalar bool array string 0xfcffffef})then{ _0={ECP_INIT}createVehicle [0,0,0]};if (format[{%1},count ECP_addUnitsArray]=={scalar})then{ECP_addUnitsArray=[]};ECP_addUnitsArray=ECP_addUnitsArray+[_this select 0];_this call (ECP_resources select 40);which is a bit odd, since the ECP_INIT vehicle doesn't exist, at least not in 1.085... <span style='color:red'>To the ECP team:</span> 1 - Is the ECP_addUnitsArray to be used for vehicles too or is that just for humanoids? 2 - In previous versions of ECP, I found the use of both ECP_addUnitsArray and calling the ECP init EH to be redundant. 3 - Also, where does the "ECP_INIT" vehicle come from. I'm unable to find where it's defined. I hope some of all this helps. Good luck!