killswitch

It uses ICP_rfwp. Sorry - bad wording on my part. Yes - the actual addon file is ICP_rfwp.pbo. Inside it, the CfgPatches part defines "ICP_weaponpack" which is what one needs to declare as a dependency in any addon that uses the weapons pack. The corrected config linked to above remains correct with regards to the issues stated.

Excellent stuff! Had a peek at the config, and it needs a bit of love&caring to make the addon work in MP on dedicated servers.<ul>[*]Addon dependency list incomplete [*] units[] list incomplete [*] Some unbalanced {}:s in the CfgGroups part The addon uses the ORCS RF Weapons pack (ICP_weaponpack<span style='color:red'>*</span>) so it needs to declare that. Otherwise, MP servers using this might just silently refuse to load missions using them. (Most common sign of this is that you select a mission and OFP immediately returns you to the mission selection screen) Again, thanks for a very nice addon! <span style='color:red'>*</span> Edit: The weapons pack addon itself is of course called "ICP_rfwp.pbo" but declares ICP_weaponpack in CfgPatches.

You might want to consider using the CoC Network Services 2.0 for your addon. That or see how they did it - it uses a system with createUnit to do exactly what you describe. It might save you some time, I mean. It will require the users of your addon to place a GameLogic type object in the mission, but that's it.

Since you have to ask what "the overclocking thing" is, I'm beginning to regret I wrote it :-) See, overclocking will void the warranty on the computer and it might even make it break. "Overclocking" is the art of making something work faster than it was sold to you as. OC:ing the processor will make it hotter and unless one knows what one does, there's a very good chance of things going very wrong. I don't have the time to write a tutorial on how to do it, so I suggest you search the internet and read up a lot on the subject before even considering it. I don't want you to damage your computer because of something a crazy stranger like me on the net told you to do.

<ul>[*] Turn off vehicle shadows [*] Turn off object shadows [*] Lower view distance to 900-1000 m [*] Lower terrain detail to "Low" or even "Very low" [*] Overclock the CPU (If you have PC3200 RAM, set the FSB from 166 to 200 MHz and you might end up with a XP3200+) [*] That GF5200 is way underpowered for the settings you listed. I know, I had one. Further improvements need breaking of the old piggy bank. (Get a sound card with HW Sound acceleration such as the SB Audigy 2, get a *much* faster gfx card or just about upgrade the whole computer)

Unfortunately, in OFP, the marker text cannot be changed while a mission is running. It was requested time and again way back but never added to OFP. (In VBS-1, however, such scripting commands have been added and existed long before the last patch to OFP was issued. Make of that what you will...) CTI changes just the marker type (using setMarkerType) after a unit is killed/destroyed.

Heh, oddly enough that is the exact reason I decided to try it aswell - Miles' postings usually being cool and written in whole sentences so I knew I had to try it And yes, they are all that - the tracers are gorgeous!

Hello. The problem you're having is probably the "CoC_ObHum issue" and that's just a config buglet with UA 1.0 unrelated to WGL. What you need to do is to fix the addon yourself. Two things needs to be done to the config.cpp of CoC_Arty.pbo:<ul>[*]Remove the sounds[] property from class CfgSounds [*] Remove the sounds[] property from class CfgRadio See this thread on the CoC Forums: CoC ObHum not found CoC have stated that they won't release a quickfixed 1.0, seeing as how UA 1.1 is in the making and it will have this bug fixed. However, UA 1.1 isn't ready yet so you might as well fix your CoC_Arty yourself. As for future improvements to WGL, I have no idea but agree with you that it would be nice to see it evolve.

when trying to load a mission on a dedicated Linux server...This is using Haliuoto 1.2 and the latest (December 01) version of the house addon (haus.pbo, size 44 605 743 bytes, dated 2004-11-30 22:37) Just uploaded a new version with a few minor improvements. See if it works better. That one seems to have done it. Yay! For people re-downloading it: the one I tried with and that seems to work is<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">haus.pbo size: 45 035 041 bytes, dated 2004-12-07 22:21 Many thanks for the quick update, Ares!

I'll echo Buliwyf's problem: either the island or Instructor's Finnish houses addon has a nasty texture file in it. Server crashes and spits out<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Invalid texture aspect ratio (128x2048)when trying to load a mission on a dedicated Linux server... This is using Haliuoto 1.2 and the latest (December 01) version of the house addon (haus.pbo, size 44 605 743 bytes, dated 2004-11-30 22:37)

You don't want to do that - the old, "regular" UCE ME Resistance is broken as hell(*) and will cause trouble when used on dedicated servers. A working link to the archive containing the fixed regular one and the JAM variant is above, but I'll just repeat it here: UCE ME Resistance 1.1 and JAM variant 1.0 (*) UCE ME Res 1.0, the old one, has the following deficiencies:<ul>[*] Fails to declare its addon dependencies [*] Has a phantom "groups" entry in the CfgPatches part which messes up missions and causes 'Cannot load mission: missing addons "groups"'-errors The thread linked to in the first post of this thread (near the now-broken link to the fixed addon) has a longer discussion on this matter, the fix and its resulting "caveats".

Yeah, the old computer I'm hosting that on is down due to a fan failure. I'll see if I can get it running again soon. *EDIT: Grab it from here: UCE ME Resistance 1.1 (incl. JAM variants) I recently (2004-11-16) did tweaks to it:<ul>[*]uce_kuffiyajam.pbo can now be used by itself alone with JAM2. (repathed textures in the soldier model) [*] Said addon has a few new variants of soldiers sporting more JAM weapons

That one is a known issue with FDF 1.3. You need to have a look in your finmod/addons folder and make a copy of the file "fdf_w12.pbo" and rename the copy "fdf_w13.pbo". In other words, when you are done, you'll have two files; one file called "fdf_w12.pbo" and another file called "fdf_w13.pbo", both the same size.

For SP, it's what Gen. Barron said combined with the CoC Command Engine and JAM HD. Great feeling hearing prolonged shootouts in the field back at HQ For MP...well, pretty much the same: missions that make you feel you're part of a bigger event, not yet another "You are Colonel Biff Starlight, commander of TaskStrikeForce FreedomL337LiberationRoxx0r and we have reports of a stolen Scudzzzzzzzzzzz". Please... More "Band of Brothers" instead of "Braddox: Missing in Action III", if you know what I mean?

A fired EH for a plane is added to the plane. A fired EH for a playable unit is...yep, added to that unit. Consider this contrived example: one can imagine setting up the plane's fired EH in the init line of a playable unit and that unit's fired EH in the init line of the plane. Not that there's any compelling reason to do so, but doing that mental exercise and understanding the following - why it could be done, how it could be done and why it's unadvisable to do so is good training in mission editing.

Bingo! We have a winner. Stock MFCTI code is probably the pinnacle of desync-generating gameplay code in OFP missions - hideous amounts of redundant publicVariable calls, so I think the reasons for your AA missiles not hitting home can be sought there rather than in sinister advesarials up to no good. Were you able to check the desync numbers for the players and the server framerate at the time? I'd look at that first. However, cheating seems abundant - a loser born every day, so I'm not ruling that out either. There are several efforts out there in making a less "desyncy" CTI and I suppose the most well-known one is CRCTI. I'm sure the more CTI-savvy readers of this forum can tell you more about what's out there.

Not UA 1.1, which is what the last occurence of "1.1" above is referring to. I'll summarise it again, in a completely unambigous way for people unaccustomed to "context" in a block of text: The DPM 1.1 patch correcting "the problem with the Clansman radio" will make it possible for the future UA 1.1 to recognize said radio. The current UA, 1.0, has a fixed set of radio class types it recognises and will still not detect the Clansman. This fixed set of radio types cannot be extended by any third party addon outside of UA 1.0, since its hardcoded into UA 1.0. In other words: the 1.1 DPM pack cannot be further patched to make UA 1.0 "work" with it.

The UA fix is for the upcoming UA 1.1. Due to the way the UA 1.0 radio detection works, UKF can't "patch" the DPM pack to let the radio work with the current UA, 1.0. So you'll have to do it the manual way (see UA docs) until 1.1 is here. In the mean time, take faith in that when it is ready, your DPM chaps will be able to call in arty just fine.

I don't see how it can do that. The LD_LIBRARY_PATH is between the OFP start script in which it is set and the ofp server process started from said script, unless I'm missing something. You don't want to set the ofp-specific LDLP globally. A D-link card in a server? I know where the CPU time is spent... Keywords: Intel/Broadcom: good. D-Link/Linksys/Realtek: toys Nope You will probably see missions mysteriously refusing to load. This has its origin in the huge amount of broken addons out there. They are not declaring their <span style='color:red'>addon dependencies</span> correctly/completely or at all. This leads to either the server not loading the broken addons or missions. Also the affected missions either won't have enough (or more often: too much) in their addons[] and addonsAuto parts. A forum-wide search on the subject might provide more insight. Look up taskset and it shall set you free I use that to lock one server process to one of the two physical CPUs and the other (ofp) server process to CPU #2. No idea. Haven't examined if it even works (ie makes a difference) for Linux. It sure helps in windows with broke-a** ATI drivers...Good luck and keep us posted of any interesting findings!

Using Fedora Core 2/x86_64 here on a 2.6.x kernel with a LD_LIBRARY_PATH "trick" in conjunction with a set of older libs. That trick is described here: "1.96 on Suse" And yes, it would be very nice to have the linux server be recompiled with more up to date compilers and libs. Also, to get the 1.96a Win32 fixes in there.

Ok, Defcon 1 again. We found the snag. One of WX:es mission scripts defined a variable called "drop" and set it to false. However, the name drop is a reserved name - its the name of the script function drop and therefore the script internal to the F4 addon that creates the exhaust smoke using drop failed. So in summary: don't define variables that are named the same as one of OFP:s own scripting commands

Can't seem to recreate it either. I believe the source of the latest version of Footmunches planes is this: Footie's planes At least, that's where I got my "latest version" of the F4E.

Thanks! Can you summarize what had to be changed to achieve this? Once I understand everything done, I'll put out an updated version of the MAAM_Magazines.pbo file. The changes were quite simple: <ul>[1] Declare class ECP_EventHandlers just above CfgVehicles [2] Slight change to the units' EventHandler definitions. 1. Declare an emtpy class ECP_EventHandlers just before CfgVehicles: 2. Change of the EventHandlers defintions Example: class MAAM_WBSoldierBase <span style='color:darkred'>Before</span> <span style='color:green'>After</span> The new parts are in <span style='color:green'>green boldface</span>: There are quite a few places where the latter part has to be done. Feel free to use the one I linked to, the only changes are the ones I described here. Well, technically, I sorted out some indentation crimes too...

Interesting initiative. Let's see how this turns out. Initial findings/suggestions: ClickTeam must die I need a version of the AMORE stuff in non-installer format. Bog standard, useful .RAR will be fine. Do I really need to state the reasons, again? (Keywords: "installers","suckage","back holes". On a more serious note: development, efficiency and dedicated (linux) server deployment.) ECP compatibility This one is dead easy and completely transparent to non-ECP users. Either go grab the ECP-compatible JAM2 on OFPEC or just use the one I made: <span style='color:red'>EDIT: link removed - the fixes have been incorporated into MAAM</span> The development process How will this work? The workflow? The process of getting a new MAAM weapon/magazine suggestion reviewed and accepted into MAAM? I mean, I can see it now... config kiddies wanting their special hand held Magnum 16" Ultra LGB handheld RoboCop replica with 48x scope and SmartBombâ„¢ launcher attached into MAAM.

Now, for some actual help: Variant 1: all your addons are in a zipped mod folder tree If your zip files already have the correct mod folder tree (in other words, when you open the zips, you see two things: 1) The auto-addon.txt 2) A mod folder "to be". Inside this you then have the actual addons in a folder "addons", as usual If so, the auto-addon.txt could look like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">AUTOADDON_START PACKAGE "@1_8th_all_1" INFOURL "http://www.1-8th.com" INSTALLPATH * AUTOADDON_END Variant 2 Just a bunch of addons and an auto-addon.txt For this variant, you need to tell OFPWatch where to put the addon .pbo:s and other files after they're downloaded. Let's assume we want them to go into the "mymod" mod folder. Also, there are readmes included. We'll put those into mymod/docs. The auto-addon.then becomes <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">AUTOADDON_START PACKAGE "@1_8th_all_1" INFOURL "http://www.1-8th.com" INSTALL *.pbo mymod/addons/ EXTRACT *.txt mymod/docs/ AUTOADDON_END Take extra care to remember to leave the trailing slashes but don't have the leading slash. In other words: Hope that helps!