CarlGustaffa

Yes, I had already used an attached EH to everyone. But I was sure there had to be a better way of doing it since apparently it's doable on a per type basis. But I guess not, since it appears to be a class defined option. What I was hoping for was to add "canhidebodies" to players type of soldier in the editor, instead of attaching en EH-killed event to every soldier on the map. But one thing always leads to another it seems. How can I restrict what units an addaction or eventhandler is being added to, based on its class? Since I now get Hidebody on vehicles I take out.

This is just plain embarrassing Somewhere along the lines, test=[] execVM... had become fog=[] execVM... I'm missing the harakiri option in ArmA

Okay, I'm pretty much going nuts about this one. When I call this script using nothing in the test=[] execVM..., I attempt to set i.e. _minimumfog=fog; _resultfog=_minimumfog; (or =fog;, doesn't matter) then hint format ["resultingfog :%1", _resultingfog] will return the scriptname, currently residing in the scripts directory. (edited) Then a strange error message stating "Type script, expected number, array......." However, after manipulating the _minimumfog value inside a while loop, th hint format starts giving me the correct numbers. Can I not use such engine variables from inside scripts without them being in loops? When I call with test=[fog] execVM... and initialize with _minimumfog=this select 0; _resultfog=_minimumfog; (edited) both the hint formats will show what I want. I fail to see how these two syntax'es could be any different, can someone please explain this to me? Full "script" plaything attached below if it should matter. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if(bWeatherIsChanging) then { Â Â hint "I will not change fogbyrain while weatherscript is running"; }; waitUntil { !bWeatherIsChanging }; player globalChat "Weatherscript appears to be finished, now updating fog automatically"; sleep 5; _bhalt = false; _squaredfactor = 1; _minimumfog = fog; _resultfog = fog; sleep 0.1; hint format ["Rain: %1\nMinimumFog: %2\nResultingFog: %3", rain, _minimumfog, _resultfog]; 2 setRain 0.3; sleep 2; _bhalt=true; while {_bhalt} do { _variablefactor=_squaredfactor+rain; _squeezefactor=_rain*minimumfog; _minimized=1 min squeezedfactor; _squaredrain=sqrt(rain); _squaredfactor=(_variablefactor*_squaredrain)+((1-_variablefactor)*rain); _resultfog=((1-_minimumfog)*_squaredfactor)+_minimumfog; 0.001 setFog _resultfog; sleep 0.009; hint format ["Rain: %1\nMinimumFog: %2\nResultingFog: %3", rain, _minimumfog, _resultfog]; }; Oh, the bWeatherIsChanging is initialized to false on the player init in this test. The purpose of this snippet is to increase the fog based on the amount of rain (since I think the visibility impact is way too little by default), but not while any setFog based weatherscripts are running (since setFog and setOvercast will not cooperate properly).

Thanks, works just brilliantly and way beyond. Excellent tool. Wonder why BIS has decided on giving so increadibly much by default, when a vehicle is per data only allowed to hold much less Found an interresting one on the Stryker; gunnerHasFlares, any idea what this is ment for?

Hi I'm part of a "clan" that does large multiplayer coop missions over several days, once every one or two years. For the next one, I think we have 27 players. The players hardware vary from very low-end to very high-end. I don't have low-end system, but grass is basically killing the framerates and causes a weird lag once every second making aiming just about impossible. The current system as far as I understand it will set the settings on a per-mission basis, or per-server basis depending on if the settings are controlled in the mission. To our mission designer, who has a super killer system, he won't be playing without having everything maxed. But seing my performance, it was obvious it wouldn't be possible. So how about the following change: Server.cfg will determine if a certain setting can be controlled by the client/player? I.e. for grass/maxterraingrid; default is so-so, but player can override. Some might call this "cheating" because lack of grass provide a tactical advantage (and I agree), but not being able to play because of it is a greater killer. Also, the server admin would be god and disallow it on teamgames and such, but could allow it on coop games vs AI. I think this would be a great feature to implement in an upcoming patch. Another not about grass. To me it is a monster killer; going from very low (off) to low (on) is going from enjoyable to intolerable and completely unplayable. I would really much like to use low, because on very low everyone in the horizon is walking in thin air; snipers floating in the air etc. But I can't because of the grass. WHY are we up to version 1.08 and still no grass on/off option? Why can't BIS acknowlegde that grass can kill the system (at least mine)? All my other settings are set to about normal or off except anisotropic filtering which is high. System is dualcore 6600, Geforce 7950 GT, 2 gb ram, and installed on a raptor disk.

I joined an evolution server last night just to test. Appears to work just fine. I think we will go for a similar solution. Thanks everyone. But BIS, pretty please separate the grass from the terraingrid resolution; as units will still appear to float on lowest resolution. I can't use grass, but I would very much like to have better grid resolution so that units that was supposed to be hiding in terrain, remains hidden instead of popping up floating above it!

Good thing I included the actual code. No, those mistakes are not present. I'll update my slightly faulty descriptive text. Thx for noting. Hmm.. Actually, hint format ["fog is: %1", fog] will yield the full path and filename to the scriptfile, even when put in the mission directory? Ehh, huh? Rain and overcast gives the correct answer though. (Previous edit on the addon disabling was faulty, I forgot to set back to fog. So, even with addons disabled (this is on porto map though), I'm still getting this...

Skipping isn't possible, but you can plan for it when you start, which is easier said than done. But you can add your own set of "tools" which will make you go through the mission much more quickly. These include debug actions for setting selv captive on and off, adding a unit next to you (without setcaptive), a "hit" eventhandler that restores your (and other units health), a script that sets health based on the distance from you in order to kill nearby enemies etc. Planning beforehand involves avoiding use of triggers grouped to specific units. Also consider setting up radio switch triggers that enables the waypoint after the one that is switched. Avoid using objectives that depend on other objectives, but if needed, include the means to set them independantly.

Where is this setting? The lag is killing me.

Thanks for the Evolution tip. Know it is some multiplayer thing, but I've touched multiplayer once only due to the grass enforcement But I actually love the singleplayer aspect of the game as well. But if grass was enforced on the upcoming lan, I (and probably others) would have to withdraw. I'll let our mission designer have a look at it, I'm just learning the editor myself.

Hmm, would this affect any laggyness? Also, how do I cope with units that have started moving, wouldn't they just stop when they shouldn't? Seems like a whole lot of global variables at work, considering the number of units this affects. Have to rest a couple of days on this one... But thanks, nice suggestions. Would unit stop true and false work better at least until the player is in the general area? At least I could work out "auto saves" that could work this way, but it won't prevent the "user saves" from going bad. Frequent autosaves are annoying, and too rare autosaves with buggy usersaves, are extremely frustrating. How to determine the balance? Oh well..... Need sleep...

Hi Being relatively new to this, I have just become "aware" of one of the greater bugs in the engine/editor -- the fact that units which has been disabled using disableAI "MOVE", will be reset during saving. I use MOVE, TARGET, and AUTOTARGET disabling A LOT! Basically this means that my mission (2-4 hours of playtime using my playstyle) doesn't really work out as planned; Once I'm "on location" the units are no longer in the position and arrangement I gave them. So, how do you cope with this? And, is this another "feature by design" by BIS, or will this eventually be fixed? I'm just about ready to give up all together

I have this some unnamed units initfield: this setUnitPos "MIDDLE"; this disableAI "MOVE" When I want to cancel it, I use enableAI "MOVE" (and setUnitPos "AUTO" respectively). When I click the savegame, it instantly starts to move. If I load that savegame, it also instantly starts to move. setUnitPos does not seem to be cancelled. Just checked, and bugtracker lists it as a bug: http://bugs.armed-assault.net/view.php?id=2419 Re-executing init lines doesn't sound like a good idea, think about all those addmagazine commands Maybe I misunderstood you though. I did try a singleplayer mission with sort of a fix for this, but it only gave limited saves and ruins one of the key features I like in ArmA over OFP -- unlimited saves for us that can't shoot straight but still would like to enjoy the game.

I have this crashing behaviour too. But I haven't seen it before I installed QG. I had it A LOT during the QG campaigns (not even finished because of it). And I've noticed I can't load some savegames in my own missions. This makes mission editing, and especially the testing part, nearly impossible. For me this was repeatable; in the QG mission where you and your 4 other sabouteur mates started on the beach to satchel off enemy armor, the game would crash if you saved after you entered and used the grenadelauncher equipped UAZ. I think I only had FDF sounds active the the time of testing, but not quite sure. Can't live without these sounds now

I'm on XP with 2GB of RAM, with an older graphics card (because I've read about all these problems with 8800). So I need to play with quite reduced settings. Ok, so it doesn't look very nice, but it's still a very good game to me. I had the memory crash very rarely, usually only when I upped the settings (I think especially texture quality) for snapshots, that I experienced these crashes. But frequent enough to be slightly annoying. So I started using -maxmem:512, and now all of a sudden I get prolonged halts of 10-30 seconds, with some very odd memory allocation going on (as seen in task manager). This only happens in quite large selfmade missions with lots of additional sounds, ambience and such. I have to switch island (using the improved Sahrani in QG) in order to restore these problems. My question, is this command as safe as I'm led to believe?

Wouldn't work as all units in groups would work in formation destroying the illusion. Disbanding from group would quickly create too many groups.

In my mission I use the ups script for enemy units to do patrols. And that's what they're doing, patrolling. However, I would like to have a few enemies idling in the city in a natural way; walking about, sitting down, doing various animations, practicing, watching around, chatting with other npcs, taking a piss maybe, you get the idea -- idling. I can't use the dismissed waypoint type, because the untis will drift waaay outside of safe boundaries. So, are the available any scripts for either ofp or arma that achieves this? Similar to the urban patrol script, except urban idling script, sortof

Although it won't make use of more idling animations, it does sound like a more simple approach. Have to keep that in mind.

I used to use setPos, but even that is very uncontrollable. I actually wanted to have guards being replaced every second hour or so, so it would be nice to have this work. I think the hotfix got installed with QG, but I did say no to installing the 1.08 patch as that was installed already. I am no longer having problems using ladders myself, but now AI are having serious issues; more than before I think. During testing (about 100 tries or so), I have not seen once that the AI has arrived guardpost alive

In my so-called (noob) mission, which is having more and more problems, I placed MOVE waypoints with house positions on a camps outlook posts. Looked nice while I was there, they got up. However, when I drive up from far away, I find that all of them (yes, ALL) have fallen down. So I observe from a distance and see that they climb up the ladder, only to immediately fall to their death. When player is close, it works. How do I deal with this?

Does the AI footsoldiers even fight back on the choppers? Wow, that's new to me. Anyway, how about moving the units out of the vehicles, or lower their skill (general or specific using an array). If it's in a cutscene, you could set the heli to captives using setCaptive command. That way they will shoot but not be shot at.

Hi I've been trying to do some alarm responses, using simple trigger work, and found something strange. I had a repeating trigger which simply did iAlarm=1 and iAlarm=2 depending on Blufor present and player in thislist condition. Worked fine, but had to use setCaptive so that the guys wouldn't shoot me. And once I shot some guy, the damned trigger ceased working?!? It was stuck on the on deactivation mode; no matter how much I tried to retrigger it remained on this mode. So I added a massive rating to myself with this addRating 100000 in my init, and now the trigger works... Seems to me I'm no longer considered BluFor once I go renegade, which seems to be related to my rating. Thus I will never trig a BluFor based trigger. Maybe this should be noted in the Biki's setCaptive description? Or am I getting this all wrong?

Actually while being captive (and not considered renegade), the blurfor triggers will detect me as blufor, but globalchat will report me as opfor? Hmm... Very strange...

Hi Most anims can be exited or swtched out of in a script, but I have no luck on the kata and talking moves. Specifically, I want two soldiers in the talk animation AmovPercMstpSlowWrflDnon_talking break out of it and react to an alarm. Once I switchMove or playMove to something else, they go back into the talking move. Arrrggggh, a whole day waisted...

Oh, so *that's* nulling the animation? Okay. Believe I tried that, but the next animation would play or switch then just return to this talking animation, unless it played a dead end such as a dead state anim. Have a tested example that works, with correct delays, and end up in a working pose where further waypointing works?