Grimes

The outSound and radioTransmission script calls are the only way to output sound and both require for the sound files to be embedded within a given miz file. You can certainly create and assemble custom messages if you have enough individual lines of dialog created, I've done this in my On Station mission. But really you have to look for mods to be able to do what you are asking. The following link comes to mind but there are a few who have also used SRS to transmit stuff like ATIS over a given frequency.

Looks like the taxi issue and runway choice has already been fixed. Just gotta wait for the next update to the Channel map.

Could modify that weather script to set the time however you want. Keep it if the values happen to be within a given range and adjust it if its outside that range. Or just comment out the bit where it modifies that entry or make it some static value.

Net is an entirely separate lua environment from mission scripting. Without modifications they can't communicate with each other. For instance slmod modifies missionScripting.lua and opens a socket that allows it to send data from one to the other. Slmod does have what you ask built in via a do script slmod.chatmsg('Your Message Here'). Only thing is that slmod has to be installed on the server running the mission in order for it to work. Aside for that you'd have to modify the game in much the same way.

May have taken instructions of North more than west for the corner of the base everything was at. But placing everything on the western end was actually a fair bit more efficient than what I initially tested and recorded. Seemed to be pretty much par for AI take-off behavior. Also at least for that base AI can use all 4 runways for take-off. https://imgur.com/uPmpUoR

Knowing which airbase and which spawns would suffice in getting started in testing it.

Correct. But again you can keep everything self contained within a single script call, change players to be global, or whatever else you want in terms of setting it up. CD1 would have to be declared someplace to be a string of the unit's name. So it could be createPlayer('f18slot1') or local CD1 = 'f18slot1' createPlayer(CD1) When it runs createPlayer twice lets say, then the players table could look something like: { [1] = {unitName = 'f18slot2', unitObj = {obj}, playerName = 'Bob', atWP = 1, type = 'FA_18_HORNET'}, [2] = {unitName = 'f18slot5', unitObj = {obj}, playerName = 'whatever', atWP = 1, type = 'FA_18_HORNET'} } It is a little flawed because depending on the rules of how createPlayer is executed and if you don't delete anything then there could be multiple entries with the same unitName, which with how the unitSetAtWP function is written would just set that to the first entry it found with a matching unit name.

Hidden or not existing (being destroyed) are the only values that impact whether the objects show up on SA page when a given aircraft spawns. Late activated groups still exist even before they are spawned. This is not a bug.

It doesn't strictly need to be an object in the sense of object oriented programming. You could just create a table and discrete functions that get passed the table that can manipulate the table or return a value for an entry within that table. It fits together depending on how you want to set it up, generally it is mostly a question of creating local or global variables and where you want to run the code. Anything set to local is only accessible within a given block that it is defined in. However you can still make a global function that has access to it as long as it is also defined within the same block. This would be useful if say you were to do a bit of a "hybrid" of using triggers and the scripting engine. You can always make it global anyway and always have access to it, but things in lua tend to run much smoother the fewer global variables you have. A quick dumb example. This bit would be in a do script. local players = {} function createPlayer(uName) local obj = Unit.getByName(uName) local pEntry = {unitName = uName, unitObj = obj, playerName = obj:getPlayerName(), atWP = 1, type = obj:getTypeName()} table.insert(players, pEntry) return pEntry end function unitSetAtWP(name, wp) for i = 1, #players do if players[i].unitName == name then players[i].atWP = wp end end end Then after it is declared you could call either createPlayer or unitSetAtWP anywhere. If you removed the local in front of players then the table itself could be accessible from anywhere. Its slightly convoluted, but within a block that you call createPlayer() you can make it a local variable within there that is a reference created by a global function of a local table from another block. I guess I'm trying to say is you can make everything global, but you can also make almost everything local except for a few global functions to transfer data between each block as needed. In terms of how I make stuff it tends to be as self contained as possible. If there is some config, customized, or is a general "tool" for others to use there will typically be something globally accessible. If it were some bespoke script I don't really intent to publish then it can all be in one big lua file that just needs to be loaded and has all the code within looped and kicked off on its own.

Part of the problem is in the documentation and potential problem you can encounter is a DCS AI issue. The wiki mist.groupToRandomZone erroneously has the disable roads entry but in the code it isn't actually passed or used by that function. While groupToPoint does use it. I'm not sure why it doesn't use that input at all or why it wasn't included when originally made, but that could be rectified. The AI issue is that sometimes the AI will just refuse to drive it. I'm still investigating this but it partially seems like vehicle type, distance travelling, and size of the group seems to impact it.

Huh, well look at that. Its giving your newly occupied aircraft full fuel while your old one just goes to 100% internal fuel even if you have external tanks on. Noticed when I switched there was also a new "birth" event, which leads me to believe that its effectively spawning a new aircraft.

Made it a little more clear on the wiki https://wiki.hoggitworld.com/view/MIST_groupToPoint So a true value at the end for that should do the trick. Alternatively you can build the route fairly easily on your own. local path = {} local group = Group.getByName('someGroup') local speed = mist.utils.kmphToMps(30) path[#path + 1] = mist.ground.buildWP(mist.getLeadPos(group), "Vee", speed) path[#path + 1] = mist.ground.buildWP(trigger.misc.getZone('whatever').point, "Vee", speed0) mist.goRoute(group, path)

Would have to be a server side mod that uses the server API. Either use chat to say which team you wanna join or just associate it with the coalition a player selects first. Save their UCID in a table with the coalition they are allowed to join and some time information for when they last joined a slot or most recently in a given slot. Use the callback onPlayerTryChangeSlot to either allow or block the players selection within each given coalition.

Correct. Now switch Georgia to red and you will note that the old Russian equipment will service the helicopter but the US made stuff won't. Its annoying and should be disabled, but that is how FARPs have worked since Black Shark released.

Yeah that is odd, in the editor it is set to another parking spot with no statics in front of it. Reported.

Reproduced it. Weirdly the behavior isn't consistent with different unit types.

It is not a bug, but also is a bug. Units from the red column do not provide services when the unit is on the blue coalition and vice versa. If you switched everything to red in that sample mission then the old Russian trucks would rearm you but the M8181 won't. So in that context it is working as intended, however the invisible farp on red is not behaving as expected.

Best guess is the server doesn't have the livery. If its a dedicated server then all you need is the description.lua for a given livery. Same goes for if a player is hosting it, but they'd need the textures so it looks right. Otherwise the server loads the mission, sees that some unit is using "livery X", checks its files and can't find that livery, thus is loads whatever is default for that unit and country, then tells everyone connecting to the server that the unit is using the default livery.

Blocking their path with ground units has worked in the past, but it has also become broken from time to time. So could just place a humvee in front of their parking stand of the group leader and the AI aircraft should remain stationary until that humvee moves out of the way or is removed.

I think it fell into the "just get it working" category of coding and was having some problem or another with it the other way around. Fast forward several years its something I'm not sure I wanna change because I don't know how many missions it'd mess up purely by someone updating mist in it. The thing is it is a wrapper function that calls mist.groupToRandomPoint to do the actual work. Big difference is that function accepts a table and has the road setting labeled abit better, while groupToPoint is several input values.

I can't think of a single game that has private servers and a policy anything like what you propose. It is just a bad idea on so many levels that its worse that I replied saying it is a bad idea rather than leaving it be.

Posting a miz file would be helpful to get an idea of other factors that might be at play.

Which aircraft?

There is no such functionality that exists like that in the scripting engine. The closest thing to it is to respawn the aircraft, which doesn't work on "client" aircraft and thus only works in single player. Plus it'd be like a fresh airstart jet where you can't read or set the avionics to whatever state they were last in.

Probably just did it with the triggers. Its pretty easy to setup. Place an AI aircraft, tick the box for "late activation". Then go into the triggers and make a trigger that occurs sometime around mission start for "Radio Item Add". Make one for each group you want to spawn in, give it a unique name since that is what will be displayed, and set each's flag value to be something unique. Then for however many groups you have make another trigger that is basically Once> Flag X True> Group Activate (whatever group) and Radio Item Remove. Basically what happens is you select the radio item, which sets a flag, which when true will activate a group, and then remove that option from the menu. You can also do that with the scripting engine and also make things a whole lot more complex. The upside of doing it via the editor is it is simple, but the groups can only be activated once. With scripting that limitation doesn't exist, but as I said, it can be a bit more complex.