-
Posts
9599 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Events
Everything posted by Grimes
-
Me being weird I don't like using world.searchObjects for getting a list of objects in an area, especially if that area is larger than a few km radius. However that mostly stems from the very noticeable hitch that can occur when searching for world objects over a densely populated area if the search area is large enough. The other way would be to iterate a table of known units, see if they exist, and get the distance from a given point. Depending on your needs you can vary the speed. For example the bubble script on Grayflag has a curated list of units and weapons that it tracks. Objects get added and removed via event handler. It only runs getPosition on each object every few seconds, which means its not ultra precise, but it is precise enough. Each bubble, think of it like a trigger zone typically around sams, will check its distance against the known object list. Depending on that distance it'll reschedule the check to occur slower or faster because the point is to allow a sam to "exist" in the mission by only spawning it in when aircraft are near. Anyway if the bubble is spawning in a short range sam and the nearest unit is 100km away it doesn't exactly need to update at a faster rate just to know the nearest unit is now 99.4 km away. But no I haven't benchmarked it. I suppose it is a question of the distances involved and what information you care about. world.searchObjects on units will return all units, you'd have to sort for coalition and category if that mattered. Whereas if you only want to know which of 10 helicopters are in a zone it'll probably be faster to check the distance with a for loop and adding them to an table of in zone units.
-
Which buildings do this? They should only remain dead until you exit the mission.
-
mist.teleportInZone("carrierGroup" , "newZone" , false , 1 , { offsetRoute = true} ) Should do the trick. It'll teleport to the zone with the name "newZone". The radius is 1 so basically it'll be exactly on the center of the zone. It passes a table with the value offsetRoute = true which means it will grab the route from the mission, including any tasks assigned, and will offset the position of the points. If WP2 is straight east from WP 1 for 50km then it'll be offset 50km east from newZone. It doesn't check for any terrain issues, that'll be on you to make sure the offset waypoints are on land all a sudden.
-
Teleport should keep the unitId value for each unit, that is the main thing that matters when "teleporting" a ship or other objects that people spawn on. Just know that anyone on the ship when it spawns somewhere else will probably fall into the water. Unknown what'll happen to any static objects you have on the deck.
-
Spawning Transports/Units with Troops Inside at Start?
Grimes replied to Daemoc's topic in Scripting Tips, Tricks & Issues
The embarking task appears to have a "From Start" checkbox. Assuming the groups are placed in the editor it does work with late activation. I would need to test it when spawning AI with scripting to see if the task still works with dynamically spawned AI units. -
The annoying feature of datalink being locked to the group now no longer exists thanks to the datalink setting. Granted you'd have to set them up one by one if you were to limit aircraft to one per group. Carrier recovery is weird as is anyway due to it occasionally being bugged and it always assumes that aircraft in a group are recovering together. Each player should still be able to do their own comms with the boat and you should still get correct grades if all contact the boat, do a case 1 as a group, and talk to the LSO.
-
In triggers Flag Set Random Value is not random
Grimes replied to Richrach's topic in Mission Editor
Ran it 100 times and got the following outputs. Left is the number and right is how many times it got selected. nullJust showing to indicate that it is kind of random and the first selected item was always different for me. You could try increasing the range, random 0-100 with the flag ranges appropriately scaled might yield sufficiently random results. In the past the lua version of math.random had a tendency to randomly choose the first and last possible value much less often. Keep in mind I'm talking about running math.random 10000 times and see what the results were. Which doesn't quite jive with what you were experiencing here. -
It is a global setting. The only thing you can effect an aircraft's GPS systems is with the KA-50's ABRIS and honestly I have no idea if that is still a feature.
-
Somewhere in the terrain files, probably in the AirfieldsTaxiways folder, defines all of the parking spots at each airbase. Parking availability is dependent on the length, width, and height of the parking spot and of the aircraft selected. There is a https://wiki.hoggitworld.com/view/DCS_func_getParking function but it doesn't return the dimensions and the "term type" returned isn't exactly reliable to know the size of parking.
-
The condition wouldn't become true because the flag is back to 0 and therefor "off." I guess the question is if you want to know a flag has been true. If so then you could set an additional flag, or increase its value by 1, each time that the flag you care about was set. set flag 1 true and flag increase "flag1WasSet" by 1. Alternatively you can use scripting to exploit it further... do script: flagWasSet = timer.getTime() Would give the precise time the flag was set, you can then use that value for whatever purposes you want.
-
You can change ROE or alarm state, then toggle whatever you set back to default. Problem being they won't engage anything else until triggered to do so.
-
This setting applies to engaging airborne targets.
-
For the Apache FCR you should be able to use getDrawArgumentValue. https://wiki.hoggitworld.com/view/DCS_func_getDrawArgumentValue Although it might have weird results because people can have an FCR be forced onto the aircraft as part of the livery, but if it wasn't setup in the miz to have an FCR it would be non functional. Likewise it might change when the FCR gets added to the loadouts.
-
Getting around unwanted AI RTB
Grimes replied to Terminator357's topic in Scripting Tips, Tricks & Issues
As long as you are using pushTask and also not pushing a new mission task to the unit it *should* return to its orbit point once all pushed tasks it has is complete. If it was setTask then that task will overwrite any other task it has and I would expect the AI to return to base if they weren't given any other tasks. If you were giving it a new mission task then I would append a waypoint with the orbit task to the original orbit points so that it is part of the route. -
Link unit would be the unitId of the carrier, not the groupId. Also the groupid and unitId of the static object should be unique, which you could comment out and allow DCS to figure it out for you or I'm sure there is some function in moose that would give you an unused id for either. Might also be a good idea to wait a tick or two before spawning the statics on the spawned ship. I'd have to look through my test code to see if I had made something to verify it works on spawned ships, pretty sure I did, but it wouldn't have used moose, so I can't help on that part of it.
- 3 replies
-
- statics templates
- code
-
(and 3 more)
Tagged with:
-
Not getting 'weapon' data for event S_EVENT_HIT on server?
Grimes replied to moggel's topic in Mission Editor
You need to check for its existence first. It is inconsistent in returning in MP, but it can return. In SP it is much more consistent. -
Yeah looks a little bugged. You can get expected behavior by directly passing the markId that is associated with each segment of the line. local rtn = mist.marker.drawShape("lineTest") -- Then latter you can pass the markId value associated with each shape. for i = 1, #rtn do mist.marker.remove(rtn[i].markId) end
-
[LUA/MOOSE-CLASS] Apache/George AI
Grimes replied to Ojemineh's topic in Scripting Tips, Tricks & Issues
Best guess is periodically running world.searchObjects within a set radius of the helicopter based on altitude then land.isVisible to check visibility and probably an azimuth to verify the target is "in front" of the aircraft. Add those units to a list and if it is new then "announce" to the player via some text to speech. And then some coordinate formatting and other stuff for the messages. -
Attack Group, "expend" parameter work around
Grimes replied to Terminator357's topic in Scripting Tips, Tricks & Issues
Could try engageUnit. https://wiki.hoggitworld.com/view/DCS_task_engageUnit It doesn't necessarily require the previous task to be completed before the AI is allowed to engage any other valid targets. As for the weapon flags, you cannot really tell AI to prioritize one weapon over another if they are both governed by the same waeponType value. -
Attack Group, "expend" parameter work around
Grimes replied to Terminator357's topic in Scripting Tips, Tricks & Issues
Three things. 1. It would be good practice to not use the name of any of the main object classes as a variable name. for i = 1, uObj in pairsj(targetTable) do would be better. Or even just a lower case unit. 2. You don't need to get the name, then use that string to get the unit object, so you can get the unit id. You already have the unit object. Target1.unitId = uObj:getID() would work. 3. If AI refuse to attack whenever you have a set weaponType it is good to try other weapon enumerator values. I'd try 1835008 for tactical ASM or or 262144 for fire and forget ASM. Its possible that "anti tank" missile is more in line with any of the ground launched ATGM like a TOW. I don't know anywhere in the files where it explicitly says "weapon has X weapon flag value". You just gotta try different things to figure it out. -
missionCommands.addCommand not passing arguments?
Grimes replied to ShuRugal's topic in Mission Editor Bugs
It doesn't automatically unpack any table passed to a function. Generally its a good idea to create a wrapper function that will then manipulate the values passed and call the expected function. Basically add ctld.JTACAutoLase to the values passed in the table and create another function that then calls ctld.JTACAutoLase with the other parameters. Though you could try: local subN1 = missionCommands.addCommand('JTAC Activate', subR1, ctld.JTACAutoLase, unpack({ 'JTAC1', 1688 })) -
They aren't in the same group. See its unit 1 of 1. That means you have unit 1 selected in the group, which has only 1 unit in it. Use the + icon or the > button on the right to add units to the group. + inserts a unit at whatever index you are at to the left. Which means what was unit 1 becomes unit 2. Where-as if you add the unit via > it adds the unit to the end of the group.
-
One of the icons on the toolbar opens a UI that you can select the code used for the syntax highlighting. Its the icon that looks like <>. local seadAsset = missionCommands.addCommand( 'SEAD' , requestAsset , request, {type = sead} ) The 3rd input for that function is the function to run. You had it as mist.respawnGroup, which can work, but not with what you sent to it. However you want it to run the request function. Which will then in turn run the mist function with the correct inputs.