killswitch

If you are referring to the "Tonal-Tango Pack Patch 1", as posted by Nagual on page 46? (Filename "BAS_TonalTango_Patch1.rar"), then no, it hasn't been fixed. Again, the particular problem is with in the config.cpp of the bas_opcpp.pbo. The exact "solution" to that bug is in my posting waay back in this thread (page 28), so it should be an easy fix. The symptoms of that problem are, for example, "missing addons..." messages, linux servers "not working" and mysterious addons automatically adding themselves to missions that don't even use them. Old problem, solution available since 1.85. Properly specifying requiredAddons is paramount. (Also it eliminates a lot of user error reports.) NB: A lot of addon makers seem to trip on this one. A good way to get aquainted with it is to do two things during addon development and testing: <ul> [*] Use mod folders [*] Test on linux dedicated servers (perhaps using mod folders) Both are very unforgiving with regards to improper/missing addon dependency declarations...

Tonal, like all islands, only have one airport that is "AI compatible", i.e where AI:s can take off and land. For Tonal, this is the big airport in the middle of the island. What is happening is that your AI Cessna is trying to taxi towards the take-off point on that main airfield (which is east of where you put the Cessna) Yep, bummer. Here's hoping OFP2 will enable us to use more than one airstrip for AI aircraft.

Gourka, this is due to the bas_opcpp.pbo not having specified what other addons it depends on. If you have some experience in meddling with addons you can fix it yourself. See my post on page 28 of this thread dealing with (among other things) the requiredAddons property. Either that, or wait until the good ppl in BAS fixes it. NB: Of course, putting the addon into the base OperationFlashpoint/AddOns folder hides the bug.

That means you already know of this: Rule #1 of Action: Action has to be performed where the unit is local and only there, ie nowhere else. <ul>[*] The player and any AI:s in his group is local to the players OFP process ("his computer"). [*] Every player's soldier is local to his OFP, even if said player is in the same group as a human leader with other AI:s in the group. [*] AI:s not under any player's control are local to the server. This might be a OFP process where a player is too (Hosting a MP game on your machine) [*] AI:s on a dedicated server is local to that OFP server session. One can imagine running both a deddy and a normal OFP session on one machine. "Locality" therefore refers to a process, not a certain "computer". This means: <ul>[*]To eject the player and any AI:s under his control, the dude Action ["EJECT",aircraft] has to be executed in the players OFP session and only there [*]To eject AI:s under the deddy's control, you'd do the Action there and nowhere else [*]To eject a mixed group of MP players and AI that are all in the same group, you'd have to do the "eject action" wherever each unit is local. The trick is to do all this right. Triggers are one foundation of doing it, separate scripts another. (Combinations possible, where a trigger calls a script). Just make sure to pin down the locality properly and code the trigger and/or scripts the right way. This means knowledge of and proficiency in using the scripting command local. Yep, its hell. Perhaps you alredy know all/some of this and have actually found something weird in 1.94. I'd love to see the offending code/mission to help isolate the problem, though. Like someone said, "coops, the final frontier"

Aha! You only need to put that line into the "On activation" field of the trigger. (It makes no sense to put that particular line into a unit's init line) Ok, got it. Two problems here and two easy solutions. First, in order to only have soldiers and not vehicles deleted you need to change the trigger line above to <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> {if ( "Man" countType [_x] == 1) then {_x addEventHandler ["killed",{_this exec "delunit.sqs"}] } } forEach thislist Also, when players respawn, the EH:s they had when the mission started (thanks to the trigger above) will be lost, so we need to add new EH:s to the newly respawned soldiers. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ; ; respawnmonitor.sqs ; ; Description: adds a "killed" event handler named "delunit.sqs" to certain respawned units ; ; Usage: ["unitname"] exec "respawnmonitor.sqs" ; ; How *not* to use it: [unitname] exec ... ; Also, dont do this: unitname exec... ; ; Example: ; You have a 4 vs 4 MP game. Name all west units "w1", "w2" and so on ; and the east units in a similar way can be named "e1", "e2",... ; ; In init.sqs, have the following: ; ; _wdudes = ["w1","w2","w3","w4"] ; _edudes = ["e1","e2","e3","e4"] ; _dudes = _wdudes + _edudes ; ; {[_x] exec "respawnmonitor.sqs"} forEach _dudes ; ; ; Notes: Script inspired by toadlife's "Universal Weapons Respawn script" ; (Can be found on OFPEC, http://www.ofpec.com/ ) ; _name = _this select 0 #checklocal _unit = call format ["%1",_name] ?local _unit:goto "respawnloop" ~(1 + (random 3)) goto "checklocal" #respawnloop // Just wait 'til its dead @!alive _unit #waitforlife @alive call format ["%1",_name] _unit = call format ["%1",_name] // Re-attach a killed EH to the newly respawned _unit addEventHandler ["killed",{_this exec "delunit.sqs"}] goto "respawnloop" As you can see, I included instructions on how to use and employ this script in the code itself. Too tired to repeat it here... Exactly

Correct You put what where? Answer with sentence(s) containing punctuation. The "~10 delay" has nothing to do with the respawn delay you set for your mission. The delay in the script snippet above determines how long a body remains before getting removed. PS. Now, you did put RED's script example into a script named "delunit.sqs", right?

Another way to solve it, as I see you have Resistance, is to simply not use the old CWC/1.46 version. The error message you get comes from the fact that Kegetys Editor Addon 1.11, strangely enough named "editorupdate102.pbo" requires OFP 1.75 or later. This means Resistance (which was released as version 1.75 but now can be patched up to 1.91 and/or 1.94beta). I'm not sure what you mean here... you can play missions on the Everon Island using Resistance (again, version 1.75 and preferably later) just fine. Or you mean a mission (your "map") that is called "Everon"? Again, I see no reason to play your games using the old CWC 1.46 version. You can "play on GameSpy" using Resistance too. It even has its own GameSpy browser built in. Rather nice, eh?

When an addon defines its own event handlers, even if they are not the same as the ones that the explo mod uses, any event handlers defined further up in the hiearchy will be lost. To be more specific, the "blood varants" of GMR:s config.bin has this in class Man: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class EventHandlers { init="[] exec ""\OFPEC_Blood\blood_init.sqs"""; hit="_this exec ""\OFPEC_Blood\blood_squirt.sqs"""; }; This means that by default, all units (soldiers and civilians alike) will have the "blood feature", since they all inherit from that base class "Man", i.e will have the same properties as Man unless they change all or (more often) some of them. However, as an example, when looking at the configuration for "BAS_GovernmentOfficer" in the config of the BAS OPFORS (bas_opcpp.pbo), we find the following: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class BAS_GovernmentOfficer: OfficerG { ... class EventHandlers { fired = " if ( (_this select 1 in [{Throw},{JAM_AT4Launcher},{JAM_RPG7Launcher},{JAM_M72LAWLauncher}]) or (_this select 4 in [{JAM_MarkerGrenadeammo}]) ) then {_this exec {\JAM_Magazines\FX\firedEH.sqs}}"; }; ... What happens here? Well, the Gvt. Officer will only have the fired event handler. The init and hit event handlers that were defined in Man (the Gvt. Officer is a "subclass" of Man; I took out the parts showing that for brevity) are gone. I think we can all agree that this is sad news, to put it mildly... I wish there was a way to add event handlers to a unit/vehicle, event handlers not necessarily defined in a parent class, instead of simply replacing them. However, the OFP config "language" seems to have no constructs for allowing that, which I believe is most unfortunate and goes against all sane principles of object-oriented software systems. The solution, of course, is to manually add the blood init and hit EH:s to any and all units where you want it...

Ok, this thread is a bit silent, so I thought I'd spice it up a bit for your enjoyment. I am working on adding JAM-equipped versions of UceE:s ME Resistance soldiers as a separate addon. The first version had some quirks... to be continued... EDIT: Minutes later, try this one: UCE ME Resistance soldiers 1.1 + JAM variants

Ok, this thread is a bit silent, so I thought I'd spice it up a bit for your enjoyment. I am working on adding JAM-equipped versions of UceE:s ME Resistance soldiers as a separate addon. The first version had some quirks... to be continued... EDIT: Minutes later, try this one: UCE ME Resistance soldiers 1.1 + JAM variants

Winters, good show, old boy! Had me a good laff there! Thanks!

SiS? Stability? I'd get a i875 board instead. Don't cheap out on a server.

Its included in this addon: SEBDeltaForce2_00_STTMKey1_10.zip

I recommend SES and Zeus Addons for coop. SES homepage (Server in England, I think) Zeus homepage (Server in Germany) You can find connection and addons details on the sites listed.

DivX.com

As far as I can tell, the reason the old ME Res addon causes the error is due to an empty "Groups" declaration in the CfgPatches part of its config. Many older addons have that and exhibit the same "phantom groups in mission" behaviour. (The bas_repair needs the ah64 as a requiredAddon since it inherits from it. The other helos that bas_repair uses don't require that since they aren't addons.)

As far as I can tell, the reason the old ME Res addon causes the error is due to an empty "Groups" declaration in the CfgPatches part of its config. Many older addons have that and exhibit the same "phantom groups in mission" behaviour. (The bas_repair needs the ah64 as a requiredAddon since it inherits from it. The other helos that bas_repair uses don't require that since they aren't addons.)

Yes it does, unfortunately with a twist - it won't remedy the fact that old missions have "groups" listed in their mission.sqm. This can also be expressed as "it wont resolve the missing groups error for existing missions". New missions will not have that problem. Also, it can be put in a mod folder. Making the addon "properly configured" is the best I can do. I dont see a way to both do a proper addon and cure the "missin addons groups in old missions" problem. By that I mean that there's no way to configure the addon to accomodate older, "faulty" missions and let the addon act properly when used in making new missions.

Yes it does, unfortunately with a twist - it won't remedy the fact that old missions have "groups" listed in their mission.sqm. This can also be expressed as "it wont resolve the missing groups error for existing missions". New missions will not have that problem. Also, it can be put in a mod folder. Making the addon "properly configured" is the best I can do. I dont see a way to both do a proper addon and cure the "missin addons groups in old missions" problem. By that I mean that there's no way to configure the addon to accomodate older, "faulty" missions and let the addon act properly when used in making new missions.

Ok, ok.. I'll pack it up and get it into your hands. I'll add to the old readme so as to give credit where credit is due. Real soon now... ...like now Consider this a "1.1 beta". It requires Resistance, version 1.85 or later. This means that it will not work with OFP 1.46, for example. Pick it apart and abuse it and yell in my general direction. I'll be on station for any venting needs. Bug reports and suggestion are, of course, more welcomed. Also note that I am not the one who made the models. Heck, I can't even do a proper wooden box in O2... UceE is the creator and Skaven has also done work on these soldier. For what its worth: Â UCE Middle Eastern Resistance, 1.1 beta + JAM Note: I *don't* want to see this on @WAR, ofp.info or any other of the big addon outlets just yet. Keep it here for a while. After all, its a beta EDIT: Just got a letter from Skaven. I have his blessing in improving the addon. Thanks, Skaven. If you're in contact with Jussi (UceE) please extend mine and the community's thanks for his work. PS. I'd say this thread is budding for a relocation to A&M:D EDITED: Link to newer version

Ok, ok.. I'll pack it up and get it into your hands. I'll add to the old readme so as to give credit where credit is due. Real soon now... ...like now Consider this a "1.1 beta". It requires Resistance, version 1.85 or later. This means that it will not work with OFP 1.46, for example. Pick it apart and abuse it and yell in my general direction. I'll be on station for any venting needs. Bug reports and suggestion are, of course, more welcomed. Also note that I am not the one who made the models. Heck, I can't even do a proper wooden box in O2... UceE is the creator and Skaven has also done work on these soldier. For what its worth: UCE Middle Eastern Resistance, 1.1 + JAM Note: I *don't* want to see this on @WAR, ofp.info or any other of the big addon outlets just yet. Keep it here for a while. After all, its a beta EDIT: Just got a letter from Skaven. I have his blessing in improving the addon. Thanks, Skaven. If you're in contact with Jussi (UceE) please extend mine and the community's thanks for his work. PS. I'd say this thread is budding for a relocation to A&M:D EDITED: Link to newer version

Oh dear... here's a tip for budding addon fixers: when you edit an addon, make sure you don't have the old, broken addon hidden in a different mod folder that you also load when starting OFP. Â Anyway, now I'm fairly certain that it works as intended. This means no more spurious "groups" being added to missions and correct behaviour when used in a mod folder. Creating a test mission correctly adds all relevant unit classes to the addons[] and/or addonsAuto parts of a mission. Again, no "groups". About the ghost "uce_r_kuffiyaATGrenadier" in the CfgPatches part. I tested the old addon, and just as I expected, this ghost declaration wont put a "uce_r_kuffiyaATGrenadier" line in the mission.sqm. With this in mind, the new one will however add a "uce_r_kuffiyaGrenadier" (no "AT"). Now, for the possible caveats part: <ul>[*]Older missions still have the rogue "groups" part listed. The fixed addon wont remedy the cries for "missing addons groups" when loading such missions. That's not a "bug" in the new addon. [*] However, as stated, the new one will no longer add that to new missions you make. And, from the "don't shoot the repair man" department: as one can see from the relatively large number of addons[] elements it adds to missions (one for the officer, one for the medic and so on), this addon has a heritage that leads back to the golden days when the community was a bit greener than today. If I were to really rework it, I'd ditch the compatability with the older missions and re-configure it to keep all the new units within a single class, say a "uce_r_kuffiya". Now, I need some sort of green light from UCE or Skaven...

Oh dear... here's a tip for budding addon fixers: when you edit an addon, make sure you don't have the old, broken addon hidden in a different mod folder that you also load when starting OFP. Â Anyway, now I'm fairly certain that it works as intended. This means no more spurious "groups" being added to missions and correct behaviour when used in a mod folder. Creating a test mission correctly adds all relevant unit classes to the addons[] and/or addonsAuto parts of a mission. Again, no "groups". About the ghost "uce_r_kuffiyaATGrenadier" in the CfgPatches part. I tested the old addon, and just as I expected, this ghost declaration wont put a "uce_r_kuffiyaATGrenadier" line in the mission.sqm. With this in mind, the new one will however add a "uce_r_kuffiyaGrenadier" (no "AT"). Now, for the possible caveats part: <ul>[*]Older missions still have the rogue "groups" part listed. The fixed addon wont remedy the cries for "missing addons groups" when loading such missions. That's not a "bug" in the new addon. [*] However, as stated, the new one will no longer add that to new missions you make. And, from the "don't shoot the repair man" department: as one can see from the relatively large number of addons[] elements it adds to missions (one for the officer, one for the medic and so on), this addon has a heritage that leads back to the golden days when the community was a bit greener than today. If I were to really rework it, I'd ditch the compatability with the older missions and re-configure it to keep all the new units within a single class, say a "uce_r_kuffiya". Now, I need some sort of green light from UCE or Skaven...

Correct. Quite right - it might be that "doing it the other way around" would be better with regards to old missions. I'll have to test with the old addon. Here's how I reasoned: while the CfgPatches part has the ATGrenadier declared, there is no ATGrenadier defined later on in the CfgVehicles part. Also, there's no anti-tank anything about that grenadier dude, so in the name of consistency, I thought it best to rename the declaration and not the definition of that unit. To be continued... PS. Skaven, if you read this - throw away that config.cpp I mailed you. "It no workie" :-)

Correct. Quite right - it might be that "doing it the other way around" would be better with regards to old missions. I'll have to test with the old addon. Here's how I reasoned: while the CfgPatches part has the ATGrenadier declared, there is no ATGrenadier defined later on in the CfgVehicles part. Also, there's no anti-tank anything about that grenadier dude, so in the name of consistency, I thought it best to rename the declaration and not the definition of that unit. To be continued... PS. Skaven, if you read this - throw away that config.cpp I mailed you. "It no workie" :-)