WirtsLegs

yes however each of those commands before the ROE assignment should take max 1 tick to execute, and certainly less than a second total to do that full list. The unit should not get a chance to engage as even if they decide to target something the aiming delay should mean that that action is interrupted before engagement takes place. If they are actively engaging, their ROE changes and they don't immediately stop that is either a bug or large design flaw. edit: this is a issue and that workaround breaks down when you start stacking multiple actions such as invis, invuln, roe, etc that could all affect start of mission engagement either by that group or another that may affect it, if we cant rely on these to execute at the start then that causes a lot of weird edge-cases and other issues. Any options or settings (not actual actions) set on waypoint0 should be in place immediately as part of the unit spawning (though that's getting into feature request territory)

Attached is a sample mission on Normandy 2 showing the issues basically trains have a couple issues 1) Cant Stop Wont Stop: first and foremost: trains refuse to be static, they ignore hold, they ignore setSpeed(), they ignore waypoint speed of 0, combine that with them bouncing off their last waypoint to run in reverse and you cannot stop trains without destroying them. If you try to spawn a train with 0 speed and no waypoints it just wont spawn if you give it a single waypoint at 0 speed it'll go at 11 knots If you set that waypoint directly in front of the train it'll be static but the cars will be squished together (see train labelled squish in sample or attached image) 2) How do I navigate? This part may be more of a Normandy 2 issue I'm not sure,but it seems many tracks you HAVE to start a train going a specific direction, eg in the port by Granville I cannot start a train at a pier and have it exit the port, i have to start outside the port and enter it further many of the points where the track splits the train cant get a path and wont spawn if you try to give it waypoints past that point train bugs.miz

What you have posted here is a workaround for the bug and good advice, but no way this is "correct as is" anything in the waypoint0 should execute and should prevent any engagement of any kind regardless of where the ROE command is.

great thanks! My Air Hockey game script may be able to finally have its code-base simplified lol

basically the title, even when disperse under fire is turned off the infantry will "disperse" aka run around in circles instead of continuing towards their waypoint Here is a quick sample miz bustedInfantry.mizin this miz blue inf are set immortal so the behaviour is more obvious, red is set invis so blue wont engage.

The issue I'm seeing only occurs when the radio item is added when you are in the slot (eg the unit is alive)

possibly related to Whats happening is radio items added to a specific group are appearing for all groups (or at least all groups in the same coalition) in both Single Player and Multiplayer, here is a quick sample miz: brokenRadioItemGroup.miz edit: small update, seems to only happen when the radio item is added while you are slotted

Definitely an issue, though I don't think it is an issue inherent with the weapons themselves but with the unit's aim. The AI seems to estimate target alt, velocity, aspect, etc way too quickly and accurately (i expect instantaneously). Instead of getting a rough likely incorrect solution first and adjusting over time.

Currently the "CTF COLOR TAG ON AIRCRAFT" triggered action sets a smoke plume that toggles around the altitude that aircraft happened to be at when the action is run (on above that alt and off below), I honestly don't know if this is intended or not as I cannot find any solid and semi-recent documentation on it. However the lua api function: trigger.action.ctfColorTag(string unitName , enum smokeColor , number altitude) contains a altitude argument, that argument (according to documentation I can find) is meant to be the altitude around which the smoke toggles. This does not work, and the smoke will toggle around the alt the unit was at when the function is called regardless of the value passed for altitude. My workaround to have it on all the time has been to have a scheduled function tracking altitude and re-running the function any time a lower altitude is detected, this is clumsy and causing a lot of knock-on complications. Now I definitely get that this likely represents a pretty low priority, but worth reporting and maybe (hopefully) its an easy fix. I have attached a quick example miz to demo the issue: brokenCTFTag.miz

This has been an issue for quite some time now (since well before 2.8), just only now finally got around to setting up a clean test and recording a track. Basically Fire at Point commands will be ignored if there is a potential target within the groups engagement range, in the sample mission I have a few bofors setup (done the test with a few different units, behaviour is always the same) Gets fire at point command as part of its wypt 0 Gets it as a triggered action Sent via do script I fly over them all in a mossie all 3 will immediately abandon the task and engage me once I am in range. This behaviour is the same in Singleplayer and Multiplayer Additionally; somewhat related, if the groups are set to restrict targets to ground only (as a way to possibly get around the above issue) they will simply ignore any fire at point commands given that have a altitude set (wont fire at all), and ROE settings dont have any impact either, seems the fire at point command flips them to weapons free. fireAtPoint.trk

Basically the title, if you embark a unit that is inside a zone with a trigger to fire when all ground units out of zone the trigger will not fire until the units are disembarked elsewhere (no matter how far the vehicle they embarked travels) Tacview shows the embarked units a staying at the point they embarked from until they disembark, and enemies will continue to fire on the units old position. Based on this it seems that the units position is not updated after embarking (either to the origin so its out of the way or to match the position of the vehicle they embarked on) attached a basic miz to demo the issueoutOfZone.miz

Infantry behaviour is unreliable and will tend to not function properly if tasked to "go to waypoint" after disembarking a helicopter. I have attached a sample miz with a few examples (different ways to trigger the waypoint) suggest running a few times and see how it behaves. gotoTest.miz Drawings on the F10 map indicate expected dropoff point, waypoint 2 (next numerical/where they should go if not tasked with new waypoint) circled in red, and waypoint 7 (the waypoint I am tasking them to goto) circled in blue. Common problems: Infantry just doesnt move after disembarking Infantry will go to the original next numerical waypoint instead of the tasked one Most of the group will go the right way but one will run off towards the original waypoint They will stop before getting to their assigned waypoint

Download link seems to be dead for the saved game mod? Any chance of an updated link?