lukio

This is great news. Congratulations and thank you for all the effort, time and cooperation that went into this!

Your server is in your local LAN (192.168.0.168) The IP Google shows (78.21.184.124) is your visible IP from your router. What is happening is that for computers on your local area network, the server is internal, for clients connecting through the outside (did you enable UPNP?) the server IP is 78.21.184.124. If you want to play with friends on your local server, give them your current outside IP (some ISPs will reassign a new IP every 24 hours) to connect or invite them to your game via Steam.

After a routine restart of my my linux server I got the error Attempt to override final function - rscunitinfo_script 9:33:42 BattlEye initialization failed Server creation failed : 2302 First I was dumbfounded because ports are open and to my knowledge the port permissions have not been changed. After doing a little bit of searching I noticed that in the /<installdir>/battleye beserver.so was set to 0 bytes. So I downloaded the newest version of beserver.so from the BattleEye site, dumped it there and restarted the server. Immediately after server started running, the beserver.so got set from 277.160 bytes to 0 bytes. The file still remains Any information on how to remedy this? Server has been running fine for several weeks and we never had issues with BattleEye server not being initialized.

Problem solved, thank you!

Not really an option on some servers :-(

The whole part between finding a server and finding a regular unit to play with is completely missing. There is no way to find new members with in-game tools, everything is exterior and reliant on the good will of a few people who manage these lists. The Squad XML is a relict that is lacking any centralized database, search capabilities, "looking for unit" / "looking for members" functions or management features like inviting people to a unit.

Not really black & white - just as I said combined arms has it's limits. A small patrol boat or perhaps small / mid corvette can be useful, but needs to be employed with care. I do enjoy the ATLAS LHD as a staging ground, but thinking about ships like destroyers or battleships involved with combat would imo be overpowered. Same with deploying a AC-130 or other strong long-range artillery. To me a ship like the one you posted is great for launching an assault & staging platform, however I feel it's fire capacity already might have too much "Oomph". Fortunately every unit has it's own way of playing and using such assets, I'm just speaking in general that such firepower can be difficult to employ in a regular mission, just like artillery.

So currently diving can be used in the following mission types: - "Stealthy" Insertion / Exfil - Defusing underwater mines - Sabotage on boats / harbors - Retrieving / defending intel / assets on sunken wrecks or other POI - Rescue missions As long as we don't have structures on or under the water (like a oil rig, underwater base, frigate or tanker), there is no point on having pure underwater / naval missions. Most of the available, larger ships are used as a staging area for a mission, seldom are they actually involved in combat or fight against other ships. The ATLAS LHD has some defensive capabilities and will take out smaller craft and helicopters, which is nice - but imho employing it for attacking coastal enemy forces would be overkill. Just like with artillery or MLRS it's difficult to implement a fun mission (with infantry) with such overwhelming fire support. Combined arms in ARMA has it's limits, Can't find a link but basically think at the airstrike scene in "Jarhead" where he is about to take his shot and then they blow up the whole airport.

So we use a template for our init.sqf for our mission builders and somehow it doesn't for CSAT forces and I'm completely stumped why. #include "\task_force_radio\functions\common.sqf"; tf_give_personal_radio_to_regular_soldier = true; publicVariable "tf_give_personal_radio_to_regular_soldier"; tf_no_auto_long_range_radio = true; publicVariable "tf_no_auto_long_range_radio"; tf_give_microdagr_to_soldier = false; publicVariable "tf_give_microdagr_to_soldier"; tf_same_sw_frequencies_for_side = true; publicVariable "tf_same_sw_frequencies_for_side"; tf_same_lr_frequencies_for_side = true; publicVariable "tf_same_lr_frequencies_for_side"; _settingsSwWest = false call TFAR_fnc_generateSwSettings; _settingsSwWest set [2, ["311","312","313","314","315","316","317","318"]]; tf_freq_west = _settingsSwWest; publicVariable "tf_freq_west"; _settingsLRWest = false call TFAR_fnc_generateLRSettings; _settingsLRWest set [2, ["50","51","52","53","54","55","56","57","58"]]; tf_freq_west_lr = _settingsLRWest; publicVariable "tf_freq_west_lr"; _settingsSwEast = false call TFAR_fnc_generateSwSettings; // pre define the SW freqs _settingsSwEast set [2, ["210","211","212","213","214","215","216","217"]]; tf_freq_east = _settingsSwEast; publicVariable "tf_freq_east"; _settingsLREast = false call TFAR_fnc_generateLRSettings; // pre define the LR freqs _settingsLREast set [2, ["20","21","22","23","24","25","26","27","28"]]; tf_freq_east_lr = _settingsLREast; publicVariable "tf_freq_east_lr"; This is the code used, works fine for WEST, but not for EAST (CSAT) forces. This leads to radios and backpacks! being removed, even though teamleads should not be getting backpacks in the first place. Somehow it works (sporadically), but I'm still not sure that this is the right way to do this - any help would be appreciated.

Out of curiosity I tried out the latest (arma3server_performance_148_131820_v5_linux) perf build on Debian 7 and it segfaults, same with prior 1.48 PERF builds. Am I missing some additional files? Already renamed the Physx files to proper / original case. Arma 3 stable works fine, though.

Exactly - no Warlords missions appeared in the listing, but it seems that the mod was loaded correctly. This was on a dedicated linux / Debian server, mod dir was chmod 775 if that helps. On my local test machine (windows) it worked as per your screenshot.

So I've been using LEA Loadout manager for quite a while to setup loadouts to give me time to prepare the F3 assign gear component as decisions have been made and experience has been gathered. In the meantime I've got (almost) everything down and loadouts about 90% finalized. The only thing I am stumbling upon is that my CO/SL/FTLs have empty LR backpacks, because somehow somewhere the defined I've also noticed that the admin menu is not available although logged in as admin (on dedicated test server). C&P'd briefing.sqf and f_briefing_admin.sqf from orginal F3 files into the mission folder but that did not do anything. I've moved back to LEA loadout for loadouts as the F3 assigngear seems to have issues with respawning players. MFW I'm trying to make things work with F3 (complete SQf noob here). Anyway all issues have been resolved by adding: if (!f_var_JIP_GearMenu) then { if (typeName (_unit getVariable "f_var_assignGear") == typeName "") then { _loadout = (_unit getVariable "f_var_assignGear"); [_loadout,player] call f_fnc_assignGear; }; }; to f_JIP_playerRespawn.sqf. Now the only issue I have - but I do not believe this is F3 related (help is appreciated anyway) is the divers loadout, the player cannot access smoke grenades in the backpack and the SDAR weapon is undecided which ammo to use and thus needs to be reloaded with the appropriate ammo. I remember having this issue with other classes as well when grenades were only stored in the backpack, not in the vest or uniform. Due to the diver having no "vest" with storage space I figure that is the cause.

Perhaps it was not clear, but the warlords mod is running, yet none of the warlord missions are available for selection in the #missions window.

How do I get this to work on dedi server? Whenever I try to load #missions I get "Include file A3\JEZ_Warlords\cfgMissionParams.hpp not found." Do I need to extract the PBOs and dump the missions into MPMissions? "

Jungle: Play N'Ziwasago to get a feel for fighting enemies in the jungle. Turn enablesentences off. The AI reports often create more confusion than necessary if you move with your unit close knit and make regular stops to check for areas in the vicinity you should be good. Maritime: I am really hoping for more naval assets and a better maritime experience. The whole diving thing is only useful for sabotage or infiltration missions, nevertheless I'm hoping with Tanoa we will see a lot more of that.

Just wanted to drop in and say "Love your revive script". Best features we are enjoying: - The eject from vehicles setting - Loading wounded into vehicles - A nice, non clunky interface when unconscious GJ! (I know you can't do much about the carry animation, it works well enough to get people moved from A to B)

Yah I wasn't talking about the AI skill setting or their reaction, it's the type enemies /vehicles and amount that need to be tuned down. An 2 attack choppersor tanks are way more than we can handle.

I thought the JIP issues with the task module were fixed? Did you add a task state -> assigned module synced to the create task module? Also select "all playable units" or something, the groups of synced objects has some issues in MP.

When you say "on a dedicated server" - does that mean it works locally in the editor preview? What about using setpos or modelToWorld? There used to be something that houses would not communicate their position globally but I can't remember if that was in A2 or A3.

Is there any way to set the difficulty level? Just tested out the current release and with 1 player connected, difficulty is set to "Ultra", we usually play with 5-10 players so maybe fine tuning it a bit would be helpful. For example we do not always have AA or UAV capabilities, basicall its just basic infantry fireteam capabilities. I tried looking for a setting on the devheaven wiki but somehow did not find anything. Is there an admin menu or something?

Well I'll just hope that anyone else running it as MP mod on a linux server chimes in. Will fiddle around with permissions and checking the error logs. Did I already say thanks for this great AI mod? Anyway - thank you!

I believe I'm on to something but not sure how it is related to F3. So when we did a new test tonight, I went as admin into Zeus and noticed that all units were Blufor but after the first death / respawn they got changed to civilian side and from then on it did not work any more. The test mission is really basic, basically just one fireteam in Stratis airbase and some enemies set up in Agia Marina. This also would explain the behaviour that it works "sporadically" or only once. Afterwards we did a second test with F3 framework, but disabled simplewounding and set it to vanilla A3 system. So then when using Grimes Revive script (which works quite well) we experienced the same issue. I have no idea where to start looking what could be causing this. --- FOUND IT: Respawn has to be disabled in the description.ext with respawnButton = 0; If (undisciplined tester / players) respawned while "bleeding out", they would remain flagged as civs.

My (small-ish) group were doing a test with 3.3.0 and noticed this as well. Unfortunately it did not happen consistently. Most of the time, the first time someone revived someone it worked, after that you could throw as many FAKs at the downed person and nothing would happen and they'd eventually bleed out. We did the tests by shooting ourselves in the legs and also with combat against AI. Mods / scripts in use during the test: LEA Loadout editor script CBA3 TFAR (most current) ASR AI3 // F3 - Medical Systems Support // Credits: Please see the F3 online manual (http://www.ferstaberinde.com/f3/en/) // SWS Config Settings // How many extra FirstAidKits (FAKS) each player should receive when using the F3 Simple Wounding System: f_wound_extraFAK = 2; [] execVM "f\medical\medical_init.sqf"; // F3 - Medical Systems Support // Credits: Please see the F3 online manual (http://www.ferstaberinde.com/f3/en/) class f_param_medical { title = "Medical System"; values[] = {0,1,2}; texts[] = {"Arma 3 Default","F3 Simple Wounding System","Authentic Gameplay Mod"}; default = 1; code = "f_var_medical = %1"; }; No other issues encountered so far.

Hey I'm back with a further (albeit more technical question). As I posted a few days ago our group was quite satisfied with bcombat test and decided to use it on official server for a small event. Surprisingly none of bcombat's "shoeshine" was visible, actually behaviour was almost like vanilla AI. So after going through logfiles we noticed the following error message: @bcombat is in the main arma3 dir, not the seperate mods dir and it gets loaded correctly, ie. appears as bcombat AI mod v. 018 BETA and in server startup it appears with hash and has the correct path. So I know the following is true: bcombat is still in beta bcombat is aimed at SP Is it possible that this is an issue with the hard coded directory paths \ vs / as our test system was Windows, but the server is running Linux (mods running were CBA3 1.20, TFAR, RHS, AGM) If yes, then please tell me that this is something you may look into :) If not then I think it may be better to wait until this great AI mod gets the stamp of MP compatability approval.

Hey fabrizio, thanks for filling in some blanks and clearing up when and how Vanilla mode kicks in. We just did a small session tonight and it got very intense with the AI showing some unexpected and sneaky behaviour! Let it be known that your AI mod is making our small scale missions far more intense and enjoyable than they were ever before :-)