node_runner

Would there be any way of using a gamelogic or module or something to have directory load automatically at the start of the mission and then pause the mission so that you can set up the first camera? I'd love to use this for making an Intro scene for my mission but I'd like to set up the camera before all my AI animations start doing their thing at the beginning. ---------- Post added at 05:18 PM ---------- Previous post was at 04:48 PM ---------- Also, I'm new to Intro/Outro editing. What is the easiest way to copy all of my objects in the main mission and paste them into the Into/Outro? Should I just copy my mission.sqm file to intro.sqm file or should I do this from within the editor? Thanks!

*weeps* Solus....I love you man.

Does anyone know of any good SP missions where you play as either a Helo pilot or a gunner?

Can you do a controlled hover with your throttle? Here is my test set up: Throttle is bound to the "Analogue" version of Thrust/Break for air controls. This is the X-axis of the throttle and I have it so Thrust is pushing the throttle away from me, and Break is pulling the throttle toward me. To make the description easy, I'll consider pushing the throttle all the way forward (away from me) as 100% throttle. Pulling it all the way toward me 0% throttle. I put a Littlebird on Utes on the air field to just do some hovering tests. I'm only using the throttle controls, nothing else. Here are the results of three different sensitivity levels by going into the A2 options menu and putting the Throttle X-axis all the way down, in the middle, and all the way up: Middle sensitivity: I have to push the throttle to about 60% before I can even get off the ground. I cannot do a controlled hover. Pushing to about 60% throttle I start climbing about 1m/sec, going to about 59% throttle, I start descending about 1m/sec. I can't find a middle ground between the two. Low sensitivity: I only have to push the throttle to about 20% to start climbing. But 19% throttle starts descending. I can't find a middle ground to do a controlled hover. High sensitivity: I have to push the throttle to about 80% to start climbing. But once again, 79% starts descending and I can't find a middle ground no matter how gently I nudge the throttle. Ideally, I need to have about a 5%-10% "deadzone" in the middle of the throttle that neither climbs nor descends. But I don't seem to have one at all. What percent area of the throttle would you say your "deadzone" is where you can maintain a hover Thirdup? I'm using the 1.05 version of ArmA2, and the most recent Logitech drivers for my G940. Not sure what else to try. Additional Note: My throttle seems to work fine in other games. I've used it in DCS: Blackshark, MS FSX, Rise of Flight, and Hawx without any problems. It only seems to be an issue with ArmA. ---------- Post added at 06:01 PM ---------- Previous post was at 05:51 PM ---------- Problem fixed! Apparently I do NOT want to be using the "Analogue" version of Thrust/Break. Once I switched it to using the non-Analogue version, it started working exactly how it should. Excellent!

Solus, I'm getting a launch error: Include file @SLX/slx.hpp not found.

Woohoo! Can't wait to play with the new release. Thanks so much Solus! You are the man!

Thirdup, are you still using your G940? I've had mine for a few months and I like it, but I have a problem with the throttle in A2. No matter what I do, I can't seem to get the the center area of the throttle to be "wider" if you know what I mean. When flying pretty much anything, but especially a helo, it is very difficult to hover because the neutral/center position of the collective is very unforgiving. If I barely even touch the throttle with my hand I'll start climbing/descending.

I guess this is one way to build your own VR helmet. The guy is playing ArmA2 in the video: http://www.engadget.com/2010/04/07/diy-vr-rig-makes-neck-pain-an-un-virtual-reality/

Would love to see an English translation. I'm new to camera scripting and could use a guide like this.

I'm being a little picky. I can run the game comfortably on three 1920x1200 displays using a single Radeon 5870 with AA turned off, post processing turned off, and everything else set to Normal/Medium. It plays pretty well and doesn't look too bad. I just get spoiled by being able to turn the settings up much higher on a single screen. I get used to the beautiful graphics. I think I probably prefer the triple screens and lower fidelity to be honest, but I switch back and forth a lot.

One thing to add to the answers above: the mission designer must have set the unit to "Playable" in the editor in order for you to take control of that unit. If you are in the mission editor yourself, place a unit down. There will be a field where you can select how the unit is controlled. The options are: -Player: You will control this unit when the mission starts -Playable: You will be able to take control of the unit using one of the methods mentioned above. -Non Playable: You will not be able to control the unit at all. Depending on the mission, the designer may not allow you to take control of that unit.

I'm just hoping for the day that I can use my x3 screen Eyefinity setup for ArmA without having to trade all graphical fidelity. Combining the peripheral monitors with TrackIR is quite a treat, no neck pain required.

I hope this isn't a stupid question. The instructions recommend the tracked vehicles sound mod and say that you can just drop it into the addons folder of CSM2. Does that also go for the other TRSM sound mods as well? If I drop in the TRSM wheeled vehicles and rotary wing mods, will they conflict with the existing CSM2 sounds for rotary wing and wheeled vehicles? Thanks.

You are probably going to get referred to one of the existing threads on this topic. The moderators here like to keep things clean and organized. Make sure you use the forum search feature and check out the existing sticky on this topic. As a quick answer, there have been many patches, many of them increasing performance A LOT. So yes, performance is much better, especially with texture loading around towns and buildings.

Oh no! I just saw that I mis-spelled cumbersome in the thread title. Looking like an idiot is what I deserve for posting in haste.

It's just impossible to please people with this kind of thing. Some people feel that being able to hear the radio loud and clear during a firefight is un-realistic and they complain, but then the other people complain that it isn't loud enough. Whatever BIS does, people will complain. BIS put some audio sliders into the options menu so you could adjust things to your liking....still people complain. *sigh*

I wonder if there would be a good way for BIS to expose more of the AI routines through the API so that the modding community could experiment with different ideas. I think it's amazing that BIS is able to accomplish what they have considering the size of their team and what their development budget is likely to look like. We are fortunate that they allow modding to the extent that they do, but I think it would be fun to see the whole community experimenting with different solutions on how to improve the behavior.

My suggestion wasn't really about making things seem more realistic or to follow procedure, just to make the AI more useful. Most of the time, when they call out "Enemy man to our LEFT 500 meters!" I have a hard time finding who they are talking about. At first, I'm like, MY left or the AI's left? Then I start thinking, to the left of where I'm looking, or to the left of where my body is facing? It gets very confusing. But if the AI is fairly close to you, then giving compass bearings is a lot easier to understand and follow.

I would like to know how to do this as well.

It would be nice to have an AI mod that could achieve two things: 1) Call out compass bearings when spotting contacts, and if the friendly AI that is calling out the contact is 50+ meters away from you, he says "Contact bearing xxx from my position" 2) When the AI calls out contacts, don't call each one individually. Look in the area and if there are multiple infantry in a 50 meter radius, just say "Contact, Infantry Group, bearing xxx"

Does the AI rely on your support for bounding movements while in combat mode? Sometimes when they start saying "Go, I'm covering", I'm not sure if one AI is talking to another AI, or if he is talking to me and just won't move until I move up. In other words, when you give your team a move command in combat mode and they start to bound toward that position, do they care at all or take into account where the player is standing or what arc the player is covering?

On the contrary, it's pretty strong evidence that storing more data in memory increases performance a lot. Hence, having 64-bit addressing and using more system memory would help quite a bit.

Like I said in my post, it is common practice for developers to build any application in a way that would make it easy to change it in order to support 64-bit architecture. It's a simple process and shouldn't need a lot of planning. If you don't believe me that it really isn't that hard, just Google it. As far as performance improvements, it is harder to state empirically either way without knowing more about the game engine. I'm convinced that it would help me though. I have a very high-end system that runs the game just fine on max settings..that is until I'm in an area with lots of objects. It's clear from my CPU and GPU monitors that rendering the objects isn't overly straining my system, but my memory utilization hints that storing the high-res texture data for all these objects starts to cause swapping to/from disk. Load up a mission like "Manhattan" and walk around at the FOB Manhattan base, and you'll probably notice it the game getting slower, as well as noticing a lot more texture popping on the grass and other objects. Besides, even if you are right and having a lot more memory available wouldn't do much to help, it couldn't hurt could it? Like I said earlier, I'm not here to insult or accuse BIS of bad programming because it's impossible for me to know how their engine works internally. I just notice some mistaken assertions that it is really time consuming, expensive, or difficult to add 64-bit support, when it really should be a trivial thing to implement. I could even demonstrate it in about 2-3 blocks of pseudo-code. If an app is designed with best practices in mind, the code should only need to be updated in one place in order to add 64-bit support, and that update should be pretty easy to make. If the code was designed properly, then adding 64-bit support would be much less work than fixing one of the many bugs that BIS has put effort into fixing since release. I love ArmA, and I'm happy that BIS is in the business they are. I'm not complaining about the game at all, so try not to take it that way. I'm just pointing out that 64-bit support really isn't rocket science.

I'm not trying to sound like a smart-a** here, but modifying the game to support 64-bit addressing really shouldn't be that difficult. If it is, then BIS is probably guilty of some bad code design. Walker, as a developer of 30+ years, I'm sure you know that it's a common best-practice not to use built-in types to store pointers, but to use typedefs. Giving an application the ability to address 64-bit memory addresses is a really simple process of using 64-bit pointers instead of 32-bit. If the pointers that an app is using is properly being defined as a custom typedef instead of using a built-in integer to store the pointer, then it should be pretty simple to modify the typedef for all the pointers the app uses to enable 64-bit addressing. Someone mentioned Crysis "not counting" because 64-bit compatibility was implemented later as a patch. This is kinda silly, because that example points out that it really isn't that hard to update a game for 64-bit compatibility. At least, it shouldn't be. I don't want to pick on BIS because they might have some other reasons why it would be difficult, but in general it shouldn't be difficult at all. If it is, then that is probably because the underlying code wasn't designed according to best practices.

RE Oblivion: I'm sure others will agree with you, but everybody tends to have different variations of what constitutes "AI" in a game. This is why I was careful to clarify the standard by which I was judging the AI, which was in terms of how well it accomplishes design goals, not based on how many tricks it can do. I would consider the design goals of Oblivion characters as ambitious and well executed for various reasons. They were capable of a lot more than just the things you list. But, whatever. I don't want to argue about it because I just don't think that would be very productive. RE Strategic route planning: There is a MUCH more efficient and easier way to accomplish things than that. I've sketched up some pseudo-code of how it would work, I just haven't looked through all of the A2 API to see if all the functions I would need are there. But it would essentially be a two-stage process that could probably be implemented as an FSM. Stage one would be to break up the terrain into squares, then use very simple rules to eliminate terrain that would be undesirable to cross through. This would be fairly easy and light on the CPU. The second stage would simply have to pick the most efficient path that crosses through the terrain that IS desirable to cross through. The AI would then re-evaluate the "plan" along the route if certain conditions are met, such as detecting enemies that were previously unknown and things like that.