WirtsLegs
-
Posts
143 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by WirtsLegs
-
Yeah no bridge at the time, what I was mainly noting with this post is at the time and still now there were simply more buildings etc, specifically marked off in the op map I linked the 3 areas there The game map is missing these, seems to be just kinda generic generated layout based on the roads (the road shapes/positions are mostly accurate at least)
-
Prior to the most recent update the area was still just filler, not accurate, haven't had a chance to check it since the last update
-
I think his complaint is accurate though The buildings "dug into hills" in the map aren't what you showed, they are much more an obvious terrain clipping issue with the terrain covering say half a door or the doors on the low side being 20 feet or more above the ground etc. There are also things like cars clipped into the ground because scenery cant be rotated to be normal to the terrain
-
adding to this, I have observed two situations where the roadnet seems to break 1) when the road passes under a bridge/overpass, I have yet to find one that works and 2) random points usually on gradual curves where it just seems to break (picture attached).
-
Shouldn't be a problem for AI units As for player aircraft, hard to say, but setLife does weird things for anything that doesn't have a healthbar anyway (aircraft basically) so unlikely to be used for that regardless
-
yeah did something similar in a script I'm working on last night worth noting, this should be doable for all trigger functions as there are a few others that are not accessible via the normal lua api
-
@Actium good find! still silly that this isnt just part of the standard lua api
-
So not something that is obvious to most people playing the game, but it seems the attributes given to units (fetchable in lua with getDesc()) are given out way too liberally. Specifically there is no distinction between a hummer and a proper APC like a LAV-25 The hummer's attributes: { 2, 17, 104, "Redacted", "APC", "ATGM", "Datalink", "Infantry carriers", "Armored vehicles", "All", "Ground Units", "Ground Units Non Airdefence", "Armed ground units", "Vehicles", "Ground vehicles", "Armed vehicles", "AntiAir Armed Vehicles", "NonAndLightArmoredUnits", "LightArmoredUnits" } The Lav { 2, 17, 26, "Redacted", "APC", "Infantry carriers", "Armored vehicles", "All", "Ground Units", "Ground Units Non Airdefence", "Armed ground units", "Vehicles", "Ground vehicles", "Armed vehicles", "AntiAir Armed Vehicles", "NonAndLightArmoredUnits", "LightArmoredUnits" } The only difference is the 3rd attribute which is provided as a index, not sure what they are but they vary between different "APC"s such that its not usable as a discriminator, and then in this case ATGM and DATALINK which are obviously not any use for distinguishing these two classes of vehicle This makes any kind of scripting that needs to be able to understand unit type difficult as we have to separately maintain a hard-coded list of vehicles vs their type I would propose removing the APC attribute from anything that isn't actually an APC (some of those light vehicles have some basic armour but they are not classed as APCs), the Infantry Carrier attribute works to tag things that can carry infantry so that discrimination is retained.
-
Yellow "urban" colour on F10 map includes fields
WirtsLegs replied to Flying Toaster's topic in Wish List
Not that I've seen, hopefully addressed soon as currently it makes building missions on the map a bit of a nightmare -
Currently once you zoom into a certain point the map basically fills with orange, the colour usually used to denote cities/towns etc examples: nullnull However a very large amount of that orange area is rural, just fields etc, and it makes quickly assessing the map really difficult, ideally I would suggest these are reduced to cover just the actual towns/cities. The Afghanistan map then has a good solution for these kinda rural areas, introducing another colour in the form of a light yellowy green for areas with the odd building and agriculture but not towns/cities.
-
Add toggle for the new incremental smoke
WirtsLegs replied to WirtsLegs's topic in DCS Core Wish List
As of today's patch this feature was expanded to include grey smoke below 50% health Making it even more of a arcade-like feature I have destroyed vehicles with a large variety of weapons and fact is vehicles rarely smoke when damaged unless they are on their way to burning up or secondary explosions etc. It's also reasonable that from in a jet at altitude, even with a tpod assessing the state of a vehicle that hasn't been completely destroyed can be very difficult While I recognize this is meant as a stopgap pending some more thorough ground unit damage models it is ultimately less realistic and in my opinion worse than not having it at all in its current implementation Please consider adding a toggle in mission settings for this feature, or changing it so that the smoke only has a small chance of appearing in varying intensity -
currently the lua api function land.getSurfaceType(table vec2 ) returns form the following enumerator land.SurfaceType LAND 1 SHALLOW_WATER 2 WATER 3 ROAD 4 RUNWAY 5 I would like to propose adding 1 or 2 new values first and most important, FOREST, not talking about like small treelines or anything custom placed, I mean the actual forest areas. These are part of the maps and should be already known by the sim, if we could have access to that it would enable a lot of features for lua scripters second, less important but would still be nice is a URBAN or CITY value, basically anywhere that is inside a town or city, for similar reasons, thugh unlike forest i dont know if this information is as accessible so it is not the primary ask cheers
-
Update pushed https://github.com/WirtsLegs/WirtsTools/releases/tag/v2.2.1 fixed bugs in Weapon Near and Weapon in Zone, added Weapon Shot feature @Rudel_chw the weapon shot feature should do what you wanted and be more performant/reliable than relying on the old bugged weapon near
-
Update on this, bug found affecting weapon near and in zone functions, basically if the weapons are destroyed while still satisfying the conditions then they won't be removed from the count I have put together a fix and added a simple shot detection feature that will be pushed once I have a chance to properly test it, hopefully tonight but we will see
-
I'll look into this If it is indeed not resetting to 0 as the amount of rockets near the unit in question reaches 0 then you have found a bug as hat is not how it's meant to work If there is a bug I'll add a simple shot count feature as well to replace this function for you
-
All you are aiming to do is count how many are fired in total? If you want I can easily add a quick function for that which will do that for you Note that weaponNear will only count the amount nearby in total at any given time, if say you fire 5 then 10 min later 5 more the flag will at most have a value of 5
-
Hey Eduardo, The error is here you have myFilters.rockets_S5M:addTerm("Name",Weapon.Name,"S-5M") the addTerm() function takes 3 arguments field: what field do you want the term to match on, in this case you picked "Name" so no issues here term: this is the value you expect in the field to have, you put Weapon.Name, what you should put is the actual typename of the weapon like "S-5M" match: This is meant to be a boolean value, so true or false, if true the filter will match when the term is matched, if false you are setting it to say i explicitly DONT want this value So all together you should try: myFilters.rockets_S5M:addTerm("Name","S-5M",true) That should work IF "S-5M" is the actual typename of the weapon note that the typename is rarely the same as what you see in the loadout editor, if you want to check the typename an easy way is to use the debug function i include, to do so run WT.weapon.Debug() after loading WirtsTools and otherwise setup your filter and instance as normal then ingame when you fire that rocket a whole bunch of info will appear on your screen, one of the lines will be the typename just have to copy that name and use it to define your filter Finally another option could be to simply match on all rockets fired by your coalition if making sure its that specific rocket type isn't important you would do that like this: myFilters={} myFilters.rockets=WT.weapon.newFilter() myFilters.rockets:addTerm("Category",Weapon.Category.ROCKET,true) myFilters.rockets:addTerm("Coalition",coalition.side.BLUE,true) --obviously change this if you are flying as redfor Let me know if you need any more help!
-
change camera limits on F10 map and in mission editor
WirtsLegs posted a topic in DCS Core Wish List
So this is I think a pretty minor thing, but would represent a pretty significant QoL improvement for many users Currently in the F10 map or in the editor you cant push any edges of your view past the edge of the map Seems reasonable, except it becomes a big issue with anyone that has a wider than typical aspect ratio. As this results in severely limiting how far they can zoom out, making navigating the larger maps especially something of a chore. Given that ultrawide (21:9) and superultrawide(32:9) are already quite common in the sim community and rapidly becoming more popular, I would suggest either removing that limitation or expanding it to give some buffer allowance outside the map boundaries, simply showing nothing or black or w/e in the areas past the boundaries is fine as the intent is not to use that space it is to allow zooming out far enough that you can see the whole map in the vertical axis -
WirtsTools 2.2.0 is out Finally You can get the full docs on the readme there BUT in short it... Adds the following features: Weapon In Zone: Sets a flag equal to a count of the weapons currently in a zone that match your criteria (works for quad point and circular zones) Weapon Near: Sets a flag equal to a count of the weapons currently within a defined range of a given target that meet your criteria Weapon Hit: Increments a flag each time a weapon that meets your criteria hits a given unit (def read the docs on this one, there are some gotchas) Weapon system overhaul: Massive change to how existing functions Impact In Zone and Impact Near work, they and the above all use my new weapon filter system that lets you simply define criteria for weapons you want to match as a filter to pass to these functions You can do things like match on weapons that are missiles, are NOT IR guided and have a shaped warhead, and so on, full details in the readme Enjoy!
-
Alright update on this, I have incorporated @jumphigh's proposed changes, thanks again jump! and have moved WIrtsTools to a new home on github instead of gitlab, new link is edited into the original post, or just visit https://github.com/WirtsLegs/WirtsTools/
-
So right now any ground unit can be placed on a whip via directly editing the miz file and getting the coordinates right, or through spawning with a lua script, this is a painful process though if you just want to add a few manpads to a seemingly civilian ship etc. However once you get them placed they work fine, they stay on/with the ship and engage targets according to ROEs etc. So a pretty simple request, I would suggest that placement on ships be permitted for all ground units through the editor, don't bother trying to enforce size or weight limits just leave it up to the mission maker to decide what is reasonable to put on which ships.
-
I know it's normal for them to vanish as you zoom out on the map I'm referring to the one that vanishes as you zoom in It shows a road through that area but zoom in and you see that there is no way to go through that's area on roads
-
The issue seems arbitrary, I've been fighting with it as well lately, ks-19s with a fire can that will sometimes track the target, guns will aim but never fire, then in another mission they work fine, etc
-
Oh awesome! Video looks great and took a look through the code quickly and it looks solid Yeah my bad on formatting, last 2 commits were quick and dirty from my phone and it got a bit ugly, was planning to fix that up on the next one, woops I'll take a proper look on my pc when I can and get this merged, though literally just got to hospital for start of kid being born, so naturally no promises on timeline For anyone else reading this before I update on gitlab, jumphighs version looks solid and I encourage you to give it a go
