Grooveline

The user-defined Properties for Trigger Zones are insanely useful. Please consider adding similar functionality for Airplane and Vehicle Groups, this would be a game-changer for content creation. Thank you.

Thanks for the responses, I appreciate it! I certainly hope this is a bug, the "Effects" string is coming out of the mission lua and I don't have another source for that value. What I mean is, I'm not running the method with values I'm providing, they are coming from an external source. I know there are differences between how the mission stores statics and what the addStaticObject method takes, but if you're correct, I'd be in a pretty bad place. Thanks again and let me know if you discover anything else, I'll do the same!

These 2 statics were generated (by the same code) using coalition.addStaticObject(). As you can see, both objects are created, and both are visible on the F10 map. For some reason, however, the smoke has its altitude set to absolute 0. The net effect of this is that the smoke is not visible in the sim (presumably it is under the level of the land). Why does the airshow cone have it's altitude set correctly (and thus is visible in the sim), but the smoke does not? For laughs (or tears), I've tried adding a "z" field, an "alt" field and an "altitude" field, each set with the elevation of the ground at the coords of the object, with no change in behavior. The big smoke object (and perhaps others) behave differently than "normal" statics. Does anyone know why?

Please consider firing more events that we can listen for in our API scripting. The current list (see below that I generated out of the current build), is nice, but could be soooooo much nicer. I'll spare you my wish list, I just hope you'll consider doing this. world.event = { S_EVENT_HUMAN_AIRCRAFT_REPAIR_START = 59, S_EVENT_MISSION_END = 12, S_EVENT_DAYNIGHT = 39, S_EVENT_SHOT = 1, S_EVENT_KILL = 28, S_EVENT_MARK_ADDED = 25, S_EVENT_WEAPON_REARM = 47, S_EVENT_HUMAN_AIRCRAFT_REPAIR_FINISH = 60, S_EVENT_UNIT_TASK_COMPLETE = 49, S_EVENT_SHOOTING_END = 24, S_EVENT_BASE_CAPTURED = 10, S_EVENT_SIMULATION_UNFREEZE = 58, S_EVENT_DEAD = 8, S_EVENT_TRIGGER_ZONE = 35, S_EVENT_SIMULATION_FREEZE = 57, S_EVENT_MAC_LMS_RESTART = 56, S_EVENT_RUNWAY_TOUCH = 55, S_EVENT_EJECTION = 6, S_EVENT_RUNWAY_TAKEOFF = 54, S_EVENT_WEAPON_ADD = 34, S_EVENT_MISSION_WINNER = 53, S_EVENT_SHOOTING_START = 23, S_EVENT_MISSION_RESTART = 52, S_EVENT_UNIT_LOST = 30, S_EVENT_INVALID = 0, S_EVENT_PLAYER_ENTER_UNIT = 20, S_EVENT_EMERGENCY_LANDING = 43, S_EVENT_MAC_EXTRA_SCORE = 51, S_EVENT_CRASH = 5, S_EVENT_UNIT_TASK_STAGE = 50, S_EVENT_WEAPON_DROP = 48, S_EVENT_MAX = 61, S_EVENT_LANDING_AFTER_EJECTION = 31, S_EVENT_PLAYER_LEAVE_UNIT = 21, S_EVENT_MARK_CHANGE = 26, S_EVENT_UNIT_DELETE_TASK = 45, S_EVENT_UNIT_CREATE_TASK = 44, S_EVENT_PILOT_DEAD = 9, S_EVENT_ENGINE_STARTUP = 18, S_EVENT_LANDING_QUALITY_MARK = 36, S_EVENT_REFUELING_STOP = 14, S_EVENT_PLAYER_SELF_KILL_PILOT = 41, S_EVENT_BDA = 37, S_EVENT_AI_ABORT_MISSION = 38, S_EVENT_LAND = 4, S_EVENT_FLIGHT_TIME = 40, S_EVENT_DISCARD_CHAIR_AFTER_EJECTION = 33, S_EVENT_TAKEOFF = 3, S_EVENT_REFUELING = 7, S_EVENT_PLAYER_CAPTURE_AIRFIELD = 42, S_EVENT_PLAYER_COMMENT = 22, S_EVENT_SCORE = 29, S_EVENT_MISSION_START = 11, S_EVENT_TOOK_CONTROL = 13, S_EVENT_PARATROOPER_LENDING = 32, S_EVENT_BIRTH = 15, S_EVENT_SIMULATION_START = 46, S_EVENT_MARK_REMOVED = 27, S_EVENT_HIT = 2, S_EVENT_DETAILED_FAILURE = 17, S_EVENT_ENGINE_SHUTDOWN = 19, S_EVENT_HUMAN_FAILURE = 16, }

Is there any chance of adding "troops" to the Dynamic Cargo system? It could work just like the Equipment section works... Add another tab and we can keep track of troop movement along with the other logistical stuff. null

On 4 occasions during the attached track, the AI aircraft I'm following (this is from a formation practice mission) performs a maneuver that is hard to describe. Basically, while in straight and level flight, it suddenly "slides" laterally approximately 50' (that's a guess) one left or right. It occurs during the track roughly at the following time points: 5:28 8:18 9:20 12:13 The last one is the most interesting. Not only is it the only shift to the left, but it also looks like the plane tries to turn before just sliding the rest of the way. It smells like the plane is somehow drifting off course and decides the correct the issue the brute force way, but that's obviously just a guess. Formation-post-update.trk

Thanks for the update, I appreciate it!

The behavior of AI aircraft when changing altitude between waypoints appears to have changed. I have no way to be certain exactly when, but I'd bet good money it was the DCS 2.9.6.57650 - 11.07.2024 update, this was when I first encountered it. I perused the changelog but found nothing that sounded like it fit. Prior to this update, and I admit this particular assertion is based on anecdotal observations (although a lot of them over a long period of time), AI aircraft would climb in a roughly linear fashion when changing altitude between waypoints. Essentially a straight line between the 2 points, arriving at the new altitude near to or at the waypoint. Subsequent to this update, this assertion is more firmly grounded in experimentation, AI aircraft are taking the express elevator to the altitude of the destination waypoint. In my experiment, I have a Hornet with 3 waypoints: 0 and 1 at 3000 MSL and 2 at 8000 MSL. As soon as he hits waypoint 1, he pitches up to 16-17 degrees until he hits the altitude of waypoint 2 (8000). How do I know this and why do I care? A guy named d0ppler (who seems to have disappeared) posted a great series of missions for formation practice, one of which for a very long time, I flew daily, and it was, without doubt, the single most helpful thing (for me) in learning DCS. For this reason, I was well-conditioned to the behavior of AI aircraft (at least one anyway) and when the update dropped, the change was immediately obvious. I would really like to be able to use this tool again, so I'm raising the issue. I can't say whether this change was an intentional change, a side-effect of something else, or an outright bug, but it is a change. I've included a track with the waypoints at the default 'Turning Point' setting. I ran it with 'Fly-over Points' but there was no observable change. The miz file is available. TurningPoint.trk

This is still going on. I fly CASE III every morning and am meticulous with my radio calls. Can anyone confirm that radios calls, or the timing thereof, are a variable in the process?

I agree with this!

Hey Nomad, I'm interested in learning more about what you guys have going on, what is the best way for us to get together and have a chat? Thanks, Grooveline