killswitch

Ok. FC2 it is. Do it like so:<ul>[*] Update your system using "yum -y update" (This will take some time to finish, might need a reboot.) [*] Install gcc: "yum -y install gcc" I will assume that you have your yum config set up OK, pointed to Fedora Legacy these days and that all pertinent keys have been imported. This forum is not the place to sort out Yum troubles and general system admining.

This thread will probably be locked due to the rule of don't dig up old threads, but you'll want to look here, Mr Mayhem: Operation Gulf War Crisis Public Beta Release EDIT: Crap, those links are hosed too...Oh well, I tried...

The first error tells us that you haven't got the GNU C/C++ compiler package installed on your machine. It is needed so the ofp server "install" script can compile a small program called "tolower".The second error comes from the script not being able to see that command, since it could not be compiled. :-) So, what you need to do is this: <span style='color:red'>Install gcc</span>. How you go about doing that depends on which variant, "distribution" of GNU/Linux that you are using. Tell us that and we'll be able to help you further.

Yep - copy all *.cpp and *.hpp files (four of them) from @wgl5/bin to the base ofp server folder, just like you do with the finmod/bin/config.cpp for FDF mod. WGL5 runs just fine on a Penguin OFP server. If you switch between mods, make sure you remove these *.cpp and *.hpp files when you stop the WGL5 server.

If you don't have those old libraries, then you don't have "all the required files". They are absolutely neccessary. Link broken, eh? Try this one: old libs

Setting up a proper binarize environment can be a real PITA... This suggests to me that binarize isn't actually set up alright, folders wise. I realise you said "All binarize files are in the same directory as the unpbo'd data dir's.", but let's just eliminate any ambiguitites in that statement. Assuming, as you say, that O:\ is the base folder where you have O2 and the folders mentioned installed, you should have binarize installed there too. That is to say that the following files and folders from the Breathe site "binarize.zip" should exist in O:\ <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> O:\binarize\ O:\binarize\bin\*.hpp (and *.cpp) O:\bin.bat O:\binarize.exe O:\exclude.txt O:\readme.txt Now, the binarize\bin\*.* files in that binarize.zip archive seemed old, so I replaced them with the ones from the archive Commented_Config_191.zip Sometimes and no. Upon getting texture errors, I go look for them and add them to my "binarize workplace". I've never had stringtable.csv errors though.Is it a publicly available addon/model so I can try binarize:ing it here?

If you read the first post, you'll notice a line saying Translated into english, that becomes and you'll notice there's a hyperlink in it, leading to a RAR archive. Download that file and in it you shall find the addon "mas_heliwep.pbo".Furthermore, as it says, you'll need JAM3.

Oh lovely... I plead old age The threads relevant to this addon should be updated to let people know the bug has been fixed. At least now everyone who is interested in config.cpp syntax bug hunting will know for sure and how to fix it themselves.

Thread resurrection for a good cause. I hope it's OK... The symptom On loading OFP with the SEF_Misc addon, you'll see this error message: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">'O:#': error unknown operatorThe SEF_Misc addon is used for the LAV addon in this thread and other addons by SEF such as the Humvee and the CH-53. The reason I've found the snag. It is indeed in the ammo definitions for SEF_AIM9 and SEF_AGM65 in it's config.cpp. The problem is this: <span style='color:red'>They both have colons (":") at the end of the "laserLock=false" lines instead of the proper semicolon ";"</span> The fix The file is config.cpp in SEF_Misc.pbo, version 1.0. On lines 526 and 552, change the trailing ":" to a semicolon, ";" and the problem goes away. I think this calls for a banana...

/Christer (a.k.a KeyCat) The documentation for the Kiowas doesn't tell you the complete set of addons it needs. Furthermore, the addon "fz_helipilots" is faulty - it doesn't properly declare it's dependency on Laser's US Weapons Pack. The "mas_m4" rifle can use magazines from that addon, hence the dependency. A corrected CfgPatches part for that addon is here: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches { class fz_helipilots { units[] = {fz_ah64d_plt,fz_ah64d_plt_d,fz_ah64d_plt_bdu,fz_ah64d_plt_bdu_d}; weapons[] = {mas_m9,mas_m4}; requiredVersion = 1.91; requiredAddons[] = {"BIS_Resistance","JAM_Magazines","LSR_uswp"}; }; }; Todo, for users and addon maker: <ul>[*] Fix "fz_helipilots" [*] Get Laser's US Weapons pack [*] Update the documentation to reflect this

They look fine. A slightly polished getin handler is below, where I <ul>[*] use a temporary variable "_gunner" so as to not call "gunner _vehicle" more than once. [*] don't use forEach in the addWeapon calls since there's just one weapon to add. [*] do the vehicle type check only once, since it occurs in all three mounted weapons sections. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_vehicle = _this select 0 ?!alive _vehicle:exit _type = typeof _vehicle #start ?!(_this select 1)=="gunner" : exit _gunner=gunner _vehicle ?isNull _gunner: exit ?(_type == "UKF_SnatchDES") : _vehicle setObjectTexture [5, "\UKF_Snatch\soft.pac"] ?(_type == "UKF_Snatch") : _vehicle setObjectTexture [5, "\UKF_Snatch\softg.pac"] _vehicle setObjectTexture [4, ""] #gunner ?(_gunner hasWeapon "ukf_sa80") : goto "sa80" ?(_gunner hasWeapon "ukf_sa80") : goto "sa80" ?(_gunner hasWeapon "ukf_sa80ag36") : goto "sa80" ?(_gunner hasWeapon "ukf_lsw") : goto "lsw" ?(_gunner hasWeapon "ukf_lmg") : goto "lmg" ?(_gunner hasWeapon "ukf_lmgsusat") : goto "lmg" #lmg ?local _vehicle: _vehicle addWeapon "ukf_min_mounted" _vehicle setObjectTexture [14, "\ukf_snatch\m249acc.pac"] _vehicle setObjectTexture [15, "\ukf_snatch\m249.pac"] _vehicle setObjectTexture [37, "\Data\black_sum.pac"] exit #lsw ?local _vehicle: _vehicle addWeapon "ukf_lsw_mounted" _vehicle setObjectTexture [25, "\ukf_ukweps\lsw\l86foregrip.pac"] _vehicle setObjectTexture [26, "\ukf_ukweps\lsw\lswbipod.pac"] _vehicle setObjectTexture [27, "\ukf_ukweps\lsw\lswblack.paa"] _vehicle setObjectTexture [28, "\ukf_ukweps\lsw\lswforegrip2.pac"] _vehicle setObjectTexture [29, "\ukf_ukweps\sa80\barreltrig.pac"] _vehicle setObjectTexture [30, "\ukf_ukweps\sa80\buttplate.pac"] _vehicle setObjectTexture [31, "\ukf_ukweps\sa80\cheek.pac"] _vehicle setObjectTexture [32, "\ukf_ukweps\sa80\pistolgrip.pac"] _vehicle setObjectTexture [33, "\ukf_ukweps\sa80\sa80_mag.paa"] _vehicle setObjectTexture [34, "\ukf_ukweps\sa80\sides.pac"] _vehicle setObjectTexture [35, "\ukf_ukweps\sa80\susat.pac"] _vehicle setObjectTexture [36, "\ukf_ukweps\sa80\susat2.pac"] _vehicle setObjectTexture [37, "\Data\black_sum.pac"] exit #sa80 ?local _vehicle: _vehicle addWeapon "UKF_sa80_Mounted" _vehicle setObjectTexture [16, "\ukf_ukweps\sa80\barreltrig.pac"] _vehicle setObjectTexture [17, "\ukf_ukweps\sa80\buttplate.pac"] _vehicle setObjectTexture [18, "\ukf_ukweps\sa80\cheek.pac"] _vehicle setObjectTexture [19, "\ukf_ukweps\sa80\foregrip.pac"] _vehicle setObjectTexture [20, "\ukf_ukweps\sa80\pistolgrip.pac"] _vehicle setObjectTexture [21, "\ukf_ukweps\sa80\sa80_mag.paa"] _vehicle setObjectTexture [22, "\ukf_ukweps\sa80\sides.pac"] _vehicle setObjectTexture [23, "\ukf_ukweps\sa80\susat.pac"] _vehicle setObjectTexture [24, "\ukf_ukweps\sa80\susat2.pac"] _vehicle setObjectTexture [37, "\Data\black_sum.pac"] exit No harm at all..

Yes, as the parameter type states (a string), you would do a string comparison:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?(_this select 1)=="gunner": hint "Welcome Mr Gunner" Yep. Funky animations as state variables are a neat idea...for SP. Actually, since animations don't "play" unless you look at them (with a few exceptions), they are kind of useless both in MP and SP. That means there's a lot of addons out there that will plain just not ever really work in MP. A shame, since they are so purdy. Doing it on either a getin or getout event is fine, since they are (AFAIK) broadcast. The one remaining hurdle is to signal a slew of setObjectTexture:s upon gunner meeting his maker... lemme think...

Oh my yes...that's the beauty of the getin/getout events - the second argument your EH gets is the position: The getin and getout events hand off the following arguments to an event handler in the "_this" variable: [ object: vehicle, string: position, object:: unit ] The second parameter is a string that is one of "driver", "gunner", "commander" or "cargo". Neat, huh? PS: On the custom animation suggestion - no go. Reason is that it will not work properly on dedicated servers. Why? The <span style='color:red'>animationState command is broken</span> too - when issued on dedicated servers it will always return the result 0, no matter what actual state the animation is in.

Mabye not - one could possibly use a/the getin event handler to add a killed event handler to the gunner to handle that particular case. The problem with that approach, though, is of course that the killed event is "BIS'd"...in other words - the killed event isn't broadcast, but is only issued on the machine where the gunner is local. Oh OFP... However, the killed event being limited in reach might not matter, in this case. I need to read the code closer... EDIT 2: Crap...upon gunner croaking, there are a number of setObjectTexture:s to be done (which need to be issued on all machines, not just the one where the gunner is local). Drats. Really, honestly...was the decision to make the killed event not be broadcast made on a Monday after a particulary tough weekend of bar hopping in Prague? One wonders... Oh OFP...

By "padding" I meant to have each line that issues either removeWeapon or addWeapon have a locality check, eg instead of <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">... #nogunner _vehicle removeWeapon "ukf_min_mounted" _vehicle removeweapon "UKF_sa80_Mounted" _vehicle removeweapon "UKF_lsw_Mounted" ...you'd have <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">... #nogunner ?local _vehicle: {_vehicle removeWeapon _x} forEach ["ukf_min_mounted","UKF_sa80_Mounted","UKF_lws_Mounted"] ...and similar locality checks elsewhere in the code, where applicable. On a more general note, I see that this script seems to be a constantly-running monitor script. That's a pre-1.85 CPU wastage offence of the Good OFP Coding Practices Bill and any such scripts should be taken out and shot until it's dead. Have you considered using the getin and getout events to trigger whatever it is that the above script does? Saves on precious CPU time, see. That's The Proper Thing To Do. Doing that won't solve the CTD issue until you've found the reason, but it's more than recommended to refactor the code to use OFP's event handler framework if at all possible.

A few things come to mind: * If this script runs on every machine in MP, it needs to have all addWeapon and removeWeapon calls "padded" one way or another so as to only issue those commands on one machine - the machine that vehicle is local to. I recall nasty crashes from issuing these indiscriminately in a MP situation. * Now, if the script doesn't run on every machine in MP, it should - setObjectTexture only has an effect on the machine it is issued on. * The random call will give a different result one every computer in MP, meaning that <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">?_rnd < 50 : goto "lsw"will have each instance of the script choosing it's own execution path when running.

That sounds like it comes from KaRRiLLioN's RTS-3, possibly in the RTS3 Core addon available on that page or here. The tag "MTY" is/was used by a fellow calling himself "Martin", so if you go look around for his addons, you might find something among these.

The latter - you only change the position of an entity on the machine said entity is local to. In your case it means - alter the positions only on the server.

You Sir, are a pearl! Thank you and Merry Christmas and all that

You have two "=":s in there somewhere. You might need to change <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">OFP_DIR==/home/ddk/ofpto<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">OFP_DIR=/home/ddk/ofpTo train you in logical thinking and basic problem solving, there's one other place where the extra "=" could be. Seeing as how line 30 references the environment variable "RUNFILE", where could that possibly be? Good grief, this is getting ridiculous. Gimme an account on the bloody machine and I'll have the OFP server running in under 10 seconds (system time).

Jumping eh? I'm...concerned. However, as a way to overcome small obstacles or perhaps skip over small walls, I'd appreciate the ability to do "jumplets" :-)

Could it be that you have somehow gotten the start script infected with DOS-style line endings, say by editing the file ofpstart with Notepad in Windows? That's an excellent way to cock up a script... The solution? Fix it using "dos2unix" from the package...yep, you guessed it, "dos2unix":<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">dos2unix ofpstartshould do it. That program will convert DOS-style line endings to Unix ones. If you haven't got dos2unix, install it by <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">yum -y install dos2unix

It looks like you've botched the start script. The very first line of that script must be exactly this:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#!/bin/bash Also, are you really quoting me the full error message there? It seems that you take great care to edit away parts of the command prompt (which looks like "[user@somewhere ofp]$" in a normal bash shell. If you do this for security reasons, I'm perfectly fine with that. I don't need to know what the prompt says, nor does anyone else. I just suspect there are parts missing from the line that reads ": bad interpreter: No such file or directory"... Ok. You use FC2. That's good because I know that the ofp server runs just fine on it.

Thanks. Except for two things, everything looks OK:<ul>[*] You've put the ofp server in the /var filesystem/tree. That's sort of like installing programs into C:\WINDOWS\TEMP in Windows... [*] You shouldn't run the ofp server process as root. Ever. Following proper practices, you would: <ul>[*] Install third-party programs such as the OFP server into /opt (eg /opt/ofp) or /home/<some user> [*] Create a new user, <some user>, that will run the ofp server (say "ofps", "ofp_server" or whatever suits your fancy) While those things are how it ought to be done, they won't solve the problem at hand. As far as I can tell, starting the server using "./ofpserver start" with your current setup should...well, work. I'd look into the other points benu mentioned - ie making sure your network configuration is setup alright - proper hostname, /etc/resolv.conf, /etc/hosts and possibly install and run the nscd service. What distribution are you running? Perhaps someone out there in OFP land has experience in running the OFP server on just that distribution.

i have already did it, but again:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Segmentation fault Are you sure? Seeing as how you've had trouble understanding benu's howto before in this thread, let's just make certain. Tell me this:<ul>[*] Where is your ofp server installed? (exact path) [*] Where are those extra libraries you downloaded installed (exact path) [*] List the contents of both the base ofp server folder and the folder with the libs [*] Show me the output of "grep LD_LIBRARY_PATH ofpserver", issued when standing in the base ofp server folder as written in manualor <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">ofpserver startas written there ? Think about that for a second. After having gone through the trouble of editing "the ofp <span style='color:green'>start script</span>, 'ofpserver'", what would be your guess of how you would <span style='color:green'>start</span> the ofp server? (Hint: it's not "./server")