node_runner

I have both the G940 and the Saitek X-65F. Hovering is not difficult for me using the G940. It still has a fairly stiff center position as long as the forces are turned all the way up. If any of you are thinking about the X-65F, I would not recommend it if you are primarily going to use it for flying rotor-wings in ArmA or other sims like Blackshark. The X-65F is a fantastic stick for fighter jets, but it has a very stiff throttle which you wouldn't want to use as a collective for flying a helo. So if you do go the X-65F route, you will probably opt to use the keyboard or other buttons on the joystick for your collective controls while flying helos in ArmA. That said, each stick has different strengths and weaknesses. I like using the G940 to fly aircraft where feel is important. I prefer the G940 in Rise of Flight and flying small engine prop planes in FSX like the Piper-J Cub. The X-65F on the other hand, shines with aircraft that have more sophisticated avionics or aircraft that benefit from a higher degree of precision. I use it for Wings of Prey, DCS: Blackshark, and will use it for DCS: Warthog when that comes out. If you really enjoy flying helos and you have money to spend, you can buy a nice USB collective stick from www.flightlink.com. I really enjoy using mine in ArmA and DCS: Blackshark. I've been using the Flightlink collective paired with the X-65F in ArmA and that has been working pretty well for me. One thing to keep in mind though, even if you are willing to spend $500 on a collective stick, you'll want to make sure you have some semi-permanent way to bolt it down into some kind of cockpit set up. Otherwise, when you pull up on the collective, you'll end up lifting the whole unit up.

It looks like a bug report has already been submitted to the CIS here: http://dev-heaven.net/issues/15191 If you guys notice any other missions where this is happening, it might help if you add those to the comments section of the bug report.

I'm having the same problem! I'm running the Steam version of both ArmA 2 and OA, fully patched, and no mods. I'm using dual ATI Radeon 5870's on my rig. I first noticed it on the same boot camp mission where a waypoint doesn't show up for me during the "night ops" mission. I've noticed the same behavior is some of the other campaign missions, such as the 2nd campaign mission where you command an M1A1 and a small armor convoy. I had to watch someone else play the mission because the waypoint never pointed me to the M1A1 and I wasn't sure where I was supposed to go when I started the mission.

Hi guys, I just got my shiny new Logitech G940 HOTAS flight system. With the new beta patch, I can even get the throttle to work in analog mode. Unfortunately, Arma2 doesn't seem to support force feedback with this device at all. The joystick is completely limp, won't auto-center, and doesn't provide any resistance while flying. I'd like to put in a request for this device to be supported because it is a pretty nice piece of hardware that I think will be in relatively high demand among flight enthusiasts.

Your problem is crossfire. A2 doesn't work very well with crossfire. Disable it and only use one card, then all of your problems should go away.

Excellent news jaynus! I'm hoping I might be able to use arma2lib to make some cool TouchBuddy plugins. Would be nice to be able to use TouchBuddy for the map, especially with high command. Someone has already made a basic TB panel for A2, but with ArmA2Lib, these could be much more useful. Touch Buddy: http://www.touch-buddy.com/forums/faq/18-master-faq.html

I'd LOVE to see BIS add more types of areas to this command, or better yet, let the community define more types. Some things that would be really useful: Road Mountain Peak Thick Grass Defilade Desert

So I've been playing around with this because I wanted to be able to spawn tanks/armor in random areas, but they would sometimes spawn in dumb places like in the middle of forests. I wanted them only to spawn in meadow/planes so this is how I got it to work. I just made a quick sample mission with a single marker in the editor named "marker" and then put this into init.sqf and it spawns a new USMC guy in a meadow every time: _pos = getmarkerpos "marker"; _radius = 500; _exp = "(1 + meadow) * (1 - forest) * (1 - trees)"; _prec = 10; _bestplace = selectBestPlaces [_pos,_radius,_exp,_prec,1]; _spot = _bestplace select 0; _spot2 = _spot select 0; "USMC_Soldier_MG" createUnit [_spot2, group player, "newguy = this", 0.5, "corporal"]; sleep 2; selectPlayer newguy; I figured out the hard way that selectBestPlaces was returning a multi-dimensional array, which is why I needed this bit: _spot = _bestplace select 0; _spot2 = _spot select 0; in order to end up with the coordinate value that I needed.

this is nice! I've been looking for something to help me spawn tanks in a random area without having them spawn in dumb places like dense forest or on a building. NICE!

I can't get this to work. I've tried the following and non of them work: _unit = ([getmarkerpos "mark1", 0, "BMP3", east]call BIS_fnc_spawnVehicle) select 0; _unit = ([getmarkerpos mark1, 0, "BMP3", east]call BIS_fnc_spawnVehicle) select 0; _unit = ([(getmarkerpos mark1), 0, "BMP3", east]call BIS_fnc_spawnVehicle) select 0; ---------- Post added at 04:20 AM ---------- Previous post was at 03:49 AM ---------- Okay, a friend helped me figure out the problem. The BIS functions take about half a second to load once the mission starts, so you either have to wait a second or two with "sleep" before calling BIS_fnc_spawnVehicle, or you can just put in: {!isnil "bis_fnc_init"}; to check and see if it has loaded or not. Oh, and the _unit = ... stuff really isn't necessary. You can just use: [(getmarkerpos marker1), 0, "BMP3", east] call BIS_fnc_spawnVehicle; and it should work fine.

There is no config editing to do at all! Just set the aspect ratio to Triple-Screen, and you are good to go, even if each screen is a widescreen. In most games, you have to set the ratio to 16:9 for it to work properly, but games like DCS Blackshark and ArmA2 have their own triple screen support which works pretty nicely. I'll be honest though, I do switch back and forth a lot between three screens and one screen. The reason is because I can turn the graphics almost all the way up on one screen and sometimes I miss how pretty everything looks when playing across 3 displays. But things do feel so much more immersive with 3 displays. Especially when flying. I'll see if I can find some time today to make a video for you guys.

AA: Disabled Post Processing: Disabled View Distance: 2500 Everything else: Normal Runs pretty well like that. AA kills the FPS the most obviously, followed by shadows and terrain details. I can put up a detailed video of it on YouTube if people really want me to. Here is one that I made for FSX:

Have you guys played with Planned Assault yet? It's pretty impressive: http://www.plannedassault.com/

Yes it works fine. I'm using Eyefinity with a single 5870. I have it hooked up to three 1920x1200 screens, for a total widescreen resolution of 5720x1200.

I don't know anything about map/island building, but is there some kind of AI pathing that the author needs to include in order to make the AI more capable of driving on roads? I'm trying to create a convoy on Quesh-Kibrul. I've use my own waypoint methods, norrin's convoy script, and DTM2801's convoy script. No matter what I try, the AI driving is just abysmal on the roads. Whether or not I group the waypoints close together, set the HMMV's closer or farther apart, or manually adjust the max speed. They constantly stop and start turning in odd directions, then bunch up and hit each other. But on Cherno or Utes they drive just fine. I can put a waypoint down far away and they even take turns and curves fairly well along the way. Is there something broken or missing about Quesh-Kibrul that would make the AI awful at driving on the roads?

I figured out my problem. It's not an issue with the map. In the convoy scripts I was using I didn't realize the first array element passed must be the lead vehicle for them to work correctly.

Ok, I made some edits to the convoy script fixing the above behavior for me and sent the changes to Norrin in case they are useful to him. Thanks again Norrin.

Well it isn't an issue with Quesh-Kibrul in particular. It's not related to that specific mod. It's just an editing question about how the path-finding works. Is the AI path-finding affected at all by how islands are made, or should the AI be able to drive along roads with no problems no matter the island?

From my experience so far, Norrin's convoy script does a pretty good job with up to about 8 vehicles (mechanized, armor still gets messed up). The only problem I'm having with it is that once the lead unit reaches the final waypoint/marker, all the other vehicles are determined to pull up beside the lead vehicle in a line formation instead of just staying on the road in a column formation and coming to a stop. If anyone has any ideas, I'd appreciate it.

Great script Norrin. Although, I'm having a problem where each vehicle wants to switch to a line formation on the last waypoint. Any ideas for this? I was hoping that once the lead humvee reaches the final waypoint on the road, that it would just stop and wait, with the other humvees stopping behind it waiting on the road. But once the lead humvee stops, all the rear humvees want to pull up beside the lead in a line formation before stopping. I'm not sure how to change this behavior since they are not grouped.

Thanks for posting those!

Two questions: 1) What is the best way to get a unit to move to a marker? I've tried placing a marker on the map named "marker1" and I've tried two different variations that say they should work according to the BIS editing wiki: this move position "marker1"; and _pos1 = getMarkerPos "marker1"; this move position _pos1; and they don't work, but the editor seems to accept the syntax without any problems. 2) When I tell a unit to "lookAT" another unit or object, is there a way to keep the unit from glancing around side to side? I'm trying to use lookAt as a cheap way to avoid camera scripting a first-person cut scene in the intro to a mission. I can get the character to walk around and look at units, but sometimes I want to stop him from glancing around the area and focus on an object. Any tips?

Thanks loyal! What ended up working for me was: _pos1 = getMarkerPos "Marker1"; this domove _pos1; The disableAI trick helped, but didn't completely stop him from glancing. But hey, it's good enough I think, so thanks for the advice.

That's what I initially tried and it didn't work.

Thanks, but that is kind of a crap way of doing it because you end up having different placement coordinates for each unit. When you have a mission with lots of waypoints and triggers and things like that, it's just a big mess. ---------- Post added at 06:23 PM ---------- Previous post was at 06:15 PM ---------- It looks like the best way is to open up mission.sqm and copy all of the objects from class "Mission" into class "Intro" and then you will have the same xyz coordinates for all your placed objects.