killswitch

Crap... Darn that "groups"...thought I had that one. Ok, blame it on lazyness and me being hungry. To be continued. I won't let you guys test something obviously faulty... More after dinner...

Crap... Darn that "groups"...thought I had that one. Ok, blame it on lazyness and me being hungry. To be continued. I won't let you guys test something obviously faulty... More after dinner...

(folds up sleeves) Oookey, what seems to be the problem here... Â (minutes later...) There. And it didn't hurt one bit. What I did:<ul>[*]Added proper requiredAddons[] where needed (on all units except the machine gunner and the grenadier. They dont need it) [*] requiredVersion = 1.85 for the requiredAddons-affected units. [*] The grenadier unit was named "uce_r_kuffiyaATGrenadier" in the cfgPatches part, but uce_r_kuffiyaGrenadier down below in the cfgVehicles. Now they are both "uce_r_kuffiyaGrenadier" everywhere(*) [*] Moved the wounds[] into a #define to make the rest of the config easier to read Now, how do we/I go about disseminating this? It's UCE:s creation and managed by Skaven, if I understand it correctly. I have e-mailed Skaven via the address in the readme provided in the .zip with said units I found at ofp.info (*) Not sure how this will affect existing missions. Testing needed.

(folds up sleeves) Oookey, what seems to be the problem here... Â (minutes later...) There. And it didn't hurt one bit. What I did:<ul>[*]Added proper requiredAddons[] where needed (on all units except the machine gunner and the grenadier. They dont need it) [*] requiredVersion = 1.85 for the requiredAddons-affected units. [*] The grenadier unit was named "uce_r_kuffiyaATGrenadier" in the cfgPatches part, but uce_r_kuffiyaGrenadier down below in the cfgVehicles. Now they are both "uce_r_kuffiyaGrenadier" everywhere(*) [*] Moved the wounds[] into a #define to make the rest of the config easier to read Now, how do we/I go about disseminating this? It's UCE:s creation and managed by Skaven, if I understand it correctly. I have e-mailed Skaven via the address in the readme provided in the .zip with said units I found at ofp.info (*) Not sure how this will affect existing missions. Testing needed.

I had a look at it... ok, np. Fixed. See the other thread.

Athlon XP1900+ (1.6 GHz, 12x133) Asus V7700 Deluxe (GeForce 2 GTS, 32 MB @220/348, driver 45.23) Abit KR7A-RAID (KT266A), 512 MB DDR 2100 POS BSLive Value First run: OFP 1.92b with -nomap (for no good reason but to lower the score even more due to constant disk access) Test 1: 13.7 Test 2: Â 9.1 Test 3: Â 9.0 Test 4: Â 4.6 OFPMark: 910.65 2nd run: 1.92b without -nomap and preloading of Nogova via the mission editor, then running ofpmark: Test 1: Â 14.2 Test 2: Â 16.7 Test 3: Â Â 8.9 Test 4: Â Â 5.0 OFPMark: 1118.57

Excellent work, BAS! I found some quirks/bugs in the config.cpp of bas_opcpp.pbo. In time, I'll check the bug report page if these are known bugs, but at the moment the whole BAS homepage is, unsurprisingly overloaded. Summary: <ul>[*] In units[], there's a missing comma sign between "BAS_RebelMedic" and "BAS_GovernmentOfficerHD". [*] units[] has only the soldiers and not the vehicles listed. [*] requiredAddons[] needs fillings, as benu noted before. [*] BAS_ZU23 uses the old "irScanRange" property in stead of the new irScanRangeMin and irScanRangeMax Units list Some ways down the huge list of units listed in the units[] property of class BAS_OPFOR we find: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ...,"BAS_RebelMedic""BAS_GovernmentOfficerHD",... which has a missing comma sign and should read <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ...,"BAS_RebelMedic","BAS_GovernmentOfficerHD",... Also, that list lacks all the vehicles the addon has. I suppose they should be listed there, so my suggestion is to add <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> "BAS_AUAZPK", "BAS_AUAZDShK", "BAS_AUAZDShK2", "BAS_GUAZPK", "BAS_GUAZDShK", "BAS_AUral", "BAS_AUral2", "BAS_GUral", "BAS_KLR", "BAS_GBRDM", "BAS_GBRDMPK", "BAS_RebelBRDM", "BAS_RebelBRDMPK", "BAS_GovBMP", "BAS_RebelBMP", "BAS_AT55", "BAS_GT55", "BAS_GZSU", "BAS_GMI24", "BAS_GMI8", "BAS_ACessna182", "BAS_GSU25", "BAS_DShK", "BAS_DShKG", "BAS_DShKA", "BAS_ZU23", "BAS_AZU23", "BAS_GZU23" to the units[] property. Improper requiredAddons declaration Seems a lot of addon makers have problems getting this one right. As indicated by earlier posts in this thread by benu and others, it leads to either strange "missing addons" messages and/or non-working linux servers. This is something that addon makers really have got to start getting right from the onset. Anyways, from looking at the config, the following should suffice to make bas_ofpcpp.pbo correct in that regard: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> requiredVersion=1.85; requiredAddons[]={BIS_resistance, BRDM, JAM_Magazines, Su25}; Note that requiredAddons, as I recall it, is a feature that came with 1.85. Use of the CWC, pre-resistance irScanRange property Starting with resistance, the irScanRange property looks to have been replaced with the two properties irScanRangeMax and irScanRangeMin. Looking at the config, again, I see that the BAS_GBRDM uses the new properties, whereas the BAS_ZU23 has the old one. You might want to change the config of the latter. Of course the old property still seems to work, but use of the newer ones in all BIS units might just be due to optimizations done in Resistance. Again, thanks for another great set of addons and missions! Â

Thing is, AFAIK, sadly <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">respawn=side is non-functional in OFP and will in actuality be the same as <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">respawn=groupi.e one respawns into the group. One of those remaining really annoying bugs/"features"...

The forum, in collaboration with my Notepad sometimes botches the formatting in " " segments. I re-pasted my burn.sqs into the above message again. Try and copy the "new" one again. Also check that the "drop" commands are on one line only.

Okeydokey... how do these behave? fire.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; ; fire.sqs ; _posDrop = _this select 0 _velocity = _this select 1 _lifeTime = _this select 2 _intensity = _this select 3 _object = _this select 4 _delay = 0.3 _lifeTicks = _lifeTime / _delay _lifeTick = _lifeTicks ; *Slight* optimization for the effects-loop below _pos_z15 = [(_posDrop select 0), (_posDrop select 1), (_posDrop select 2) + 1.5] _pos_z10 = [(_posDrop select 0), (_posDrop select 1), (_posDrop select 2) + 1] ; Start the "ouch, fire, hurts!" thread on all machines. [_posDrop, _lifetime] exec "FX\Fire\BurnInit.sqs" ; If the GL "Server" is local and player is undefined, we are either running ; on a dedicated server or in a SP intro/outro. For now, we assume this script ; will only be used in a MP mission. We wont do the visual effects on a deddy. ?(local Server && !(player==player)): exit ; Burn, baby, burn. #Begin drop ["cl_basic", "", "Billboard", 1, 1.5, [(_posDrop select 0), (_posDrop select 1) + random 0.5, (_posDrop select 2) + 1.5],[random 0.3, random 0.3, random 0.3], 1, 0.004, 0.004, 0.1, [5*(0.1 + 0.2 * _lifeTick/_lifeTicks), 5*(0.1 + 0.5 * _lifeTick/_lifeTicks), 5*(0.1 + 0.1 * _lifeTick/_lifeTicks)], [[0,0,0,1], [0,0,0,1], [0,0,0,1], [0,0,0,1]], [0,1,0], 0.5, 0.05, "", "", ""] drop ["cl_fire", "", "Billboard", 1, 1.5, _pos_z15, [(_velocity select 0) + random 0.3, (_velocity select 1) + random 0.3, (_velocity select 2) + random 0.3], 1, 0.004, 0.004, 0.1, [(0.1 + 0.2 * _lifeTick/_lifeTicks) * _intensity, (0.1 + 0.5 * _lifeTick/_lifeTicks) * _intensity, (0.1 + 0.1 * _lifeTick/_lifeTicks) * intensity], [[.4,.9,1,0], [1,1,.9,1], [1,1,1,0.6], [1,.8,.8,0]], [0,.5,1], 0.5, 0.05, "", "", _object] drop ["cl_fire", "", "Billboard", 60, 9, _pos_z10 , [(_velocity select 0) + 1.5, (_velocity select 1) + 1.5, (_velocity select 2) + random 1.5], 1 , 0.185 , 0.155 , 0 , [0.05,0.25] ,[[0.3,0.6,0,1],[0.5,0.5,0,1],[0.75,0.75,0,1],[0.75,1,0,1]] , [0] , 0.3 , 0.3 , "" , "" , _object] drop ["cl_fire", "", "Billboard", 60, 9, _pos_z15 , [(_velocity select 0) + 1.5, (_velocity select 1) + 1.5, (_velocity select 2) + random 1.5], 1 , 0.185 , 0.155 , 0 , [0.05,0.25] ,[[0.3,0.6,0,1],[0.5,0.5,0,1],[0.75,0.75,0,1],[0.75,1,0,1]] , [0] , 0.3 , 0.3 , "" , "" , _object] ~_delay _lifeTick = _lifeTick - 1 ?_lifeTick > 0 : goto "Begin" burninit.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; ; burninit.sqs ; _firepos = _this select 0 _burn_time = _this select 1 _burning=[] _units=[] _safe_dist = 5 _gl = "Logic" camCreate _firepos _tar = list allist ; Prune the list of all units and make one containing only "Man"-type units (i.e soldiers and civvies) ; ; Reason? To save CPU time in the tightly timed loop below. ; {if (!(_x in _units) && ("Man" countType [_x]>0)) then {_units=_units+[_x];} } forEach _tar _ti = 0 _cunits = count _units #loop _unit = _units select _ti ?( _unit in _burning ): goto "nofx" ?( _unit distance _gl) < _safe_dist && (alive _unit): _burning = _burning + [_unit]; [_unit] exec "FX\Fire\Burn.sqs" #nofx ~.01 _ti = _ti + 1 ? (_ti < _cunits): goto "loop" _ti = 0 ~1 ? (_time < _burn_time) : goto "loop" deleteVehicle _gl exit And lastly, burn.sqs <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">; ; burn.sqs ; _unit = _this select 0 _lastPos = getPos _unit _lastDir = getDir _unit _dmg = getDammage _unit _d = 0.05 ; Now toast that poor sucker #burn ?(player==player):drop ["cl_fire", "", "Billboard", 1, 1.5, [(_lastPos select 0),(_lastPos select 1),(_lastPos select 2) + .75], [0,0,0], 1, 0.004, 0.004, 0.1, [(0.1 + 0.2), (0.1 + 0.5), (0.1 + 0.1)], [[1,1,1,0], [1,1,1,0.3], [0.3,0.3,0.3,0.5], [0,0,0,0]], [0,0.5,0], 0.5, 0.5, "", "", ""] _lastPos = getPos _unit _lastDir = getDir _unit ?local _unit:_unit setDammage (_dmg + _d) ~.01 _d = _d + .005 ? (getDammage _unit) >= 1 : _i = 0; goto "lowburn" goto "burn" ; Afterglow for the squadmates' barbeque #lowburn ?(player==player):drop ["cl_fire", "", "Billboard", 1, 1.5, [(_lastPos select 0) +(random 1*2)*(sin(_lastDir)),(_lastPos select 1) -1 +(random 1*2)*(cos(_lastDir)),_lastPos select 2], [0,0,0], 1, 0.004, 0.004, 0.1, [(0.1 + 0.2), (0.1 + 0.5), (0.1 + 0.1)], [[1,1,1,0], [1,1,1,0.3], [0.3,0.3,0.3,0.5], [0,0,0,0]], [0,0.5,0], 0.5, 0.5, "", "", ""] _i = _i + 1 ~.1 ? (_i >= 50) : exit goto "lowburn"

Lol...this is like squeezing blood from a rock... what value do you use, i.e. how many seconds. Answer with a number.

Ok. Called from a trigger for certain vehicles... got it What I meant about the lifetime parameter was "what actual value in seconds do you use". Will the vehicle burn for 1 minute? 10 minutes? Working with the scripts... to be continued...

Hi Hark. If you could take some time to answer my questions above, we'll take it from there...

Well, I needed to learn about drop anyway... Also, I hope that disseminating "better practices in OFP script coding" will be beneficial to the community. Spawning CPU heavy script threads 3 times a second is a dragon well worth slaying...

Holy CPU torture, Batman  A couple of questions:<ul>[*]How often/from where is firesource.sqs called? In a unit/vehicle's init or from, say, a killed event handler? From a trigger? If a trigger, how is the trigger set up (condition)? [*] fire.sqs looks like it has been slightly modified from its original. (_Duration isn't defined so _numloops is bogus and is not even used later). Can I have a look at the original? [*]What value of the parameter _lifetime is used when calling firesource.sqs? *Important* [*] fire.sqs, depending on _lifetime, might be wasting CPU. It will generate calls to BurnInit.sqs every 1/0.3 secs (about 3 times per second). We'll get to that... [*] BurnInit in itself is a major CPU chewer... oh dear... [*] So is burn.sqs. Tell me a little about its intended use and I'll see if I cant rework the whole mess to be nicer to both clients and servers...

First page, 8th post. Then, its repeated many, many times over on many pages of this thread. I takes very little effort to find it.

The correct way to list mod folders with the -mod parameter is <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> -mod=BAS;DKMM so use that instead. If it still crashes, so be it. At least you are using the -mod parameter the right way.

Excellent writeup, Tex. Reminds me of some of my deadstick landings in Falcon 4. You get this sinking feeling (in more than one way ) in the stomach when the heater behind you gotes out... Then it's minutes of sweating while descending... "Cowboy 1, Mandumi tower. Next time, get clearance before landing"

Answer: MoH:AA follows the Half-Life heritage in that it is a "story-line fps", but other than that... If we were to discuss "enjoyable games based on a Hollywood-induced hype", the MoH franchise would fit in fine. Â MGS, on the other hand, I haven't played, so I'll take your word for it. My take on games that brought fresh blood to the genre: Deus Ex and Max Payne (FPS Noir, so to speak). Add Mafia to the list. In the near future? We'll have to see... And for a slight thread derailing, my nominations for "other genres" are:<ul> [*] Jet sims: Falcon 4 (eventually, that is). The standard. [*] Prop sims: IL-2. Without a doubt. Then UBI-soft politics got to them... (Witness the destruction of the RS6 franchise in RvS) [*] War games: Allied Assault: Red Devils over Arnhem. Be gone, foul hexes!

Yep, just like DV Chris put it, in the beginning stages of the dialog, you both expressed yourselves a bit too general. This left the door open for possible wrong interpretations to be spread, just like benu says above. One has to be careful both when reporting problems and when answering them, so as to not state something that is ambigous or won't cover all possible cases. But enough of that. Anyway, the addon dependency and ammo config quirks have been reported to DKM/ AKM74 so everything should work out for the best in the end.

Checked the config... yep, there's a few bugs/quirks in the ammo and weapons configs. (Sneaky dependencies on other addons, among other things). I'll continue digging and report my findings... The linux deddy is a wonderful addon testing tool. It reflects a little saying of mine rather nicely - "You either do it right or you use Windows"Â Perfect is good enough. We'll get there...

bd, a good heatsink might be the (very heavy) Zalman CNPS 7000A-Cu Silent and efficient. Also, you might want to consider the Antec Sonata case. Less noise = good, IMHO. Oh, and its black, too. Now, as to why you cheap out and get a 9600 is another matter. Â Get a 9800 while you're at it.

That is part of the old, 1.0 version of the F18. The current 1.3 has a different config and another name for its main gun. You'd have to find the old F18 to use RTS-3 as it stands today. I believe Karr. has the old one on his site (see first posting, I guess)

Interesting problem... my guess is that it will work as intended for the hospitals, which I assume are editor-placed empty buildnings. These will be local to the server and therefore be repaired by the server-local setDammage call. The bridge sections has me wondering, though... Not sure what terminology to use here..."static world objects" might work for this discussion. The bridge sections (just like most houses, trees, road signs and whatnot) exist "locally" on every machine in a MP session. Now, lets say that some player(not hosting) sneaks up and rigs and fires off a load of satchel charges and thereby destroying one or more of the bridge sections on his machine. In time, this damage will be distributed to all other machines and everyone will see a destroyed bridge. Judging from this, lets assume the following: setDammage on a bridge section will be distributed to all machines, sooner or later. Therefore, it just might work to only do a "setDammage 0" on the server. You'll just have to find a way to test it, though... PS. You can shorten your "init.sqs" to this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ?(local Server): [] exec "repairobjects.sqs"

Yep, that's a very useful addon editing/testing trick and all. But why quote my message? I don't quite understand what it has to do with the problem of reliably detecting wether an init event handler is running on a dedicated server or in a single player intro/outro? Or how it in a general sense solves any "MP usage workarounds" that I mentioned, without naming any particular such MP-addon-problem. Anyway...on with the thread...