charonos

Interesting observation, there is no side "empty" btw, empty vehicles are always considered "civilian". There must be still a different "flag" to them, because AI keeps firing at abandoned vehicles although they are officially "civilian". Setcaptive and setfriend don't seem to get along with each other too well. If i remember correctly setcaptive does NOT actually change the side of the unit (check with command :side unit), but i might be wrong

Do the units actually follow that waypoint? If not, try: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> [west1,0] setwaypointstatements ["true","[] exec ""talondone.sqs"" "] or use: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> west1 setCurrentWaypoint [west1, 1] Except you already had given the group a wp with index 0 before. It think script waypoints override existing waypoints, so choosing the index 0 always works for me. But now with the new command you can manually set the waypoint index that you want.

I could be wrong but i think the string relating to the action in the action has to be without blanks: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ? (not alive (g1)): p1 action ["TAKEMAGAZINE",g1,"30Rnd_545x39_AK"] ? (not alive (g1)): p1 action ["TAKEWEAPON",g1,"AK74"] Also where did you get that syntax from ? From the wiki: Also double-check if g1 really is carrying the weapon that you state in the action. Hope that solves it for you.

I did not have the time to read all troubleshooting posts but if what you say is fact, then i expect BIS to correct that, it can't be intended from their side to have such performance drops with the patch.

It also depends what kinds of units you are talking about. If it is class air vehicles or parachute soldiers it should work, if it's snipers on rooftops you might run into some not being counted due to the roadway LOD height problem. @Platoon_Patton What is this going to do in a trigger??? It will check if the trigger is above the desired height and if that is true count the Skydivers in your example. The construct "this" in the editor refers to the object that you use "this" in, which in this case is the trigger itself. Wolfrug's proposal will do the job just fine.

They all inherit the same base class: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class Land_posed : House { class Land_Vysilac_FM : House { class Land_komin : House { and their config just consists of an armor value, DestructionEffects and maybe Lights definitions. Nothing spectacular that shows differences from the config-side. THE PROBLEM CAN ONLY BE IN THE MODEL P3D

If you write a general script for that, consider KyleSarnik's thought about ejecting the crew, because not every vehicle might have ejectdeaddriver=true in their config. And he is right about this working different on every machine, i have tried this today exactly the same way with the civilian and they kept firing at the car,even killing the civilian driver sometimes lol. A bizarre issue this whole thing is, i wonder what Suma would have to say about it ?

@Drew77: That was a long awaited fix with patch 1.05, the command is working now as intended.

Yes ,also in Arma, empty vehicles are on the civilian side. No matter if you put a civilian inside, the AI will continue to fire at it until it is destroyed. The side of the car does change to civilian, but the AI has been issued the command to destroy it as it was still an enemy. The vehicle is damned for destruction no matter what you do.

Is your .RPT file also error free? Did your patching process succeed without errors? I think dialog-related stuff has suffered the biggest problems with the patch. Just from a quick look at your script i have noticed: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> {_id = XCam_Ctrl_Pool displayCtrl _x;_id ctrlSetFade 1}foreach _ctrls2; {_id = XCam_Ctrl_Pool displayCtrl _x;_id ctrlCommit 0.2}foreach _ctrls2; What happens if you comment these lines (as they are time critical) just for a test? Apart from that everything seems alright, so the problem must be in the patch fixes. A couple of definitions in the UI config have been changed with the patch.

@VictorFarbau Blanco stated earlier:

Hi, i would be glad to be proven wrong or that i have overlooked a setting, but i am having some issues with the new patch. In fact after the new patch has changed the UI config, the button- as well as the listbox-fonts are being displayed distorted, that means some letters are bigger than others. Can anyone confirm this or give me a hint how to counter this? Cheers. Examples:

Hi, i would be glad to be proven wrong or that i have overlooked a setting, but i am having some issues with the new patch. In fact after the new patch has changed the UI config, the button- as well as the listbox-fonts are being displayed distorted, that means some letters are bigger than others. Can anyone confirm this or give me a hint how to counter this? Cheers. Examples:

Okay good, thanks for letting me know, i suspect that the problem might be a consequence of a patching-error which i (and many others) had. Why are BIS patches screwing things up? I mean they should be easy to apply and be convenient for the user, but instead they pose major problems.

Okay good, thanks for letting me know, i suspect that the problem might be a consequence of a patching-error which i (and many others) had. Why are BIS patches screwing things up? I mean they should be easy to apply and be convenient for the user, but instead they pose major problems.

Hmm, this has bugged me too, when troops waste all their ammo on destroying an unmanned MG. There is a more elegant solution for sure, but for now i can think of a script that replaces the vehicle. Retrieve the vehicles heading and position and then deletevehicle it and createvehicle an empty vehicle right on the spot with the data. This should at least work for now, if i can think of something better i will post here.

Correct me if i have misunderstood you, you are intending to write a dynamic campaign generator as a 3rd party software for ArmA? I am afraid that this is impossible if you mean to have separate C++ prgrams running besides ArmA. You can only write it in script-syntax to actually interact with ArmA. FYI : There is several people already working on dynamic campaign generators, but don't feel discouraged to go ahead and create something like that, it is always good to add something to the community or just for the fun of it.

@KyleSarnik I was NOT generalizing the issue, All i was saying is that the AI is prevented from firing the shot, in the example of the sandbag it is very obvious that something in the model must be the cause therefore it is highly likely that this is the case with the watchtower. I am absolutely aware of the fact that the fire intersection does work in connection with other buildings and objects like you described. Still some objects must have a poor geometry/fire geometry LOD or any other discrepancy in the model that disturbs the otherwise working free-line-of-fire condition. Unfortunately there is no way (yet) to compare the model of the radar tower (as Blanco stated now post 1.05) pre-patch and post-patch to find out what BIS has changed to correct the bug.

Are you sure about the machinegunner only? Have you done a large number of tests? It was always problematic to have AI fire at each other when there is geometry LOD between them, i remind of the old OFP sandbag problem, which was fixable by setting the sandbags to destroyed, but in the watchtower case this wouldn't work for obvious reasons.

@Wolfrug: Limitspeed does NOT work on helicopters which is disappointing, the chopper AI always was annoying, so slow advances with terrain cover for anti-tank apache missions came closer with the introduction of this command, but as far as i have tested it on choppers it had no effect. I have even tried it in the config (with OFP), but if you set the maxspeed to let's say 10 then the whole flight behaviour fucks up and the chopper will turn into a vertical upright position and crash, as he seemingly tries to correct the for the inhibited agility.

ObjectID is supposed not to work anymore: object The search function will find numerous threads that discuss this. @ the ace OFP scripter: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #move _g domove (position crate) ?((_g distance crate)<=2) : goto "wait" goto "move" You are spamming domoves at the unit without ~ delay. That usually results in the unit not moving at all. Also one domove command is enough <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _g domove getpos _s _g assignasgunner _s !_g distance _s <= 2: _g moveingunner _s These lines have a inherent redundancy. It is sufficient to just issue: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _g assignasgunner _s [_g] ordergetin true Ordergetin Also note, that lock does not work on AI units: From the wiki:

And why is this considered a bug ? Wiki description:

The Wiki states unambiguously that a string is returned and not a variable. So what you have to do is to convert the string into a variable for instance like: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _variable= call compile format ["%1",Ctrltext 104]

Patch 1.05 has made massive changes also to the UI, therefore TroopMon is suffering unitended font and dialog changes. I am working on fixing the problems, for some reasons the fonts all look messed up with some letters being bigger than others?! I will post an update link once it's ready.

So what do i do when i get the error about characters.pbo? Retry isn't working and ignore doesn't fix the problem. Is it possible that a certain soldier addon can cause characters.pbo no to be recognized by the patcher Any suggestions?