Grimes

Mist is meant to supplement the base scripting engine where the majority of the functions are related to getting and organizing data in a useful way but still relies on you using the base functions within the script. There are a few functions that try to simplify complex functionality like mist.respawnGroup and some of the flagFuncs. There are functions in mist that have scripting counterparts where it really doesn't matter which one you use, while there are others where things are executed a little differently. For instance math.deg and mist.utils.toDegree are identical, the mist version exists because I was adding a bunch of converters and figured it should exist. On the other side of the spectrum the differences between mist.dynAdd and coalition.addGroup are quite extensive. Simply put mist.dynAdd is overloaded to populate any missing data other than coordinates and unit type. It'll generate new ids, names, heading, etc and it'll save that data to be added directly to the mist DBs because there is some data for dynamic groups that isn't accessible. Statistically math.random has a tendency to choose the first and last possible values less often. I'd argue that it is a use case question because depending on what you are doing it could be more noticeable. Picking a random number between 1 and 10000 to add a randomized distance or altitude for a flight wouldn't cause much of a problem. Picking a random number to spawn a given task that are always in the same order then yeah maybe you spent the most time on the first task and wonder why it gets picked less often. See the screenshot, both tests called the respective .random function 1000 times and it shows the distribution. The message is formatted as the number and how many each function returned that value; "Number : math.random : mist.random". Anyway the distribution bothered me even though it isn't likely to be that big a deal and I wrote some code to try and balance the result. Moose takes the object oriented programming approach where literally everything becomes an object with its own set of sub-classes. You could probably write a script that exclusively just makes moose calls without directly calling any function from the DCS scripting engine yourself. Moose in the end would use Unit.getPoint or whatever but you wouldn't need to.

You might be able to but it'll only work for the host. Might be best to use the Add Other Command and have your trigger respond to the flag that gets set with that.

It is setting the value, its not adding or subtracting at all. You set the weight back to zero if you want there to be no cargo weight. It also sets in gradually over a second or so.

For reasons beyond my understanding it isn't part of the unit class. Instead it is in trigger. Fun part is it works with most aircraft. https://wiki.hoggitworld.com/view/DCS_func_setUnitInternalCargo

I don't think it ever has because there isn't much logic to how they disperse. It is completely random. So there is as much a chance as a tank shooting at another tank from the front, the group disperses, and then some decide to expose their rear to the enemy.

Likely it is a combination of when the map was made and depth not being an issue for the longest time. That said there are parts of the Persian Gulf that are extremely shallow in reality. As for workarounds small ships might be ok. There are also the old ships from LOMAC where they don't actually have a hull below the water surface, therefore should be able to sail where there is almost no depth.

Yes it tends to be how lua serializes tables. The same occurs if you do something like `for index, freq in pairs(Radio.channels) do` then if you print the values it'll be out of order. Fun part is it can be out of order in the same pattern on multiple runs. You'd have to use `for i = 1, 20 do` to get the values in order. Might be best to just write something that'll make the changes automatically.

I said it was reported and I've tried to give it some attention, but other than that I can't do much at all about it unfortunately.

No fire at point is just to engage at exactly a single point in 3d space.

Likely doesn't think their gun can do any damage to the target ship. Try doing the task for "fire at point" or no task at all because if the AI is capable of damaging a target with their weapons they will fire automatically. Also the attack group task for ships is more for telling them to attack ships with anti-ship missiles that they currently can't detect.

Yeah, a track file has the mission embedded into it. Assuming you didn't change the livery via the re-arm menu you can change the default livery. Either opening the track in the mission editor, making the change, and re-saving it as a track or opening the miz via zip program and editing it that way should work.

1. Best place to get UCIDs are from the stats file. You can also setup a password that an admin can use to register themselves as an admin on the server or use a chat command as an admin to add another player. "-admin add <player name>" typed into chat from any admin will add that player. 2. A format use throughout slmod for this sort of thing is basically: Admins = { ["sahsjkadhjasduiasufhiosf"] = "Me", ["jafogopjakjop4235krj2kl4j23"] = "myFriend", } -- end of Admins It is done this way because it is much faster to access for lua. 3. The admin list is reloading on mission change, so you can just update it that way instead of restarting. It basically loads that file, gets the data, and then closes it for further edits.

It is a problem with the lantirn.

Reported.

If you find the values that moose uses to call https://wiki.hoggitworld.com/view/DCS_func_addStaticObject or https://wiki.hoggitworld.com/view/DCS_func_addGroup then by all means report a bug. But do try to report scripting bugs using as direct function calls as possible.

Second waypoint only matters for racetrack orbits, but doesn't change the turning radius. Slower is smaller. Donno if altitude plays into things. And if an aircraft is refueling it shallows the bank angle slightly which makes the radius even larger.

Radius depends on the speed that is set.

I think it is a general ground AI bug and not something specific to sam sites because I was able to get similar behavior with other unit types. That said there are some very weird behaviors occurring. This applies to every ground group: When given a route the AI will want to get into the formation set by the route, which means that each unit will move to where it is expected to be. At first I thought that was what was happening where the alarm state task delays the hold just long enough for the route to "begin" which results in the AI trying to get into formation. However the behavior occurs with just the hold task. One way to counter-act this was to add a template option to the hold task, specifically the "default" template. This is supposed to force the AI into the formation the group starts in, but the AI still ignored it. Will do some more tests and get it reported.

You should never see the effects of the removal trigger from the confines of the editor. It should only be seen in game or from F10 map after the trigger executes. When you load back into the editor at any point it should be restored to the default world state. There are no limits to the number of mission start triggers you can have.

Copied the image from another thread which might be tangentially related where certain bridges on Syria are actually terrain and not objects. Most bridges in DCS will look something like this. The "bridge" as far as objects are concerned is the flat surface that spans the gap. The abutment is simply part of the terrain and may or may not be textured to look appropriate with a bridge. Some bridges may consist of multiple objects and therefore segments can be destroyed. As far as I am aware bridges are just another world object and have nothing special about them with regard to damage. Well they could be special in the sense that they are thin and elevated which means a delayed fuse won't directly cause it to explode on the object.

AFAIK you can't. That is only if easy radios are on and you didn't select the right radio when trying to contact something.

Yeah should be doable. After a quick look at the load function it might make more sense to make a new command for listing the folders, which you select and then it goes in and list the missions with the same load command. So something like: -admin folders -admin f1 -admin load1. Would see if a 2nd input could be done to directly load a folder if you know the name. No they are not available within the mission lua environment. You can add custom stats entries via slmod.customStat but that is all.

It should automatically assign a new route once it reaches the end since that function is supposed to add a script to the last waypoint to execute the patrol function again.

The intercept aircraft's option to set its missile range to max is waiting on the attack task to complete before executing. The other two tasks are enroute tasks which means the AI will do that task if they detect the target, but will also execute other tasks in their queue. Hence their settings are to fire at max range while intercept is still at default. Interesting bit is how altitude impacts the results. AI fire at similar ranges but due to lower drag at higher altitudes the missile can hit. It was enough of a difference that between the altitude you set of roughly 7500m to what I initially did to recreate it at 8000m the missiles would hit. I think it might be more of a weapon issue with the MICA needing to be tuned. Tested with a a few other A2A missile types and max range shots all resulted in kills no matter the altitude set.

This was discovered and reported on Saturday.