killswitch

Just wondering... can anyone recreate the problem with a too long -mod= parameter I described in the beginning of this thread? I.e, create a bunch of mod folders with names long enough to make the whole "-mod=longname1;longname2;longname3..." become more than 80 characters long. Then try and host a MP game, i.e. klick "New" in the MP game browser. Hello, CTD! Suma? Is this reproducible at your end?

Remove any quotation marks in the "Target" field of the shortcut. I see that it ends in ...-nosplash -nomap" <- note that last quotation mark? Also, if there is one " in the beginning, remove that one too

You're adding -nomap to the wrong shortcut. Its the 1.92 beta that you should add it to. 1.91 doesn't recognize -nomap. Make a shortcut to the 1.92 beta .exe and edit it as follows: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> C:\Programs\OperationFlashpoint\FLASHPOINT192BETA.EXE -nosplash -nomap

Scanger, a tip: you can disable the splash screens by adding "-nosplash" (without the quotes) to the command line parameter list in the shortcut(s) to the game?. For example, like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> C:\Programs\OperationFlashpoint\FLASHPOINTRESISTANCE.EXE -nosplash Saves one the tampering with the core game files.

A couple of thoughts on your problems: <ul> [*] If OFP is running while you try to patch it, a similar error message will occur. Happened to me... [*] You need to have the original, untampered 1.91 exe installed. Other than that, unfortunately, it may be reinstall time, like suggested... Hope it helps.

Bug?: a -mod=... shortcut parameter part that is more than 80 characters long (including "-mod=") gives CTD when trying to create a MP game. Applies to: 1.92 beta, Windows client Description If I use a list of mod folders that make the "-mod=bla;bluh;bleh" part more than 80 characters long and try to start (host) a new MP game, OFP crashes to the desktop. Notes <ul> [*] A change in the total length of the command line does not affect the game, it's only the -mod parameter. [*] The total amount/size of addons seem to have no relevance. [*] Using the new "-nomap" on the shortcut makes no difference. A few examples... below are three different -mod parameters listed and they reference the same set of mod folders. I renamed the last one (nam2/namp2/nampa2) to show the problem. The last one is slightly too long, making the "-mod..." string exceed 80 character <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> -mod=mods/misc;mods/BAS;mods/DKM;mods/inf;mods/Fort;mods/KEG;mods/isl;mods/nam2 Â Â Â Â (79 chars - works) -mod=mods/misc;mods/BAS;mods/DKM;mods/inf;mods/Fort;mods/KEG;mods/isl;mods/namp2 Â Â Â Â (80 chars - works) -mod=mods/misc;mods/BAS;mods/DKM;mods/inf;mods/Fort;mods/KEG;mods/isl;mods/nampa2 Â Â Â (81 chars - gives CTDs) SP missions seem to be unaffected by this, i e the game loads the last mod folder (containing the SEB Nam Pack2 addons) and I can play 'nam missions fine. Trying to host a MP game, though, crashes OFP as soon as I klick "New" in the MP game browser. 1.91 is not affected by this. There, I can have long mod folder lists in my shortcut(s). Here's the last part of the flashpoint.rpt file after a "-mod parameter over 80 chars"-CTD: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> Mods: RES;mods/misc;mods/BAS;mods/DKM;mods/inf;mods/Fort;mods/KEG;mods/isl;mods/nampa2 ======================================================= Date: 08/23/03 Â Time: 01:44:53 ------------------------------------------------------- Exception code: C0000005 ACCESS_VIOLATION at 0058D892 Version 1.92 Fault address: Â 0058D892 01:0018C892 D:\Spel\OperationFlashpoint\FLASHPOINT192BETA.EXE file: Â Â intro world: Â Â intro Prev. code bytes: 0C 53 55 56 8B E9 8B 45 04 8B 75 00 83 C6 10 57 Fault code bytes: 8B 78 10 8B 46 08 3B F8 89 7C 24 18 7E 1D 8B C8 Registers: EAX:00000000 EBX:00000000 ECX:0012F6AC EDX:00000000 ESI:13D11640 EDI:0012F6E4 CS:EIP:001B:0058D892 SS:ESP:0023:0012F678 Â EBP:0012F6AC DS:0023 Â ES:0023 Â FS:0038 Â GS:0000 Flags:00010202 ======================================================= I'm unsure if this will help Suma and the guy's, but the crash is always at $0058D892. If the developers so need, I can mail in the whole .rpt file along with the context.bin and more info. *EDIT: Hmm...wonder if I should've posted this in the other 1.92 thread. Took placebo's note in that one as a "go" for doing it here but this thread is headed for the "my cat's breath smells like cat food"-category...

That script file, and a lot of others, is "embedded" into the bas_mah60.pbo addon file. That way, it is always available to you as long as you have the addon installed. Think of an addon as an archive, sort of like a ZIP file. An addon such as the Blackhawk has a lot of files in it, and to use them in your mission you refer to the scripts like in the example you provided. Somewhat simplified, one can say that the string "\BAS_mah60\FX\BAS_AIRope.sqs" is interpreted as "look inside the BAS_mah60 addon, in the FX sub-folder, for a script named BAS_AIRope.sqs".

Check the mouse settings in the control panel. Set the #6 button to "Middle Button". It is set to "Auto Scroll" per default. That solved it for me.

Can't confirm that. I have 512 MB DDR and the only programm that ever used 100% of it was mathlab which is really much more RAM demanding than OFP. Fair enough. Depends on how one uses OFP then, I guess. I regularly pass 800+ MB of memory usage for XP as a whole when playing certain OFP missions. Confirmed via the task manager and, in a slightly non-quantifiable way  by the sound of the disk chewing on the swap file. I do have a lot of addons in my many mod folders. This of course has a lot to do with it. A clean OFP:Resistance uses less memory and might be fine with 512 MB. Not enough for my use, though. Will be getting more soon.

Looking at what www.microland.co.uk has to offer, there are three things I'd change: * Get a i875-based board, like the Gigabyte 8KNXP. The E7205 is old hat. They're trying to sell old stuff to you. * Get 1 GB of RAM. OFP needs it. I have 512. I know. * Get the 800 FSB version of the P4.

What does it mean??? Mustn't I change the value from TEast to 0 for working on Linux??? Im not the best in english, plz explain again... What he means, I think, is this: within the config.cpp, the only usage of either the TEast or the TWest definition are a few places where "side=TWest" is used in place of "side=1". Also: TEast should be TEast=0, but the fact that it isn't doesn't matter, since the TEast definition is never used down below in the config.cpp The Windows version of OFP seems not to care/won't give an error if you have the same value of TEast and TWest, but the linux server does. And yes, you have to change the definition of TEast to 0 and re-pack the JAM pbo to make the linux server accept it. Hope that clears it up. *EDIT* Ok, took too long typing this - Evis cleared it up a few posts back. Sorry about the redundance.

If there is a problem, I don't think it has to do with that line. The bas_derad.pbo, for example, has this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> requiredAddons[] = {"BIS_Resistance","BAS_Weap"}; Mixed case and all, and it works fine on a linux deddy. Lee_H._Oswald: can you tell us if the linux server, when started with the JAM addon, prints out this, silently on a new line shortly after it starts?(there's a couple of lines with output before this) <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> JAM_Magazines Damn...I need a linux machine to do some digging on...

The Blackhawks are in a .rar-archive and not in one of those damned .exe-files. Good thing. Meaning: the virus cannot have come from the BAS .rar. Sorry to hear about your virus infection. Hope it won't happen again Hmmm...thinking of it... I too downloaded another addon pack from a "prominent addon maker". This one is in the infernal .exe format. Eeek...must go check. What virus/trojan was it, btw?

I guess what you need is a way to keep planes and helos from triggering and only have stuff on the ground do it. Hint: use the countType command. Something like <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> "Land" countType thislist > 0 or combinations of countType use and other condition expressions to filter out what you want. (The expression above is true when there are one or more land units (cars, people, tanks and so on) within a trigger area.)

Yep. Same with the MP version. Reason: the mission has Apaches in it and the bas_repairh addon has a bug. Furthermore, all missions using an AH64 will give you this error message if you have the bas_repairh in a folder other than the base OFP/Addons folder. The reason? That old classic of insufficient/missing requiredAddons... The bas_repairh contains a unit "bas_ah64_a" that has the BIS AH64 as a base class. Since the AH64 is an addon itself, the bas_repairh should have that declared in a requiredAddons[] in the CfgPatches part. If so, the problem will be fixed. How it looks now: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class BAS_repairH { Â Â Â Â Â Â Â Â Â Â Â Â Â units[] = {bas_repairH}; Â Â Â Â Â Â Â Â Â Â Â Â Â weapons[] = {}; Â Â Â Â Â Â Â Â Â Â Â Â Â requiredVersion = 1.90; }; How it should be: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class BAS_repairH { Â Â Â Â Â Â units[] = {bas_repairH}; Â Â Â Â Â Â weapons[] = {}; Â Â Â Â Â Â requiredVersion = 1.90; Â Â Â Â Â Â requiredAddons[]={ah64}; }; Or perhaps even <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class BAS_repairH { Â Â Â Â Â Â units[] = {bas_repairHW,bas_repairHE,bas_repairHR,bas_cobra_a,bas_ah64_a,bas_mi24_a,bas_mi17_a}; Â Â Â Â Â Â weapons[] = {}; Â Â Â Â Â Â requiredVersion = 1.90; Â Â Â Â Â Â requiredAddons[]={ah64}; }; (The latter seeing how there's actually no "bas_repairH" unit defined, but a lot of other units) Oh, also, for mission makers: the way the repair pad scripts are done, there will be only one working repair pad per side, even if you place more than one in the mission. Reason: the position of the repair pad is broadcasted in two public variables, and whatever pad gets "init:ed" last will get the last word on where repairs are done. Absolutely love the helos! :-) Wee! Back to playtesting...

Sweet. Tried it in "SP:ish mode", need *much* faster computer :-) (Currently: XP1900+). Then again, I tried to play with all 23 extra AI groups enabled. Won't do that again...lol. Couple of things: <ul> [*]Please consider using the 1.3 release of the F-18 [*]I see a lot of extremely tightly timed loops in some scripts. Waiting for 0.0001 secs in one place, IIRC. Try easing up on the timings. I did and I noticed some improvement in the CPU load. Not much though, but still... [*]As others noted, the balance/economy might need some adjustments. It quickly deteriorates to "Air Quake". [*] Sometimes (using an AI cmdr) the base gets positioned in a way that puts a building over a piece of road. This hinders the AI's driving. Consider moving some of the "near-a-road" base points a bit further out.

Oh yes - I'll second all of this. Now, what we need is a new island: How about a "Fulda Gap island" (preferably a 25,6x25,6 km island and not a puny normal sized island) so we can start creating a Fulda Gap scenario campaign, 80's style. (Fulda is a river some ways east of Frankfurt, near the old east-west border, if I'm not mistaken) Oh man, the ideas I have for that area... :-)

I'll cast my vote for this one, too. Let all event handlers (perhaps defined in an addon's config.cpp) be triggered on all machines, not only on the one where the unit is local. And while I'm at it, this would be useful: to be able to add eventhandlers in a config.cpp instead of overloading them over what's been defined higher up in the "vehicle tree". Example: Assume class LandVehichle has an init eventhandler "init1.sqs" As it is now: if I put a init eventhandler into, say, class Car (a LandVehicle), let's call it "init2.sqs", the first one defined in LandVehicle is overridden by the one in Car. It would be wonderful to be able to also add, not only replace, eventhandlers in the "children" of a base unit class. But, as BBSmith said, they are probably only concentrating on the "show stoppers". However, fixing/enhancing the event handlers would definitely be a part of (even if it might break a lot of the clever workarounds seen in some addons (CoC Network Services, Hudson's/Pennywise's F18 to name a few))

Results: 3934-4155, sits at 4054 at the moment AMD Athlon XP1900+ 512 MB PC2100 (DDR266) GF2 GTS 32 MB

Hi Scott. Sorry to hear about your problems. Here's my take on it: back in the days I too had a Asus K7M motherboard and had symptoms similar to yours - games crashing unexplicably. After much research I found the likely reason for my problems: the AMD751 chipset has a fluke/bug in its AGP handling that wasn't fixed until the C1 revision of that chipset. This revision wasn't out until late in the 751:s life, in the summer of 2000. By that time, most manufacturers had switched to the VIA KX133 chipset for their motherboard. Result: not too many K7M:s or other 751-based boards ever had the fixed chipet. I had my faulty board exchanged for a KX133 board that, unfortunately, had a VIA chipset and capacitors that leaked and died a year later (Abit, what'd you expect?) ... ;-) I could easily replicate the following using both windows 2k and linux, using three different AGP graphics cards: AGP set to x1 - all is well AGP set to x2 - random crashes So, my suggestion is that you try to lower the AGP transfer rate in the BIOS to x1 and see if that helps. My other guess on your problem is that the memory modules might be giving you trouble. That and the fact that you really need more memory for OFP. 512 MB is a good minimum, I'd say.

Lots of good suggestions here... a couple more: <ul>[*]Distributed global/side/group/vehicleChats (e.g a sideChat in a server script will be shown on all client machines) [*]Scripting support for complex datatypes ("structures"). Lists, hash tables, graphs and whatnot. [*]Access to world/island data through scripts. Town names, their respective neighbours, distance between them and so on. [*]getRank/setRank (In-game career?), get/setSide (changing sides and "affiliation") Above all, though: OFP is a distributed, real-time simulation. Make the scripting language work with that. Unambigously and *very* clearly documented.

My pet OFP vehicle physics peeves I hope will be different in OFP2: <ul>[*]Decceleration (braking). As it stands, the stopping distance of all vehicles is too long. Put in better brakes! [*]Steering. Ever run into a tree in a curve due to the steering ceasing to work when going above a certain (low) speed? [*]Engine power/feel. Like noted previously, all vehicles must be *much* better/faster at climbing slopes. [*] Steering radius. Prime example: taxiing aircraft. Oh, also, the aircraft flight modelling needs work, to say the least. Â

Look for "VIAHyperion4in1448.exe" on the computer. At the time of this writing, that is the latest version available on www.viaarena.com and probably the one you used.

First: the "VIA 686B Southbridge Data Corruption" issue is oooold and fixed. Does not apply to your motherboard or chipset. This, however, does not mean that VIA makes excellent chipsets... Also, VIAHardware changed its name to sudhian.com quite some time ago. Dunno why they did it, because the new name conveys absolutely nothing to me... Oh God no... Â Uninstalling the Hotfixes as a way to uninstall the 4in1 drivers is like uninstalling Office when trying to get rid of, say, Quake III from your computer. In other words: wont work, don't do it. If you really want to uninstall the 4in1:s, use the same program you used when installing it and it will give you the choice to uninstall all or some parts of the 4in1:s. Not that it should be needed on a correctly set up OS, however. Which brings me to... Installing XP 1: Check with Asus and get the latest BIOS for the motherboard. Check what has changed over the versions to see if there are any issues resolved by later versions. 2: Set the BIOS to 2x AGP and Fast Writes off, just for good measure. 3: Install XP on your computer and let it format your system partition ("C"). This to clear out any old demons like for example win9x or a non-working earlier XP install 4: After that, get your internet working. Do *not* install any drivers for your sound card or other cards yet. 5: Use Windows Update to get your XP patched up to SP1 and all the Hotfixes available. This will take forever and a million restarts. Get DirectX 9 on the box this way, too. 6: When you cannot find anything that Windows Update wants to update or anything extra you want (like Media Player 9 or things like that) it is "driver time". 7: Install the 4in1 drivers. Only install the AGP driver (4x mode) and the INF-thingie. Don't install the IDE driver (ok, you can, but you don't have to). Restart for the billonth time. 8: Install the latest drivers for your ATI card. Catalyst 3.5 I believe. At this point you could try installing OFP again on the now relatively pristine and clean XP. 9,10 and so on... get latest SBLive drivers, drivers for your TV card, Promise controller, C-media sound controller on-board (if enabled) and so on. 11. Hopefully live happily for a while If you still get grief from OFP it is time to suspect a hardware problem. Bad cables to the CD-reader? Also, some CD/DVD writer combos are known to cause problems with games using copy protection. Testing with another CD-ROM reader might be the solution.

Nope, the P4 is SP only. For two or more physical processors, you need Xeon processors (available at up to 3.06 GHz at this time, IIRC)