dwringer

Who knows why people do what they do. The fact remains that the series has shown a constant improvement in usability just as you describe. Not only that, but the modding community has created DOZENS of FANTASTIC tools for editing game content. You also have to realize at some point that this is a civilian product derived from a professional military product. They will not spoon feed everything to you; it would be arguably in bad taste to do so. And the community seems as user-friendly as the game, you get back what you put in. The more you learn about it, the simpler it will all seem, and you will see that any layer of superficial simplicity would strip vast amounts of potential.

LOL, well it took me years to fully grasp but in fact, you can really do anything from inside the editor if you want to. It's just a matter of learning the syntax and how all the different things like triggers, waypoints, game logics, namespaces, etc work in the engine. It just happens to be every bit as complicated as learning any other mature, commercialized programming environment. Which it is :P

You can place a Game Logic object on the building in the editor, and in its on act do something like "bldgToBurn = nearestBuilding this". Now the building should be named 'bldgToBurn' and will respond to scripting.

Been experimenting with the same thing myself, and I don't really have much to report other than that it does indeed seem to be nonfunctional. I have tested: setOvercast : not working setRainbow : sets variable but cannot demonstrate effect? setLightnings : sets variable but cannot demonstrate effect? setWindForce : unknown, does appear to be working setWaves : appears to be working setWindStr : works, but must set wind to Manual in editor setGusts : works, but must set wind to Manual in editor setRain : working setFog : working setWindDir : working it is odd because in the BIS functions, there is an a3>ModuleEvents>BIS_fnc_weatherModule script which appears to utilize these very functions; I presume it is a component of the weather module or intended to be used with the weather module. Regardless, I cannot get the module or the function to change the non-working parameters at all.

Hello, I have been working on this script for over a year and only recently made the breakthrough allowing it to work effectively on entire groups rather than single units, so I decided to release it here. Hopefully there are not too many bugs. /* Arma 3 Dismissed Unit Bounding Script Stops "DISMISSED" units from moving beyond a certain radius. Reinitializes the unit/group. Break by adding "hasRebelled" flag to leader's namespace. Not tested for MP. Updated: 9 March 2013 Author: dwringer Arguments: [leader, radius] */ private ["_man", "_distMax", "_distRet", "_posStart", "_tx", "_ty", "_td", "_distCurr", "_grpOld", "_grpNew", "_wptReturn", "_wptDismiss"]; _man = _this select 0; _distMax = _this select 1; _distRet = _distMax * 0.85; _posStart = getPos _man; _man setVariable ["hasRebelled", false]; sleep random 5; while {!(_man getVariable "hasRebelled")} do { _grpOld = group _man; _distCurr = 0; {_tx = (position _x select 0) - (_posStart select 0); _ty = (position _x select 1) - (_posStart select 1); _td = sqrt ((_tx * _tx) + (_ty * _ty)); _distCurr = _distCurr max _td;} forEach units _grpOld; if (_distCurr >= _distMax) then { _grpNew = createGroup (side _man); _wptReturn = _grpNew addWaypoint [_posStart, 0]; _wptReturn setWaypointType "MOVE"; _wptReturn setWaypointSpeed "LIMITED"; _wptReturn setWaypointCompletionRadius _distRet; _wptDismiss = _grpNew addWaypoint [waypointPosition _wptReturn, 0]; _wptDismiss setWaypointType "DISMISS"; _wptDismiss setWaypointSpeed "NORMAL"; _wptDismiss setWaypointCompletionRadius _distRet; _grpNew setCurrentWaypoint _wptReturn; {[_x] join _grpNew} forEach units (group _man); deleteGroup _grpOld; }; sleep 45; }; Usage is simple: Save the script to an .sqf file such as "wrangle.sqf". Call with _nil = [groupLeader, radius] execVM "wrangle.sqf" For example: Place a group of civilians in the editor. Give them an initial waypoint of "DISMISSED", right where they are. In the leader's Initialization: field, put: _l = [this, 100] execVM "wrangle.sqf" Now preview the mission. The group of civilians will wander about aimlessly until one of them gets 100m from the group's starting location. At this point, you should see the group coalesce and reconverge at their initial starting position. Hopefully this works okay for people. The AI in "DISMISSED" mode is very dodgy, but this mitigates the worst effect (the endless roaming) in exchange for groups that frequently like to reconvene.

try: opfor_patrolFnc = { _n = _this select 0; _marker = _this select 1; _side = _this select 2; _mingroupSize = _this select 3; _chance = _this select 4; _dist = _this select 5; _units = ["O_Soldier_SL_F","O_Soldier_TL_F","O_Soldier_F","O_Soldier_AR_F","O_Soldier_GL_F","O_soldier_M_F","O_Soldier__F","O_Soldier_AR_F","O_Soldier_GL_F","O_Soldier_LAT_F","O_medic_F","O_soldier_exp_F"]; for "_i" from 0 to _n do { _grp = [getMarkerPos _marker, _side, _units,[],[],[],[],[_mingroupSize,_chance],0] call BIS_fnc_spawnGroup; [_grp, getMarkerPos _marker,_dist] call bis_fnc_taskPatrol; }; }; Not tested but hopefully that helps. see also http://community.bistudio.com/wiki/Control_Structures#for-from-to-Loop :)

First, in your player's init line, your init.sqf, or any other init field you want really, put something like "dsarf = false;" just to initialize it. Make the condition in your trigger be simply "dsarf" (the 'true' is implicit by what is returned from the variable). Then the line "dsarf = true;" should be all that's necessary to fire it. EDIT: to be more precise, "true=dsarf" is wrong, that's an assignment to "true" of the value "dsarf", which fails because true is a universal value. To be more accurate you could do "true == dsarf" or "dsarf == true" but this is redundant.

They will execute sequentially if they're both in a single thread, i.e. running from a single .sqf. You can run multiple scripts in parallel on a single machine, and use globalVariables on that machine to do this, but multiple scripts on multiple machines have to wait for the engine to get around to doing it's publicVariable updates, which I don't believe have any guarantee of speed. Edit: Global variables on a single machine are, erm, global, so do not need to be broadcast whatsoever with publicVariable. Edit 2: Was thinking about this, and perhaps an approach might be to add a global variable that, for instance, will only let the first thread go into its loop if set to 0, and only let the second thread do it if set to 1 <enforce with waitUntil>, and then have each thread adjust that variable to allow the other thread to continue when the time is right. I don't exactly know, I have never done much concurrency to begin with and certainly not on the RV engine ;)

I think you can just give the squad a "GET IN" waypoint, give the helicopter a "LOAD" waypoint, and synchronize the two. However, the helicopter may not actually go to the ground until your squad gets to it, and it might run around trying to land next to your squad rather than at the assigned pad. What i would in a situation like this is basically do a setFuel on the helicopter to 0 so it won't go anywhere. Then, make a trigger that won't go off until the squad is fully loaded (the count of units matching the condition of not being in the vehicle should be 0). Make the trigger add fuel and it should be able to take off. You might have to change the trigger condition instead to simply wait for the squad to be within a certain proximity; I'm not sure how the AI works when telling people to get in vehicles that have zero fuel. :) Good luck; hope that helps. EDIT: Actually you can just add an extra "MOVE" waypoint for the squad just before their "GET IN", and put the refueling call into the helicopter's "LOAD" waypoint's "On Act." field, which should ensure the helicopter gets fuel as soon as the infantry squad arrives, but the helicopter won't have fuel until such time as the squad was already ordered/flagged to be ordered into the helicopter.

If you guys want something that works in multiplayer, and I am saying this VERY cautiously as I have not tested it myself, there are actually specific commands called "addWeaponCargoGlobal" etc. You simply make the script run only on the server, and then use the global commands. AFAIK this is effective, modeled after a script somebody else had used. Click this spoiler to see the version I mean (does not use config files, but instead uses manually typed lists of items): <The classname aggregation was done by Pzar, and the multiplayer aspect by Riouken> To use, save as box_filler.sqf in the mission dir and then in the init field of the box, put : _handle = [this] execVM "box_filler.sqf"; ;; creates a box with default numbers of everything (50 items, 200 ammo, no bags). refill loops with a default cycle of 500s. _handle = [this, 5] ;; uses default qty's, but 5 of each bag. no loop. _handle = [this, 0, 5] ;; uses default qty's, but 5 of each special item. no loop. . . . _handle = [this, A, B, C, D, E]; <-where A,B,C,D,E are integers, spawns a crate with A of each bag, B of each item, C of each mod/attachment, D of each weapon type, and E magazines. no loop.

The position it seems to be referencing is the line that says: _box = _this select 0; Are you still calling the script with _fill = [this] execVM "crate_filler.sqf"; from within the crate's init field? I have copy-pasted it just now and tested it, and examined my arma.rpt thoroughly, but I do not see or encounter errors. Or perhaps this is an issue with something in my code being run on the server that I failed to comprehend? I have only been able to test it locally, but the line of code that you're getting an error from is identical to the one in the OP except i changed the word "_crate" to "_box". EDIT: I reproduced something similar to your error in my .rpt by calling it without brackets around "this". This is what i got: So just make sure you're using brackets ;) If that's really not the issue, then I apologize :!

That weapon may not work but this one will: "R_60mm_HE" Might not really be a big enough explosion, but you can repeat the line multiple times or just say something like: _bomb = for "_i" from 1 to 3 do {"R_60mm_HE" createVehicle (getPos ied);}; ...which will make three of them explode at once. Check the sticky at the top for classnames and find Sickboy's post on that thread for more ammo types that you could potentially try using.

Hey man, this is really great stuff, I confess I am pretty clueless about MP scripting. However, I have combined your script with the other info I have found online thus far, and made some changes that should enable this thing to be very easily expanded as the classes in-game are changed. I went through the classnames alongside those in a post from another forum by Pzar, and there are a couple others in this one. If you like, feel free to use this script and take all the credit for yourself. When called like your script, afaik it functions identically. Sorry if there are bugs :) /* Arma 3 Weapon Crate Filler MP Compatible. Loops when using default quantities. Does not loop with optional args set. Updated: 7 March 2013 Authors: Riouken Pzar dwringer Arguments: [box (&optional numBag numItem numMod numWeapon numAmmo)] */ if (!isServer) exitWith {}; ///init private ["_box", "_loop", "_wait", "_numWeapon", "_numAmmo", "_numMod", "_numItem", "_numBag", "_natoWeapons", "_opforWeapons", "_launchers", "_oculars", "_cartAmmo", "_launcherAmmo", "_glAmmo", "_manAmmo", "_attachments", "_items", "_hats", "_dress", "_chest", "_backpacks"]; _box = _this select 0; _loop = true; // Defaults: _wait = 500; _numBag = 0; _numItem = 50; _numMod = 50; _numWeapon = 50; _numAmmo = 200; switch (count _this) do { case 2 : { _numBag = _this select 1;}; case 3 : { _numBag = _this select 1; _numItem = _this select 2;}; case 4 : { _numBag = _this select 1; _numItem = _this select 2; _numMod = _this select 3;}; case 5 : { _numBag = _this select 1; _numItem = _this select 2; _numMod = _this select 3; _numWeapon = _this select 4;}; case 6 : { _numBag = _this select 1; _numItem = _this select 2; _numMod = _this select 3; _numWeapon = _this select 4; _numAmmo = _this select 5;};}; _natoWeapons = [ "arifle_MX_F", "arifle_MX_GL_F", "arifle_MX_SW_F", "arifle_MXC_F", "arifle_MXM_F", "arifle_SDAR_F", "arifle_TRG20_F", "arifle_TRG21_F", "arifle_TRG21_GL_F", "hgun_P07_F", "LMG_Mk200_F", "srifle_EBR_F" ]; _opforWeapons = [ "arifle_Khaybar_C_F", "arifle_Khaybar_F", "arifle_Khaybar_GL_F", "hgun_Rook40_F" ]; _launchers = [ "launch_NLAW_F", "launch_RPG32_F" ]; _oculars = [ "Binocular" ]; _cartAmmo = [ "30Rnd_65x39_caseless_green", "30Rnd_65x39_caseless_green_mag_Tracer", "30Rnd_65x39_caseless_mag", "30Rnd_65x39_caseless_mag_Tracer", "100Rnd_65x39_caseless_mag", "100Rnd_65x39_caseless_mag_Tracer", "20Rnd_762x45_mag", "20Rnd_556x45_UW_mag", "30Rnd_556x45_Stanag", "30Rnd_65x39_case_mag", "30Rnd_65x39_case_mag_Tracer", "16Rnd_9x21_Mag", "30Rnd_9x21_Mag", "200Rnd_65x39_cased_box", "200Rnd_65x39_cased_box_Tracer" ]; _launcherAmmo = [ "NLAW_F", "RPG32_F", "RPG32_AA_F" ]; _glAmmo = [ "1Rnd_HE_Grenade_shell", "UGL_FlareWhite_F", "UGL_FlareGreen_F", "UGL_FlareRed_F", "UGL_FlareYellow_F", "UGL_FlareCIR_F", "1Rnd_Smoke_Grenade_shell", "1Rnd_SmokeRed_Grenade_shell", "1Rnd_SmokeGreen_Grenade_shell", "1Rnd_SmokeYellow_Grenade_shell", "1Rnd_SmokePurple_Grenade_shell", "1Rnd_SmokeBlue_Grenade_shell", "1Rnd_SmokeOrange_Grenade_shell", "3Rnd_HE_Grenade_shell", "3Rnd_UGL_FlareWhite_F", "3Rnd_UGL_FlareGreen_F", "3Rnd_UGL_FlareRed_F", "3Rnd_UGL_FlareYellow_F", "3Rnd_UGL_FlareCIR_F", "3Rnd_Smoke_Grenade_shell", "3Rnd_SmokeRed_Grenade_shell", "3Rnd_SmokeGreen_Grenade_shell", "3Rnd_SmokeYellow_Grenade_shell", "3Rnd_SmokePurple_Grenade_shell", "3Rnd_SmokeBlue_Grenade_shell", "3Rnd_SmokeOrange_Grenade_shell" ]; // Omitted FlareGreen_F, FlareRed_F, FlareWhite_F, FlareYellow_F, because while they -do- work // and load up, I was unable to find a launcher for these ones yet. _manAmmo = [ "APERSBoundingMine_Range_Mag", "APERSMine_Range_Mag", "ATMine_Range_Mag", "Chemlight_blue", "Chemlight_green", "Chemlight_red", "Chemlight_yellow", "ClaymoreDirectionalMine_Remote_Mag", "DemoCharge_Remote_Mag", "HandGrenade", "HandGrenade_Stone", "MiniGrenade", "SatchelCharge_Remote_Mag", "SLAMDirectionalMine_Wire_Mag", "SmokeShell", "SmokeShellBlue", "SmokeShellGreen", "SmokeShellOrange", "SmokeShellPurple", "SmokeShellRed", "SmokeShellYellow" ]; _attachments = [ "acc_flashlight", "acc_pointer_IR", "muzzle_snds_B", "muzzle_snds_H", "muzzle_snds_H_MG", "muzzle_snds_L", "optic_Aco", "optic_ACO_grn", "optic_Arco", "optic_Hamr", "optic_Holosight" ]; // (I omitted Zasleh2 because it comes up as a blank box for me) _items = [ "FirstAidKit", "ItemCompass", "ItemGPS", "ItemMap", "ItemRadio", "ItemWatch", "Medikit", "MineDetector", "NVGoggles", "ToolKit" ]; _hats = [ "H_Cap_blu", "H_Cap_brn_SERO", "H_Cap_headphones", "H_Cap_red", "H_HelmetB", "H_HelmetB_light", "H_HelmetB_paint", "H_HelmetO_ocamo", "H_MilCap_mcamo", "H_MilCap_ocamo", "H_PilotHelmetHeli_B", "H_PilotHelmetHeli_O" ]; // (left the booniehats out due to no textures) _dress = [ "U_B_CombatUniform_mcam", "U_B_CombatUniform_mcam_tshirt", "U_B_CombatUniform_mcam_vest", "U_B_HeliPilotCoveralls", "U_B_Wetsuit", "U_BasicBody", "U_C_Commoner1_1", "U_C_Commoner1_2", "U_C_Commoner1_3", "U_C_Poloshirt_blue", "U_C_Poloshirt_burgundy", "U_C_Poloshirt_redwhite", "U_C_Poloshirt_salmon", "U_C_Poloshirt_stripped", "U_C_Poloshirt_tricolour", "U_OI_CombatUniform_ocamo", "U_OI_PilotCoveralls", "U_OI_Wetsuit" // "U_Rangemaster" ]; // (Note you can only wear your faction's clothing, and I'm not sure // who can even wear rangemaster, so it is commented out) _chest = [ "V_BandollierB_cbr", "V_BandollierB_khk", "V_BandollierB_rgr", "V_Chestrig_khk", "V_ChestrigB_rgr", "V_HarnessO_brn", "V_HarnessOGL_brn", "V_PlateCarrier1_cbr", "V_PlateCarrier1_rgr", "V_PlateCarrier2_rgr", "V_PlateCarrierGL_rgr", "V_Rangemaster_belt", "V_RebreatherB", "V_RebreatherIR", "V_TacVest_brn", "V_TacVest_khk", "V_TacVest_oli" ]; _backpacks = [ "B_AssaultPack_Base", "B_AssaultPack_blk", "B_AssaultPack_blk_DiverExp", "B_AssaultPack_blk_DiverTL", "B_AssaultPack_cbr", "B_AssaultPack_dgtl", "B_AssaultPack_khk", "B_AssaultPack_khk_holder", "B_AssaultPack_mcamo", "B_AssaultPack_ocamo", "B_AssaultPack_rgr", "B_AssaultPack_rgr_Medic", "B_AssaultPack_rgr_Repair", "B_AssaultPack_sgg", "B_Bergen_Base", "B_Bergen_sgg", "B_Bergen_sgg_Exp", "B_Carryall_Base", "B_Carryall_ocamo", "B_Carryall_oucamo", "B_Carryall_oucamo_Exp", "B_FieldPack_Base", "B_FieldPack_blk", "B_FieldPack_blk_DiverExp", "B_FieldPack_blk_DiverTL", "B_FieldPack_cbr", "B_FieldPack_cbr_AT", "B_FieldPack_cbr_Repair", "B_FieldPack_ocamo", "B_FieldPack_ocamo_Medic", "B_FieldPack_oucamo", "B_Kitbag_Base", "B_Kitbag_cbr", "B_Kitbag_mcamo", "B_Kitbag_sgg", "Bag_Base" ]; // (B_Mk6, B_Mk6Mortar_Support, B_Mk6Mortar_Wpn, and Weapon_Bag_Base omitted due to acting funny, also note // that the *_Medic *_AT etc bags come with stuff in them, and who doesn't like free stuff. Also, *_Base just // comes up as a generic bag, but it does work) ///run while {_loop && (alive _box)} do { clearMagazineCargo _box; clearWeaponCargo _box; clearItemCargoGlobal _box; {_box addWeaponCargoGlobal [_x, _numWeapon];} forEach (_natoWeapons + _opforWeapons + _launchers + _oculars); {_box addMagazineCargoGlobal [_x, _numAmmo];} forEach (_cartAmmo + _launcherAmmo + _glAmmo + _manAmmo); {_box addItemCargoGlobal [_x, _numMod];} forEach (_attachments); {_box addItemCargoGlobal [_x, _numItem];} forEach (_items + _hats + _dress + _chest); {_box addBackpackCargoGlobal [_x, _numBag];} forEach (_backpacks); if ((count _this) > 1) then { _loop = false;} else { sleep _wait;}; }; // Also Glasses, I could not get these into a box, so you have to set them on something (or more correctly, // someone!) with a glasses/goggles slot, this also overrides any they have set in preferences, and // interestingly enough, none is implemented as an object, instead of just deleting them: //this addGoggles "G_Diving"; //this addGoggles "G_Shades_Black"; //this addGoggles "G_Shades_Blue"; //this addGoggles "G_Sport_Blackred"; //this addGoggles "G_Tatical_Clear"; //this addGoggles "None";

That's nonsense; I get 6 core utilization, and most of them stay around 50% but are by no means capped at 50%. How does seeing 4 cores in use imply only 2 cores being used properly? It implies 4 cores are being used, no more and no less. As I said, mine uses six with no issues. The OS also reports additional CPU's to represent the hyperthreading - essentially, an extra set of registers for the cores - being used to a limited extent. Also, the game does not operate well when it is using a CPU to 100%. Your goal should never be to use 100% of a CPU if you're simulating a system as dynamic as this one. There is ALWAYS more calculating that the engine could be doing. But here's a fun example. Load up an Arma game on a pc with an insufficient CPU. Get a machine gun. Try to scientifically determine the rate-of-fire for your weapon. If your cpu is being stressed, it's going to be highly variable because the engine has to make so many compromises in what it decides to compute when that it can't keep up.

Assuming you've got a legitimate version of the game, I'd say it may just be that you're overtorquing the engines. This would especially be the case if you notice it most prominently on the Medium, and least on the Light. Keep an eye on the Torque indicator if you have instruments enabled, and/or try to keep the torque needles from getting too high if you are using the virtual cockpit. That's my only suggestion really, since you said maneuvering works fine.

Happens to everyone afaik. BIS will also not provide support, afaik, except perhaps to disprove this line of my post. You should, however, be able to search the forums for this issue for several fixes that have worked for people. I think it basically comes down to opening your [c:\program files (x86)?]\steam\steamapps\common\take on helicopters\ folder, and looking around for the Take on Hinds installer (I think it's an .exe file in there or a well-labeled subdirectory). Run that installer "As Administrator" by right clicking on it and, if given the option, selecting it, or if not, clicking properties, going to the compatibility tab, and then selecting "Run as Administrator". Also, I don't mean to come off as too negative toward BIS lately, even though that's what happened in my last couple of posts. I just think this product is sorely undersupported. Unfortunately their entire company is probably going through some tough times right now with the [REDACTED].

Well no, I understand the complexities involved and I dont expect it to be always simple. There are so many different distributions of each product involved, I would never expect them to even be as compatible as they are, really. The issue to me seems that if somebody buys all the products together on Steam, for example, they don't seem to work together out-of-the-box. This may seem like a minor point, but to me it is the biggest issue because Steam is probably the biggest single content-delivery platform. Whether the products being on Steam at all is just a 'courtesy' is debatable. I know a lot of people don't like the system. I actually bought Arma twice just to have a copy on Steam, though, and have done so with a couple of other titles too. My own opinions are not necessarily shared by many, but I just wanted to be clear. I don't want to come across as too critical, I know how complicated it is just by how many different situations pop up here on the forums and how little idea I have as to how they could be resolved. PS Frankly the only issues I had were in getting the TOH DLC's to work, my Rearmed experience was as smooth as it gets, and that's with Steam versions of everything. However, I had some directory junctions in place already so I recognize that everyone who plays anything but vanilla has a very unique installation of the system.

Despite the impression you may get, nobody that I'm aware of got everything working as such "out of the box". kju has been giving people assistance in this kind of thread ever since the last patch. Some of us got things working, most probably gave up and stopped coming back to the forum. I hate to sound cynical but as far as I see it, that's how it is. The core fan base for this game seems to consist of about 10 people. EDIT: also, I've noticed no comment on my last post... afaik the game itself supports setting the order from within the Expansions menu.

Not sure if this is a solution as I havent COMPLETELY tested it but, the ingame Expansions menu actually allows you to select each (not the core game files, though) and click Up or Down to reorder them. I for one hate using third party apps except when it's prohibitive not to (ie when joining multiplayer games to sync mods, etc), and this should be a fix that doesn't require any, that also doesn't require .cfg editing. Of course editing the .cfg is probably not such a bad idea either.

If you have any complaints about the flight model (or any physics in ANY sim, tbh), I highly suggest leaving the difficulty on Veteran or Expert. If your joystick truly is well-calibrated, check the rudder. If you have a twist-rudder stick like I do, there's a very good chance the potentiometer (the piece that detects left/right twisting) inside is full of metal shavings, dirt, ash, congealed pieces of substandard lubricants, who knows what. I don't know what the factory conditions must be like where they make these things but afaik every single one in the world has this problem. No exaggeration ;) This will internally cause impedance problems or something (I know nothing about electrical engineering) and lead to a rudder that is jerky. A way to get an idea of whether this is happening is by getting in a light chopper, looking at your feet, and twisting back and forth. Your feet should not be moving on the pedals except during the twist-phase of what you're doing, and it should be a slow, deliberate measured move. If you see the guy's feet jerking left and right, acting 'touchy', or in any way not matching EXACTLY the motion of your hand, you are suffering from this problem. The only real solution of which I am aware- and the one which has worked flawlessly for me - is to open up your joystick to gain access to the potentiometer and spray some TV Tuner/Electrical Contact Cleaner/Lubricant into it. You can get it at radio shack, make SURE you get the kind designed for TV tuners that cleans AND lubricates. Just stick the nozzle into a gap on the side of the potentiometer and give it a single spray. Let the propellants evaporate from the area, work the joystick back and forth a few times, and then plug her in. If you were successful, the joystick should operate better than when it was brand new. If this isn't your issue, then I'm at a loss. The problems you're describing are not inherent to the sim but indicative of some other error.

Thanks for the support, hopefully you aren't expecting a very finished product ;) I have done some more updates, removing the copy/pasted houses and adding more 'essential' landmarks, as well as interstate highway bridges. Also I made a rudimentary improvement to the layer mask so there are some paved areas, although it's pretty shoddy atm. Download is available as soon as the link becomes active again, which should be just a few minutes after this post appears. EDIT: Sorry, I think I actually broke the map with that revision by linking to textures in a path to a different map on my tools drive... fixed in the latest, and should be working now.

Hello everyone, I have been working on a terrain for the last couple of weeks, and initially was using nothing but Arma2 assets and a buldozer.exe copied from my A2OA executable (and \bin folder supplemented with extracted bin.pbo from my a2oa directory). Everything worked exactly like I would expected it to, and the terrain rendered just fine in Arma 2. When I loaded the map in Take On Helicopters: Rearmed, however, I noticed that the satellite texture had some segments overlapping around the edges of the terrain (only the last one or two segments per side on a 31x31 segment (12288km)^2 map). I can set up buldozer.exe from my TakeOn-H.exe and the bin.pbo -> \bin files from TOH in Visitor and edit using TOH assets, but when I do that buldozer shows me the same texture issues around the terrain borders. Is there a config setting I need to be adjusting where the default has changed from Arma2 that controls this type of behavior? Or is there something about the mask import process that needs to be modified to alleviate this? I have also encountered a secondary issue. Granted, I'm not sure if I'm going about this the right way at all. I have extracted a couple of TOH pbo's onto my tools drive. While the Arma 2 pbo's are extracted into my P:\ca\ directory structure, the TOH pbo's have been placed in P:\hsim\* . I did this after reading the pbo_prefix.txt files and trying to match the directory structure to what I saw there. Unfortunately, when I export this, I get a map that plays just fine but doesn't show any icons in the map for any TOH assets. All the Arma 2 buildings are represented by dark rectangles/squares as usual, but the map is simply blank where any TOH structures should appear. In the 3d world, the structures are in fact present, and they have working collision detection. I found some silent errors from the export process in a log file that indicated error code 52 (or 53?) from the various TOH p3d's. I'm not sure if that's related. I have copied all the *.cpp files from all the hsim pbo's I have extracted into my own namespace [i understand some people discourage using one's own namespace, but without a technical reason why this should be forbidden I choose to use one]. PBO's extracted thus far are: structures_us_h plants_us_h hsim_rearmed_core_h One possible issue I am confused about: There was a ca.pbo to be extracted directly to my P:\Ca\ directory, that had its own config.cpp I have found no corresponding hsim.pbo. Does anyone have any advice or info about this, and might that be related to these issues? Sorry, I know this is a lot to ask of a community that appears to be entirely dead. I dunno where else to look, though ;) Thanks!

I haven't created any classes other than the map itself. I put my map in a P:\[namespace]\Mapname\ directory, rather than putting the map directory in the root of the P:\ drive. Basically, I followed SgtAce's Arma2 map tutorial to the letter and started expanding from there. Thus the config.cpp I'm using for my map is derived from the one he used, which in turn appears to be modified from the Utes island config. The .cpp files that I copied, I did so because it is specified to be a requirement in order to use ladders/doors/etc on buildings in the map. There is a p:\namespace\ca\ and a p:\namespace\hsim\ holding all the copied *.cpp's. The p3d's themselves (and rvmats, etc, everything from the pbo's) are held in p:\ca\* and p:\hsim\* (with their pbo prefixes appended to the directory as appropriate). This seems unusual to me, but this is from following the Simple Terrain Tutorial from the BIS Community wiki. EDIT/PS: Everything works fine when I make it only with A2 assets and load the map in A2. It's when opening the A2 map in TOH, or making the map TOH-specific, that the other problems become evident. Neither actually impacts the way the simulation works, just a texture issue and a map UI issue really. EDIT 2: Here's a shot of what I'm talking about regarding the terrain. This doesn't happen using Arma 2/OA's executable or loading the map in A2[OA]: Aand one more follow up . . . I can confirm that this occurs only on the North and East edges of the terrain. The infinite-texture-tiling algorithm seems to be a little overzealous in where it starts drawing I guess?

Hah, sorry I let the links die on these. I'm afraid there are a couple of issues left in the scripts that I haven't fixed yet, or at least archived the fixed versions. It works fine enough though so it's gonna have to stay as is for now. I appreciate the offer Sven, but I couldn't very well ask you for that when I had my own hosting I was too lazy to FTP into. Now I did so the files should stay put :)