A Hamburgler Posted June 30, 2018 Share Posted June 30, 2018 Yes I believe there is, check out "mist.getGroupData(groupName)". I believe this will also give every units loadout. Edit: Something like this: local myGroupData = mist.getGroupData(myGroupName) -- gets all data for the referenced group name trigger.action.outText(mist.utils.tableShow(myGroupData), 25) -- will show data on screen env.info(mist.utils.tableShow(myGroupData)) -- will show data in log Yes I looked into this and does not return the payload of spawned units. The way they get the payload is by getting the group and unit IDs then matching them to a group within the mission file. But does not work if you spawn multiple units as their group ids and unit ids are different. So im seeing if there is possible another way to do this. Link to comment Share on other sites More sharing options...
Grimes Posted June 30, 2018 Share Posted June 30, 2018 Payload is tricky. We have Unit.getAmmo() which returns an itemized list of the ammo, but its not a breakdown of which weapon is on which pylon. The pylon data is whats needed to spawn the unit with an appropriate payload. So that data is only accessible to units placed in the mission file. Come to think of it, I have never tested spawning AI with weapons defined by anything other than the CLSID that defines the weapon. The best I could do within mist is to also search mist.DBs.dynGroupsAdded for payload data. But that only would work for dynamically spawned groups using mist because I cannot derive the payload data. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
A Hamburgler Posted July 2, 2018 Share Posted July 2, 2018 Payload is tricky. We have Unit.getAmmo() which returns an itemized list of the ammo, but its not a breakdown of which weapon is on which pylon. The pylon data is whats needed to spawn the unit with an appropriate payload. So that data is only accessible to units placed in the mission file. Come to think of it, I have never tested spawning AI with weapons defined by anything other than the CLSID that defines the weapon. The best I could do within mist is to also search mist.DBs.dynGroupsAdded for payload data. But that only would work for dynamically spawned groups using mist because I cannot derive the payload data. Damn but you would think by now ED would have some functions for us to return a units current payload. So if I start with 4 jdams and drop two and I run this functions it will return 2 jdams ect and which pylons they are on. Link to comment Share on other sites More sharing options...
Subferro Posted July 8, 2018 Share Posted July 8, 2018 Question regarding the teleportGroup function: I’m trying to set up a trigger that causes a carrier to teleport back to its original waypoint so that the player never has to deal with the carrier turning downwind. It sort of works, but static objects I placed on the deck despite being linked to the unit don’t show up when it respawns. Also I put true for the second parameter in teleportGroup, but the new ship isn’t findable on the same TACAN channel. Any way to make these two things happen? Link to comment Share on other sites More sharing options...
Wrench Posted July 16, 2018 Share Posted July 16, 2018 Waypoints/route Hey guys. I'm having a bit of trouble with route following using mist.goRoute. (Fixedwing waypoints) The trouble is that the aircraft doesn't make clean turns the wayt tyhey do using ME routes or even those created with CA. CA created Route: MiST Route: Results are about the same whether using 'turningpoint' or 'flyoverpoint' as the type in mist.fixedWing.buildWP. Carrier Script. Link to comment Share on other sites More sharing options...
Grimes Posted July 17, 2018 Share Posted July 17, 2018 Results are about the same whether using 'turningpoint' or 'flyoverpoint' as the type in mist.fixedWing.buildWP. Thats a longstanding bug of the scripting engine. AI given tasks via the scripting engine, for one reason or another, defaults to the flyoverpoint waypoint type for any task assigned during the mission. It works when you spawn an aircraft with that route assigned. But when you give it a new task after the aircraft spawns is when the bug occurs. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
Wrench Posted July 17, 2018 Share Posted July 17, 2018 Thanks grimes. Can I spawn then using a scirpted route, and have that read properly, or does it have to come from the .miz? Carrier Script. Link to comment Share on other sites More sharing options...
Wrench Posted July 17, 2018 Share Posted July 17, 2018 2nd question: Can I abuse the CA system to make the aircraft think it received the route from a Game Master, given that it will follow that route properly? Carrier Script. Link to comment Share on other sites More sharing options...
Delta99 Posted July 17, 2018 Share Posted July 17, 2018 I think what Grimes is saying is that no matter what way you do it via scripting you're going to get a "flyoverpoint" so until they fix that you are out of luck. My Missions: Valley Patrol Mission :: Valley Escort Mission :: A2A Engagements Link to comment Share on other sites More sharing options...
Grimes Posted July 17, 2018 Share Posted July 17, 2018 If you spawn a group with their route, it works. If you spawn a group then give them any route, its broken and uses fly over points. (as in having to use pushTask or setTask to give it to them. I don't know if CA routes are effected by this bug or not. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
Wrench Posted July 18, 2018 Share Posted July 18, 2018 They're not, that's what the first screenshot was from. I had actually taken that one after the scripted route. Are CA functions accessable via script? I couldn't find anything on the wiki, and didn't see anything in the CA Lua files that beared fruit. Carrier Script. Link to comment Share on other sites More sharing options...
Zayets Posted August 1, 2018 Share Posted August 1, 2018 Here's a question for Grimes, hope you have time to check if is true or not. I am writing the next sequence: local groupData = mist.getGroupData('MyGroup') groupData.groupID = newGID groupData.groupName = 'New Name' groupData.units[1].unitId = newUID groupData.units[1].unitName = 'New Unit' groupData.units[1].groupName= 'New Unit' groupData.units[1].groupId=newGID mist.dynAdd(groupData ) Everything works beautiful, checking on F10 map group name is the new name. I can't see the unit name but I can extract it and it looks ok. Problem comes when I want to pick up the group coming from the unit itself local findGroupName = Unit.getGroup(myUnit):getName() This returns the name of the initial group MyGroup and not New Name. Is there something I missed here? Ta [sIGPIC]OK[/sIGPIC] Link to comment Share on other sites More sharing options...
Zayets Posted August 4, 2018 Share Posted August 4, 2018 Right, I see there's no answer to my question above which probably is my fault being too specific. I have played more with dynAdd function and noticed that if I add a new group based on a model = getGroupData('MyGroup') model and then dumping the mist.DBs to the log both mist_DBs_groupsByName.lua and mist_DBs_MEgroupsByName.lua I notice they are identical. Moreover, mist_DBs_dynGroupsAdded.lua is empty. That despite the fact that I see the new groups on the F10 map and funny enough they have the new group name I have assigned them using model["groupName"] = 'NewGroup'. Which brings me to my question: what does clone supposed to do in the function call? Is this what I need to see the new group being created in the mist.DBs.groupsByName? mist.dynAdd{ units = table unitsTable, country = string/number countryName/countryIndex, category = string/number categoryName/categoryIndex, name or groupName = string groupsName, groupId = number groupId, clone = anything clone, } If so, how do I do that? Simply by assigning model["clone"] = true? I am asking because there's no example in the mist.DBs.groupByName Thanks in advance! [sIGPIC]OK[/sIGPIC] Link to comment Share on other sites More sharing options...
Grimes Posted August 5, 2018 Share Posted August 5, 2018 Clone acts as a flag to automatically generate a new groupName, groupId, unitNames, and unitIds if present. Usually it'll rename it USA GND 1 for groupname and USA GND 1 unit 1 for units. Can you upload the miz file so I can experiment with it directly instead of having to recreate it and potentially doing something slightly different that I don't get the same result. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
Zayets Posted August 5, 2018 Share Posted August 5, 2018 Thanks Grimes. Figured it out myself through many tries that clone gives a new name and a real new group in the mission. Basically that was what I missed from my function call. While we are at it, assigning a route to a newly created group is possible only through goRoute() function? WHich means that the group must be spawned? [sIGPIC]OK[/sIGPIC] Link to comment Share on other sites More sharing options...
Grimes Posted August 5, 2018 Share Posted August 5, 2018 You can spawn a group with a route or assign a new one after it spawns. mist.goRoute() is assigning a new route after it spawns and is done slightly differently by getting the groups controller and setting it as a new task. Spawning a group with an existing route is probably the best way to do it, at least for aircraft. One of the table entries for adding a group is called "route" and has quite a few entries possible for it. Here is the documenation on it: https://wiki.hoggitworld.com/view/DCS_task_mission The only difference as far as the formatting of that table is concerned is that spawning a group with a route, you just start it with the route entry. If you are assigning the task after it spawns you need the following at the start. This is more or less what the goRoute function does, it just creates that corrected formatting and assigns the task immediately. Mission = { id = 'Mission', params = { Here is a small bit of code of a route I just had laying around. Pretty much copied it directly out of a miz file. ["route"] = { ["points"] = { [1] = { ["alt"] = 2000, ["action"] = "Turning Point", ["alt_type"] = "BARO", ["speed"] = 138.88888888889, ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { [1] = { ["enabled"] = true, ["auto"] = true, ["id"] = "WrappedAction", ["number"] = 1, ["params"] = { ["action"] = { ["id"] = "EPLRS", ["params"] = { ["value"] = true, ["groupId"] = 1, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [1] }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] ["type"] = "Turning Point", ["ETA"] = 0, ["ETA_locked"] = true, ["y"] = 648400.296, ["x"] = -291732.52314285, ["name"] = "DictKey_WptName_8", ["formation_template"] = "", ["speed_locked"] = true, }, -- end of [1] }, -- end of ["points"] }, -- end of ["route"]] The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
july865 Posted August 7, 2018 Share Posted August 7, 2018 (edited) i would like to thank Grimes/Speed for the hard work put in creating MIST. im sure you have been thanked a 1000 times over. but i'll make it 1001 :-) on the GitHub repository "ReSpawn_example" was a life saver. reduced a wall of code to barely nothing. can someone point me in the right direction to make the unit hidden until called upon with an F10 command, but still remain an unlimited number of spawns? Sample miz attached . respawn_example.miz Edited August 7, 2018 by july865 including Speed Asus x99, i7 5930k, 32g mem, MSI 1070GTX, 970 Samsung M.2, LG 35in Ultra-Wide, TrackIR 4 Thrustmaster Warthog HOTAS [sIGPIC][/sIGPIC] Link to comment Share on other sites More sharing options...
Zayets Posted August 7, 2018 Share Posted August 7, 2018 Unfortunately you can't make it hidden, only invisible to AI. I could not access hidden property of an object already spawned. Yes, thousand thanks to Grimes/Speed for MIST. I would like to repay them somehow, maybe enhancing the documentation which is really brief, maybe adding some working examples for the functions and so on. MIST saved me writing many lines of code as well, many functions I wanted to create were already there. [sIGPIC]OK[/sIGPIC] Link to comment Share on other sites More sharing options...
july865 Posted August 7, 2018 Share Posted August 7, 2018 (edited) my apologies to Speed for not including him. I had tried "Late Activation" with the script but it only worked for 1 respawn. Changing the Time function just wouldn't work at all. Cant recall where, but i had play on a server that went on for hours with respawning units at will, using the radio menu. all units where invisible until called upon. Edited August 7, 2018 by july865 typo Asus x99, i7 5930k, 32g mem, MSI 1070GTX, 970 Samsung M.2, LG 35in Ultra-Wide, TrackIR 4 Thrustmaster Warthog HOTAS [sIGPIC][/sIGPIC] Link to comment Share on other sites More sharing options...
Zayets Posted August 20, 2018 Share Posted August 20, 2018 Can you upload the miz file so I can experiment with it directly instead of having to recreate it and potentially doing something slightly different that I don't get the same result. Hi Grimes,attached the mission for test. I am having one group with late activation and getting the group model from it. Then I assign the route on the fly and modifying the route points in the process. Group spawns alright but at the initial location of the group I take the model from even if the route points is different. Group just spawns , moves for about one minute and then stops, mind you from the initial location not the one I gave it in the route table.tst.miz [sIGPIC]OK[/sIGPIC] Link to comment Share on other sites More sharing options...
Grimes Posted August 21, 2018 Share Posted August 21, 2018 They aren't moving in that sample file at all. Mostly because it looks like the spawned group never gets the route. An important thing to note about route building is that. A. Its best to set the start waypoint at roughly the coordinates of the first AI in the group. In the past the AI have just decided to ignore routes if the WP wasn't like that. B. Ground AI might "give up" on orders if they can't reach the destination by a given ETA. Basically a minute after they fail to reach a WP at the specified time they just stop and give up. Its a noticeable problem with amphibious units where the ETA is often based on a speed the units can't reach over water. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
Zayets Posted August 21, 2018 Share Posted August 21, 2018 (edited) Route is given by using group.route = table route at the time the the table needed to dynAdd the group is created. Basically I am passing before dynAdd is created. Basically, this is the function local groupPrefix = 'XGRP' local unitPrefix = 'XUNI' function DeepPrintTable(e) -- if e is a table, we should iterate over its elements if type(e) == "table" then for k,v in pairs(e) do -- for every element in the table print(k) DeepPrintTable(v) -- recursively repeat the same procedure end else -- if not, we can just print it env.info(e) end end function generateVehiclesRoute() local startPoint = {} local endPoint = {} -- Decide if they will move off(0) or on(1) road local routeChoiceRandom = mist.utils.round(mist.random(0,1)) -- Pick one zone to spawn the group local pickedZone = 'SpawnGround_' .. mist.utils.round(mist.random(1,6)) if routeChoiceRandom == 0 then startPoint = mist.getRandomPointInZone(pickedZone) endPoint = mist.getRandomPointInZone(pickedZone) routeChoice = "Off Road" else local nearestRoadStart_x, nearestRoadStart_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y) local nearestRoadEnd_x, nearestRoadEnd_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y) startPoint = {nearestRoadStart_x, nearestRoadStart_y} endPoint = {nearestRoadEnd_x, nearestRoadEnd_y} routeChoice = "On Road" end local vehiclesRoute = { [1] = { ["alt"] = 66, ["type"] = "Turning Point", ["ETA"] = 0, ["alt_type"] = "BARO", ["formation_template"] = "", ["y"] = startPoint.y, ["x"] = startPoint.x, ["name"] = "STA", ["ETA_locked"] = true, ["speed"] = 5.5555555555556, ["action"] = routeChoice, ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] ["speed_locked"] = true, }, -- end of [1] [2] = { ["alt"] = 64, ["type"] = "Turning Point", ["ETA"] = 164.7057218182, ["alt_type"] = "BARO", ["formation_template"] = "", ["y"] = endPoint.y, ["x"] = endPoint.x, ["name"] = "END", ["ETA_locked"] = false, ["speed"] = 5.5555555555556, ["action"] = routeChoice, ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { [1] = { ["enabled"] = true, ["auto"] = false, ["id"] = "GoToWaypoint", ["number"] = 1, ["params"] = { ["fromWaypointIndex"] = 2, ["nWaypointIndx"] = 1, }, -- end of ["params"] }, -- end of [1] }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] ["speed_locked"] = true, }, -- end of [2] } return vehiclesRoute end function generateVehiclesModel(modelType) local vehiclesGroupId = mist.getNextGroupId() local vehiclesGroupName = groupPrefix .. '-' .. vehiclesGroupId if modelType == 'easy' then groundModel = mist.getGroupData('easyGroundModel') env.info('Easy Ground:' .. #groundModel.units) elseif modelType == 'medium' then groundModel = mist.getGroupData('mediumGroundModel') env.info('Medium Ground:' .. #groundModel.units) elseif modelType == 'hard' then groundModel = mist.getGroupData('hardGroundModel') env.info('Hard Ground:' .. #groundModel.units) end groundModel["clone"] = true groundModel["route"] = generateVehiclesRoute() groundModel.groupId = vehiclesGroupId groundModel["groupName"] = vehiclesGroupName local vehiclesUnitId = mist.getNextUnitId() for i = 1,#groundModel.units do groundModel["units"][i]["name"] = unitPrefix .. '-' .. vehiclesUnitId groundModel["units"][i]["groupId"] = vehiclesGroupId groundModel["units"][i]["groupName"] = vehiclesGroupName vehiclesUnitId = vehiclesUnitId + 1 end return groundModel end Edited August 21, 2018 by Zayets [sIGPIC]OK[/sIGPIC] Link to comment Share on other sites More sharing options...
Grimes Posted August 22, 2018 Share Posted August 22, 2018 That code is different from the one from the attached mission file. Which the new code didn't work with the old mission. I figured it out and modified as needed. By the looks of things it works when given the off road tasking. The AI go to the first waypoint and then loop their route accordingly. What is interesting though that it appears that the AI completely ignore objects, speed, and group formation to get to and return to the initial waypoint. Best guess is that is a DCS bug that needs investigating. The on road tasking is what is causing the strange result. Using CA to select the group it appears they are wanting to go to the tip of land near the Kerch Straits in the far western side of the populated map. Did some experimenting and figured out the issue. local nearestRoadStart_x, nearestRoadStart_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y) local nearestRoadEnd_x, nearestRoadEnd_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y) --startPoint = {nearestRoadStart_x, nearestRoadStart_y} startPoint = {x = nearestRoadStart_x, y = nearestRoadStart_y} --endPoint = {nearestRoadEnd_x, nearestRoadEnd_y} endPoint = {x = nearestRoadEnd_x, y = nearestRoadEnd_y} routeChoice = "On Road" The commented out part is your code. Basically the table looked like {[1] = xValue, [2] = yValue} instead of {x = xValue, y = yValue}. So I think the scripting engine didn't know what to do with that and tried to create a waypoint from the nearest road at map origin. Worth mentioning is that your code to assign the point is running the mist.getRandomPointInZone twice. local nearestRoadStart_x, nearestRoadStart_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y) So it is generating an X, Y coordinate and using the X value, then generating another coordinate to use the Y value. Technically there is nothing wrong with that, its just doing the work twice for a random result. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
Zayets Posted August 23, 2018 Share Posted August 23, 2018 Thanks Grimes for your time. Did the necessary change and a slight difference in units behavior occurred. Group is not stopping and it looks like it goes to point 1 in route. Unfortunately it does not spawn in point 1 as I wanted, it acts like the group receives a go to route command from the point in which is spawned (which is not point 1). Well, i guess I will have to go for other approach, I am thinking to use clone in zone and then assign a go to route command. Maybe this will work better in this case. As for the function being called twice, I got lazy when testing and leave it that way. Again, thanks for the check. It looks like I modified the script but not reloaded in the mission, that's why you ended up with the wrong file. [sIGPIC]OK[/sIGPIC] Link to comment Share on other sites More sharing options...
Grimes Posted August 23, 2018 Share Posted August 23, 2018 Yeah you gotta iterate through the units table within the group to create a new spawnpoint for them. The first waypoint for the group is just its waypoint, the units have their own coordinates that are used. The mist.teleportToPoint() function uses something like this where newCoord is the coordinate generated and newGroupData is the group table. It creates an offset point and changes the spawning position for the group. local diff = {x = (newCoord.x - newGroupData.units[1].x), y = (newCoord.y - newGroupData.units[1].y)} for unitNum, unitData in pairs(newGroupData.units) do newGroupData.units[unitNum].x = unitData.x + diff.x newGroupData.units[unitNum].y = unitData.y + diff.y end The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now