charonos

The command findnearestEnemy does work somehow, but if you need to apply it on a time-critical basis, you should look for a quicker solution. I have tested this with 2 opposing units standing right next to each other (1 m distance), used a mutual reveal on both of them and still it can take SOMETIMES up to 10 seconds until findnearestEnemy came up with a result other than nullobject.It is unpredictable. Probably due to the same reason why opposing units would not open fire at each other if they are very close to each other, which has been a known bug in OFP already and has not been fixed.

You might not have set the offset right from the center of the object that you are attaching the light to. If the light is physically inside that object it might not really shine. You have used these commands to create the light, right? _light = "#lightpoint" createVehicle [_x,_y]; _light setLightBrightness .2; _light setLightAmbient[1.0, 1.0, 0.9]; _light setLightColor[1.0, 1.0, 0.9]; _light lightAttachObject [_object, [0,-4,0]]; One thing i have noticed is that when you move an object with the velocity command that has a light attached, the light will stop shining after a certain distance, seems to be a bug. You can of course also use particles, but they don't really seem to emit light, but in the distance for your UFOs it might be allright. Try it out with the koulesvetlo type and set the size to like [10,10,10].

Lol, if you say so,knowing better what i mean. Mike@Uk just needs a random selection, so it's all about the random command. Either with "floor" (as you suggest) or without it, he gets a "select"-compatible rounded random number and all possible spawnlocations will be allocated to the units anyway, so each unit will eventually get one of the positions in the array,regardless if the result is next to lowest integer in relation to the random result or not.

If your spawn locations are that specific like "on a tower", then you should put all imaginable spawn locations into an array like _spcoords1=[x1,y1,z1]; _spcoords2=[x2,y2,z2]; _spcoords3=[x3,y3,z3]; _spawncoordsarray=[_spcoords1,_spcoords2,_spcoords3]; and then make a random element selection: _n= round (random (count _spawncoordsarray)); _spawnpos=_spawncoordsarray select _n; _type createUnit [_spawnpos, YOURGROUP]; You can then subtract these already used coordinates from the array _spawncoordsarray=_spawncoordsarray-[_spawnpos]; and run it again for the remaining units to spawn. Hope that helped.

Hmm, the Wiki also states that an empty string is returned, if the unit has no command. From the Wiki: <<Return the current command type (empty string when no command)>> So the radio command that you send to the unit must be the cause of the problem. All units in initial state without being issued a waypoint will return empty string on currentcommand. However the Wiki lacks a lot of information, that is true.

@bdfy Who sais that a big script is a bad script apart from the debugging aspect? The main goal is to avoid too many parallel scripts. In theory it is better to have one script with a 1 second delay, than 10 different scripts running parallel and if you have a lot of conditions,parameters and actions to control then your scripts will become loooong. There is however some controversy about that topic here in the forums. Another example of a big script is a switch do case construct that lists a lot of different cases which doesn't run continously. Scripts like that can also turn out to be long. They can of course be splitted into many small scripts, but when you are at it, adding more and more code, then sometimes you find yourself with a huge script.

There "might" be a limit of lines that can be used though, during debugging a 2000+ lines script for many hours i finally solved my problem by putting all lines past 2000 into a new script, but maybe i was just overworked and deleted the error-causing line during the copy/paste process. That needs to be confirmed by someones else, i am not absolutely certain about that.

Obviously the addon author has not defined the class CfgGroups in his config, the only way to have these units appear in the editor is to write an additional addon-config that defines the groups. But as you consider yourself a noob you might not know how to do this. What units are you talking about? Either write the addon author an email and ask him for that feature in an update or i can do it for you, shouldn't be too much of a biggy. Charon

No intention to divert the topic of the thread, just a little sidenote. I would always go for game logics rather than invisible Hs, because if you have lots of invisible Hs in your map and call for chopper extraction later the chopper might land on one of those (if not intended) except you use a script that sticks an invisible H right under the chopper. You can of course setpos [0,0] the invisibleH after you have created the grenades. Anyway, can't wait for CoC's Arty converted for Arma, as it's so much nicer to have ballistic mortar shells than "faking" them.

PutiNix77 is a visionary with global warming in mind. Soon there will be palm trees in Berlin, there was no mentionable winter here until now, i see it coming. Maybe some maniac will model a Berlin island for the Wachpolizisten in the future, would be kinda cool. Strafing punks at Kottbusser Tor with an automatic or sniping hooligans at Alexanderplatz.

Na det is ja wat! Cool idea!

Thanks for the tip, i very much appreciate it! I will look into that matter. Currently i am doing a full waypoint implementation, which makes you feel like playing chess against yourself. You can have created and existing groups board choppers, move the choppers to waypoints, unload the group etc. Also there is a join option now, so one group can join the other. I am still having problems making a quick check which side resistance is friendly to, for 3 side battle scenarios.

Good to see that it's not just me lol. You pointed exactly the problem out. I will make more tests, to see if there is a quicker way to find it out, maybe with some weird operations on individual units, there has got to be something that units would refuse to do with enemies that they would instantly do to friendlies, which would reveal the enemyside...

Hehe, i am using the Wiki constantly and have not considered that command helpful for the situation, but thanks for thinking about it. With determine i actually mean to find out and not to set. So a command that is supposed to SET a side to friendly or enemy is not solving the problem, which is to FIND OUT how friendly or inimical a side is to the other. I don't want to alter the friendly status of the sides at all, i just want to retrieve the original information that the mission maker has set in the editor by script. So something like GETFRIEND would work, if it existed.

Does anyone know a QUICK method to determine which side the resistance is friendly/inimical to OTHER THAN LOOKING IT UP IN THE EDITOR ? I mean by script? I have tried numerous things, the search function has not found a satisfying solution in the forums. There is the commands "friendly" and "enemy", which have no operator, so they are useless for scripting, unless i have overlooked something. I have ended up with a complicated script that uses countEnemy and compares a west,east and guer soldier that have to stand next to each other for this to work, and it can take up to 10 seconds to get a result. There must be an easier way, anyone has any idea? Thanks for the brainstorming. Charon

I have finally found a very >>clean<< solution, where other debuggers can be started as usual and TroopMon can be started by pressing a button right under the ABORT button. And if future tool hackers will conform to clean methods of implementing their stuff into the main config.bin then there should be no conflicts at all between all the scripts started with the Esc-Menu-method. I will release an update later this week, which will have the new start option and accurate ammo count/efficiency statistics as well as an additional detail display of the checkunit's config attributes.

Snakeman, i primarily did not want to interfere other debuggers. Most of all i did not want people to have to insert a description.ext into their mission folder. Your point about the OBJECT remaining in the final mission is valueable, i honestly did not anticipate people might forget to remove it. I will look into alternative easy ways of starting the tool without affecting the mission.sqm. Thanks for the input.

@ SNKMAN, well that's exactly the point, you don't always see what all of your placed/spawned units are exactly doing and people tend to overspawn scenarios to have objectives accomplished. Already in OFP that was giving me such a headache to be aware of having 20 living russian attackers somewhere on my map that would not do anything because they were constantly in "COVER" mode, lying on the ground or were issued other strange orders. Remember the OFP/ArmA AI is not working perfectly, so it's all about checking what the AI is really doing out of what you intended it to do. To code a good AI and still keep the FPS high, is a task that is very hard to achieve for every game company. Still the most annoying thing about the AI is that units open fire at target distances of 50m+ easily, but sometimes would stand around carelessly right next to each other at 10m- at not open fire even with perfect combat settings, that must be possible to fix, again was like that in OFP already. Gaia's console is a time-saving tool for people that want to check variable values and not put "hint" or "chat"-"format" lines in their code, but be able to decide while the mission is running which variables to check. I am working on a little update for TroopMon, it will have a very accurate (to the bullet) ammo count statistic for all sides, which is a tactical feature to evaluate firepower/efficiency.

Search function has found: http://www.flashpoint1985.com/cgi-bin....aa+size

Yeah experimented with that one too, cool to see that finally missile deflection is achievable in ArmA, as most OFP chaff/flare scripts have used setdir on the missile which did not alter their movement direction at all,but just their heading, and the missiles had still hit their target.

I can't test right now if it makes a difference but try brackets instead of the quotes, thats how i do foreach statements: {_x addweapon gogs} foreach _units3; and from the Biki: { STATEMENT; ... } forEach ARRAY; Hope that helps, Charon

Still the same borked mission, i have started it after installing the new patch from the start and it still does not finish, i am sure there is a condition problem in that mission. Maybe one enemy tank took off to the other side of the map and if the condition is to kill all enemies then you'll never meet that condition. Very disappointing that BIS didn't fix that mission with the new patch, because they must be aware that it is not working. Anyway let's hope for patch 1.3 ...

@KyleSarnik That's the big problem the 4 gunners would probably not fire simultaneous rounds and of course it would be difficult/impossible to make them convincingly move the barrels in the same direction. Still it's a lot of work for a subtle effect that can only be noticed when you are actually observing the Shilka firing from very close range or with binoculars. And AIwise you end up with 1 commander AI, 1 driver AI plus 4 gunner AIs per Shilka.

It might be a waste of AI to put 3 additional gunners in there to actually have all 4 barrels firing rounds because each additional turret-class needs one gunner. It seems that the engine allows only one barrel per weapon. We will find out soon from BIS. My ArmA experiments have shown that an additional gunner only engages targets that the primary gunner is targetting in the same moment, so it might be actually only one targetAI for the whole vehicle, who knows. The config features different selections from the p3d, it would be probably easy to define the additional selections (like in the old memory LOD) once o3 is out. class AddBarrel : MainTurret { body = "Turret_2"; gun = "Gun_2"; animationSourceBody = "Turret_2"; animationSourceGun = "Gun_2"; animationSourceHatch = ""; selectionFireAnim = "zasleh_1"; gunBeg = "usti hlavne_1"; // endpoint of the gun gunEnd = "konec hlavne_1"; // chamber of the gun };

Hmm, i haven't experimented with soldiers yet, but Zerg63's BDU units DO bleed, so i guess it's a problem with your config. Make sure your inheritance is correct, then it should work. The part responsible for the wounds seems to be: selectionHeadWound = "head_injury"; selectionBodyWound = "body_injury"; selectionLArmWound = "l_arm_injury"; selectionRArmWound = "r_arm_injury"; selectionLLegWound = "l_leg_injury"; selectionRLegWound = "r_leg_injury"; But if you use already defined classes then it should work fine. Once the tools are released, you will probably have to make sure to have your selections named like above in the editor.