-
Posts
9668 -
Joined
-
Last visited
-
Days Won
11
Content Type
Profiles
Forums
Events
Everything posted by Grimes
-
Airbase, new scripting function getRunways for Airbase DCS object
Grimes replied to sunski34's topic in Mission Editor
https://wiki.hoggitworld.com/view/DCS_func_getRunways -
unit_push_task_fall_back.miz Found it. Interestingly the flight originally had an orbit task and when every unit was given a pushTask to attack, when they completed it they all formed back on the leader doing an orbit. However the orbit positions had changed completely. Removing the orbit task saw the whole group RTB to nearest. Anyway my memory was correct. It assigned a task to the group controller and then to the remaining 3 unit controllers.
-
1. You might need to specify the weapon type in order for expend to be valid. weaponType = 2147485680 ought to do the trick. Additionally the boolean for attackQtyLimit should be required for the limit to be used. That was missing from the wiki for some tasks. 2. I know there are some quirks to assigning tasks to a unit controller and trying to get certain expected behavior out of the AI. I'd have to search through the archives because I did test this several years ago for splitting up a bunch of JDAM targets so the AI can engage quicker. I vaguely recall I assigned the task I wanted the group leader to do to the group controller and then iterate through the other group members to push their own set of tasks to their unit controllers. Might have been something along the lines of pushing a unit task to each unit overrides the group mission task. If the group leader still has their own mission task then the rest of the flight is aware of it and is able to reform on the leader. Otherwise they have no unit level mission and RTB.
-
Can't replicate the group stacking up like that. Can you post a mission or track file where it happens?
-
Trying to get Tu-22Ms to salvo fire ALL their missiles...
Grimes replied to AvgeekJoe's topic in Mission Editor
No problem. It mostly only impacts SEAD and anti-ship tasking where self defense against missiles can play a role. If it was a lower explosive anti-ship missile you might've seen more expected behavior of launching several at the target. But again its just rounding up maxHP/weaponDamage to figure out how many in that group can be launched. You also see it with ship launched anti-ship missiles but there isn't really any control over that at the moment. -
Trying to get Tu-22Ms to salvo fire ALL their missiles...
Grimes replied to AvgeekJoe's topic in Mission Editor
With normal tasking AI only fire enough weapons within their own flight to destroy a given target. This can be rectified by assigning an "Engage Unit" or "Attack Unit" task and specifying the expend value to "All" and allowing group attack. -
A code example or the types of targets might help to clarify. Just a few thoughts though: If you are calling getDetectedTargets once to build a table and then iterate over that table or getDetectedTargets is returning nil values on each run. If it is the latter then that is where knowing the targets matters. I believe there have been changes made where "dead" objects register at different times. Part of this is if using events you may see a unit_lost event before the unit is fully destroyed. It isn't the worst thing in the world to verify your object is still accessible before running code on it simply to avoid errors or extra processing. In your example if target then ought to be enough. If I wrote it differently on the wiki the "test" could just have been if Unit.getByName('BMPAirDefenseSystemGroup1_unit1') then as part of the function that gets called. Honestly don't know if one is faster than another because it takes microseconds to do, but technically stuff like that can add up. Either is fine for most use cases anyway. Through a quick and dumb test that some functions can still work on a "dead" unit while others will error. Initially I thought it could be a difference between unit:getLife() and Unit.getLife(unit), but that doesn't seem to be the case. I would need to spend more time on this to get a thorough answer for which functions can still return something on dead objects and possible add that info to the wiki. At the basics isExist can be relied upon, but other than that I don't know.
-
known LandingReFuAr waypoints does not work on a carrier
Grimes replied to Gurke's topic in Sea/Navy AI Bugs (Non-Combined Arms)
Of course you can. It is a little tricky in some instances if you wanted it to respawn exactly where the old aircraft was at due to how spawning on ships works. But if the idea is S-3 lands and another S-3 spawns to take its place then it is very much doable via script. -
How to get planes to attack ground and air targets?
Grimes replied to Gunfreak's topic in Mission Editor
Using only the mission editor you don't have many options. The most you can do is set them to attack one thing and then change their ROE to allow the AI to go off mission and attack anything. The problem being that they can and will attack anything. The odd thing of all of this is it is mostly an editor limitation. The task for AI to engage a group is the same for ground, sea, and air. Likewise "CAS" is just engageTargets but with ground unit attributes while CAP is engageTargets with aircraft related attributes. Using the scripting engine you can combine the task types or just give orders allowing the group to attack specific groups. https://wiki.hoggitworld.com/view/DCS_task_engageGroup Could be as simple as the following. Click the little question mark icon next to a groups name and it displays information like the groupId and unitIds for that group. Replace the number for groupId from my sample for the 109s and radar. Or just use one of them for the opposite of whether you give em CAS or CAP. If you wanted to use the actual "attack group" task just replace id = "AttackGroup". It has the same input values. local gp = Group.getByName('spitfires'):getController() gp:pushTask({ id = 'EngageGroup', params = { groupId = 20, -- GroupId associated with aircraft }) gp:pushTask({ id = 'EngageGroup', params = { groupId = 5, -- GroupId associated with the radar })- 1 reply
-
- 1
-
-
Forgot that it tends to not like it if you do a deadObject:function. Changed it slightly to Object.isExist(target) which should get the desired results. Was actually a little curious to see if LST/LSS works and sure enough it does. Can even guide weapons via it fairly reliably.
-
https://wiki.hoggitworld.com/view/DCS_func_setPoint
-
Forrestal Spawn Points - let's see your carrier decks!
Grimes replied to Tomcatter87's topic in Mission Editor
At present you have to use the scripting engine to spawn in and remove statics as you see fit. Removing objects is easy enough via something like. local objs = {'static1', 'static2', 'static3'} for i = 1, #objs do if StaticObject.getByName(objs[i]) then StaticObject.getByName(objs[i]):destroy() end end Spawning is a little more complicated because you need the coordinates for where objects can go. Have to use: https://wiki.hoggitworld.com/view/DCS_func_addStaticObject to spawn em. -
UnhookCargo Event? How do I detect unhooked cargo?
Grimes replied to cfrag's topic in Mission Editor
Reported. -
Suppose it depends on the feature, but the general answer is you probably don't need to do anything. If you load into an F-16 mission that was last updated when the F-16 came out you will still have access to the F-16 A2G radar, new weapons that were added to it, etc. In terms of new AI units, well obviously they won't be in old missions, but you can just add them to the existing mission. Mission editor features are the same way, just modify that mission, even if you don't it'll be fine without it. The most you need to do is re-save the file, but even then it is far from a requirement. Just look the dates of missions included in the game for various modules, the vast majority are several patches old. The editor has a lot of backward compatibility built into it for loading old mission versions. That said the editor versioning itself doesn't update all that often.
- 1 reply
-
- 1
-
-
UnhookCargo Event? How do I detect unhooked cargo?
Grimes replied to cfrag's topic in Mission Editor
At present there are no events associated with hooking or releasing cargo objects. It has been requested. I think you are just going to have to query cargo objects periodically and check values returned with inAir() or getVelocity() to determine their state. Since they are static objects the only time where inAir would be true or getVelocity wouldn't be 0 is when it is sling loaded. -
correct as is AI airport spawn
Grimes replied to Iberian's topic in Aircraft AI Bugs (Non-Combined Arms)
Not a bug, it does that by design. -
Via scripting you can sort of do it via markup functions: https://wiki.hoggitworld.com/view/DCS_func_markupToAll It is worth noting that the Draw feature and what is available in the scripting engine are almost two different iterations of it. For instance the scripting engine has one set of outlines for shapes while draw has different options. Scripting can't draw an ellipse or icons. Some of the scripting functions can "rotate" the object but it is purely done via doing the corresponding rotation of points and drawing it that way. Also color for scripting is basically RGBA in values from 0 to 1 while the editor values for drawn shapes is hex.
-
fixed AI F-15E - JSOW not releasing properly
Grimes replied to gasmate's topic in Aircraft AI Bugs (Non-Combined Arms)
Well that is odd. Reported. -
Forrestal Spawn Points - let's see your carrier decks!
Grimes replied to Tomcatter87's topic in Mission Editor
Like with the Stennis and Supercarrier spots 1-4 are only available for spawning at mission start. The 8 spots on the starboard side are always available, assuming they are not blocked. -
The shot event doesn't have a target because the missile is guiding to a point and the seeker isn't active when shot. For air to air missiles like the AIM-120 the value returned with Weapon.getTarget can change between nil and returning something depending on what is happening with the guidance. It can acquire, lose track, and reacquire, lose track, and acquire a different target for instance. There is no event for that so it requires constantly rechecking the value. So for the HARM fired in PB modes that value never changed even if the target it was guiding to was destroyed and it switched to another nearby target, it was always just nil. IIRC in SP and TOO the returned value could switch targets if the missile did. So I reproduced the bug that Weapon.getTarget doesn't change in PB modes with the HARM.
-
I did end up reporting that Weapon.getTarget never changes once it does start acquiring a target. Only got it to occur with the HARM in PB in F-18 and POS submodes in F-16, and Harpoon in RB/L. So that aspect of it is bugged. Also did request the addition of Weapon.getTargetCoord. Unknown when either of those will be addressed.
-
Script @Wpt DOESN'T execute for human flight
Grimes replied to CougarFFW04's topic in Mission Editor Bugs
-
Script @Wpt DOESN'T execute for human flight
Grimes replied to CougarFFW04's topic in Mission Editor Bugs
I don't think any of the waypoint actions occur for player or client aircraft other than what is assigned at their spawn point. Simply put players don't have to go to their active waypoint like AI do. Players might decide to skip it, not fly perfectly over the waypoint, or completely ignore their route.