Jump to content

Grimes

ED Beta Testers
  • Posts

    9161
  • Joined

  • Last visited

  • Days Won

    11

About Grimes

  • Birthday 09/08/1985

Personal Information

  • Location
    Black Mesa

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Not directly. If you call Unit.getFuel() and the value is above 1.0 then you know that aircraft has at least one external fuel tank. I don't recall if jettisoning fuel tanks is part of the shot event or not.
  2. Reported. As a reminder please remove any mods when reporting bugs. And frankly removing most everything else in the mission is also appreciated. This just needs a boat and some statics to spawn on it.
  3. It is dependent on DCS scripting capability and uses this function. https://wiki.hoggitworld.com/view/DCS_func_addGroup "Function can NOT spawn new aircraft with a skill level of "client". However in single player a group can be spawned with the skill level of "Player". When this occurs the existing player aircraft will be destroyed." So no you cannot use it in multiplayer on client aircraft. However client aircraft don't need it because they can respawn at any point as long as they can still access the slot.
  4. Its been an on and off again issue where the object is identified by its unique Id instead of the typename. As far as I am aware it always occurs with scenery objects. You can get a number of them from just having AI drive around a town, but traditionally blowing things up will also produce it.
  5. parking_id is just the value stored that is visually associated with the index. No clue why it is saved in the miz. It doesn't really have any bearing on what the actual parking index is. The printed values are the terminal index. At some bases like Beirut International they are labeled with the ramp area and a number (G20) for example, while others are just numbered. Point is those aren't the actual parking values and it is just for display. I am not certain if any of them are accurate to the actual ["parking"] = x, The unknown type: I could not replicate that at all. Though I did notice that parking indexes started at 0, but that value consistently belonged to a runway. Spent a bit of time and other variations trying to figure out why you got that result when I didn't. As for spawning it appears to be related to what was occurring in my test script/screenshots. It more or less comes down to the fact that each spawn point has certain dimensions for length, height, and width to limit what is allowed to spawn there. The type also limits helicopters from spawning in bunkers. Unexpected results occurred simply based on how you load the mission and what you spawned. I used Frequent Brother for my test. Loading into the editor it looks "fine" however loading into game and also selecting the units it changed the initial waypoint type for several units. In fact it changed them for every unit that the editor deemed was placed at a parking spot it shouldn't be allowed to park at. The A-10s, B-52, E-2, and E-3 were the main units that were automatically moved to airspawns. Loading directly into the mission via Mission on the main menu the units get shuffled around as per your bug report. It looks like every unit that got moved exceeded the limit and possibly caused others like the AH-1 to be moved. Now here is the kicker and when things got really weird. I used my code that was spawning the aircraft to spawn E-3s. Remember that some of the A-10s were moved onto the same spot simply because it ran out of room. None of the E-3s were moved on spawn. My working theory is that since there are no spawn points of the correct size at Ramat David for the E-3 that it didn't know what to do and just allowed it to happen. I suppose it can be described as a Scripting problem and a spawn/map problem, with a tiny bit of a you problem. Scripting because we don't have the tools to get exact dimensions or are able to check if certain unit types are actually capable of spawning there. Outside of manually cataloging every single parking spot for what could be accepted there isn't a whole lot of recourse available until ED realize how dire we need certain API and add it. A spawn/map problem because the strict dimensions dictate where things can spawn at even though there may be ample ramp space with nothing physically blocking an aircraft from getting to the runway. According to the editor there are no spawn points on Syria that support a B-52. I think it is fair to say that Caucuses has more uniform spawn points and a majority of the bases could spawn a KC-135 sized aircraft. On Syria 8 of the ~60 bases support a KC-135. A you problem because you have done a great job making a mission generator, but that generator can build missions outside the rules of DCS. Sometimes thats great because the rules of DCS and the editor can work against you in terms of flexibility, but some of those rules have a purpose. I think you might have to just make exceptions for certain areas of a given map and just airspawn certain aircraft. However at least with spawning via script I was able to spawn B-52s at Incirlik on a few key spawn points and it worked. Whether saving them to spawn there in a miz and loading said miz would work, I couldn't say.
  6. All of the getParking spots returned seems to indicate they are correctly positioned. There is a size limitation with a lot of these and apparently spawning via script it ignores some of the restrictions causing issues. Spawning an F-16 at every spot works while using an A-10 can be problematic. Some A-10s spawned in locations to small and others were occupying the same space. Probably needs some of the spawning logic used on the carrier where it will delay aircraft from spawning if a valid parking isn't available. I made a feature request a while back to add a parameter to pass the aircraft you want to get valid spots for since Term_Type isn't as descriptive or standard as it needs to be.
  7. They will be available as insurgents and probably a few others but they aren't currently in game. ED like to tease upcoming objects in videos from time to time. Just gotta wait.
  8. All it does is it searches mist.DBs.deadObjects table for the category to see if an object represents a map object and then checks the distance from a given point. This is the code it ultimately uses. Just replace the bit of code where it references zones, though its not a flag function, so you have to manually call it whenever you want it to do the check and set a flag or do whatever action once the conditions are met. Realized it'd be a good idea to have a function that works with point so I'm adding a mist.getDeadMapObjectsFromPoint function now. As is life with DCS I decided to add an object filter to look for certain object types but the results are not what I expected and is a possible DCS bug. local map_objs = {} local zones = {} for i = 1, #zone_names do if mist.DBs.zonesByName[zone_names[i]] then zones[#zones + 1] = mist.DBs.zonesByName[zone_names[i]] end end for obj_id, obj in pairs(mist.DBs.deadObjects) do if obj.objectType and obj.objectType == 'building' then --dead map object for i = 1, #zones do if ((zones[i].point.x - obj.objectPos.x)^2 + (zones[i].point.z - obj.objectPos.z)^2)^0.5 <= zones[i].radius then map_objs[#map_objs + 1] = mist.utils.deepCopy(obj) end end end end return map_objs
  9. AI in DCS don't like to do mixed take-off and landing operations even when they should easily be able to do so on an airbase, especially one with multiple runways. I haven't tested it specifically with the updated carrier behaviors, but as long as the other flights are set to uncontrolled and nothing else is actively trying to take-off I would think the landing aircraft should make an approach. There is the likelihood that the waypoints are a little too close for the landing aircraft to the ship. It can be like giving AI a task to bomb something while close to the target. The AI has predefined limits and it may be within those limits when given a task, thus it extends. At least with an airbase if you place it roughly in the right position, speed, and altitude the AI can do a direct approach. With the updated carrier pattern I think the AI pretty much have to go into the landing stack, be cleared, then line up for the initial, etc. Try working backwards, get the E-2 landing best how you want it and then add the other AI and see how it may or may not change the behavior.
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. 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.
×
×
  • Create New...