[HOUNDS] CptTrips

It's video proof that helicopters are so damn ugly that the Earth repels them.

For me, LCtrl + Lshft + Esq. It's a multi-mode toggle so keep doing it until it gets to the full-off mode.

A similar unexpected result on field capture zones (slight twist). I suspect under the covers it is related to my original post somehow. I ran across a situation where a static can capture an airbase even when clearly outside the airfield zone. Aside from the oddity that a tent can capture an airbase (hint: it works with an Orca whale too ), it is clearly outside the airfield zone. Yet when run, the tent has flipped the field blue. Of course, if I move the tent to the 3 o'clk position it doesn't capture the field even though even closer. Oddly, if I change the tent to an Abrams tank in the corner, it doesn't capture the field. Ground units (in this case) must be using a different algorithm than statics. I bet a dollar, statics here are using something similar to the sphere volume like in my original post. However, when calling world.searchObjects, it finds ground units within a bounding box not the specified sphere. I hope that the answer isn't that this is intended. I understand that searching a sphere is more expensive than searching a box. But it is not something likely done every frame, and it certainly could be written as a two pass search, first using a box to get a selection of possible candidates and then only apply the more expensive sphere search on those for the final results. That would reduce the number of objects needed to evaluate with the more expensive calculation. Otherwise it can lead to various confusing and apparently broken, almost random seeming results. It will give false positives on things at a distance of 140% of the intended radius. If you compare a sphere volume with its bounding box volume, 48% of the box volume will be giving a false-positive hit result. Almost worth flipping a coin to decide if you trust the result or not.

Doh! It was late. My brain was shutting down. So, BOX seems to work fine. Makes sense. My original problem is, that BOX search works fine, except I asked for a sphere.

(Do you see anything wrong with the first sphere example? That's the one I am really interested in.) Hmmm. I'm still screwing up somewhere. Still getting 0. This the code now: local foundUnits = {} local sw = trigger.misc.getZone('SW') local ne = trigger.misc.getZone('NE') ne.y = 10000 local volB = { id = world.VolumeType.BOX, params = { min = sw, max = ne } } local ifFound = function(foundItem, val) foundUnits[#foundUnits + 1] = foundItem:getName() return true end world.searchObjects(Object.Category.UNIT, volB, ifFound) trigger.action.outText("Number of units found: " .. #foundUnits, 20) env.info("Number of units found: " .. #foundUnits) (see attached) TestBOXVolume3.miz

Also put it on land with m113. Tried alt of both 0 and -10000. still no hits. (See altered example) TestBOXVolume2.miz

Yep. Those are tugs on the surface. I saw in the editor the cursor on the water siad "-100" (?) I tried -10000 but still didn't get a hit. Y is alt, right?

I tried adding some helper zones at the corners as per https://wiki.hoggitworld.com/view/DCS_volume_box. Here is my test code: local foundUnits = {} local sw = trigger.misc.getZone('SW') local ne = trigger.misc.getZone('NE') local volB = { id = world.VolumeType.BOX, params = { min = { sw.point.x, 0, sw.point.z }, max = { ne.point.x ,10000, ne.point.z } } } local ifFound = function(foundItem, val) foundUnits[#foundUnits + 1] = foundItem:getName() return true end world.searchObjects(Object.Category.UNIT, volB, ifFound) trigger.action.outText("Number of units found: " .. #foundUnits, 20) env.info("Number of units found: " .. #foundUnits) It kept coming back with 0 objects found. I assume I am missing something simple. (attached test miz) TestBOXVolume.miz

Ah, I stand corrected. Hmmmm. Now I wish I had a Cylinder volume. Don't really want the boundary to curve in with alt. I just want to have a cylinder of infinite height. Oh well, that is a wishlist item. But a square ain't a sphere or a cylinder. [edit] I could see the benefit of doing a computationally cheaper bounding box check first as a trivial reject, and then do a more expensive 3d radius check on those found in the bounding box. Maybe they just forgot the second step.

I ran into a problem with some Moose functionality. In debugging the issue, it appears to originate in the SSE. So, I wrote a test using only SSE and duplicated the underlying issue. I am attempting to scan the area defined by TestSphereZone. Here is the test code: local foundUnits = {} local sphere = trigger.misc.getZone('TestSphereZone') local volS = { id = world.VolumeType.SPHERE, params = { point = sphere.point, radius = sphere.radius } } local ifFound = function(foundItem, val) foundUnits[#foundUnits + 1] = foundItem:getName() return true end world.searchObjects(Object.Category.UNIT, volS, ifFound) trigger.action.outText("Number of units found: " .. #foundUnits, 20) Note a volume type of "SPHERE is specified. (Really should be called Cylinder IMHO, but whatever.) I would have expected a count of found objects to be 6. What is returned in this case is 18 objects (i.e. appears to include objects outside the cylinder but inside a bounding box corners. On a 10 nm radius zone the error at the corners is 4nm or 140% percent of the intended radius. (Test miz attached.) Thanks in advance. TestShereVolume.miz

To be fair, you see the light reflected off the ISS. The form of the ISS is too small for you to resolve. The same way you see you see light emitted from distant stars at night, though they are too far away for you to resolve the surface of their disk. I have no idea how far fighter aircraft should be able to be seen under normal atmospheric conditions. Gut instinct is that 40nm seems kinda crazy. It seems there are two separate questions: 1. What is a reasonable distance to spot fighters under normal conditions. 2. Should displays with lower resolution be able to gain an advantage in spotting them. The first question has been addressed by plenty of research out there I suspect. It's probably less than what radar can reach or else why have radar. Remember what BVR stands for? The second question seems like an area for additional improvement. BTW, I have noticed this effect in another sim when flying with a group in a scenario. The two of us that had VR could consistently spot targets much further out than our 2d wingmen. Even when we told them exactly where to look. $0.02.

Or maybe the inverse. Add a 3rd "DCS Fiddle" tab in that UI with WebView control hosting that page. I have seen mention of DCS Fiddle and was intrigued, but I have had time to play with it. Not sure what all it can do. Is there a video?

It's written in C# using .Net on Winforms UI. I assume theoretically it could be ported to a Blazor web UI. I haven't looked into that. I haven't done local file system stuff in Blazor yet. Not sure of the constraints. Theori

Yeah. Notepad++ is fine. The main reason I created this was to have the log entry filtering if I only want to find Moose trace entries or Errors. Makes it a little easier to find quickly. Sorry for the link. I had posted an updated version to the Moose discord, but wasn't sure if anyone here was interested. ------------------------------- If anyone is interested, this version implements a file watcher that will flash the refresh button green when new log lines are detected available. Also fixed a parsing bug of Moose traces that have negative "line from" values. Event handlers? https://www.dropbox.com/s/7jwwcti9zp6l4ua/DCSLogViewer_0_9_9.zip?dl=1

Hi guys. I am new to Moose\Mist and mission scripting. I have been setting up my environment to dig in. I was really hoping to get true interactive debugging working with Lua, but that seems to be on hold at the moment. That means I will be relying heavily on log file tracing for my debugging. To make things a little nicer, I decided to try and write a custom log file viewer for the DCS files. There are some nice general loggers out there, but I felt if I wrote my own I had more flexibility to tailor the functions directly to DCS and Moose\Mist (e.g. filtering down to just Moose or Mist tracing statements, etc). I have what I would consider a beta version now. What would be helpful if I could get some other people exercising it against various log file test data. Especially stuff with Moose or even Mist tracing statements. If you felt like giving it a try and giving me your feedback, you can get it here: DCSLogViewer

Yep. I'm hitting this too. Please let us know if you find a fix. regards.

Hi guys. I have been trying to get interactive debugging working using the document in the MOOSE Git. I am not yet using MOOSE so I am using the alternative “loadfile” approach mentioned in the document. I am new to Lua and DCS, but I want to prove to myself debugging is possible before going to far down the road of learning Lua. I need true debugging or I suspect it wouldn’t be worth it to bother. It wouldn’t be worth the years it would take off my life. I have tried various ways and seem to be running into the same class of problem. Seems to be some kind of scoping issue. Probably some stupid simple Lua trick I am not doing right, I just haven’t figured it out. In testing I have an example that is not even involving debugging so is a good simple case. Say I have a script file “TryTest.lua”. Say the content looks something like: TryTest = function(count) –- do some trivial stuff looping through the country enum –- dump out some stuff to env.info end The contents of the function isn’t important because I am not getting that far. I have a trigger when my debug flag is true I go do a “_G.loadfile( full_path_name .. ‘TryTest.lua’) “ on mission start. I have a trigger when the player enters the zone that does a DoScript “TryTest(1)” When it fires it says it can’t find the global TryTest. *** If in the debug flag is false, then it does a DoScriptFile of the same code. In that case the same exact code works fine. The zone DoScript “TryTest(1)” is resolved. Same code the global TryTest is resolved when using DoSCriptFile, but not with loadfile. Some kind of scoping problem. Inversely, an earlier attempt it wasn’t a function, just the code inside the function that got loaded directly in the zone trigger. In that case it got to the code but it barfed when that code tried to index “country” which is a global DCS enum. So in this case, it was still a scoping issue in reverse. TLDR; I seem to be running into scoping issue with loadfile that I am not seeing with the same code loaded with DoScriptFile. As I said, I am a noob, so I assume I am missing something simple. Thanks in advance for any clues.

Since we don’t have a regions/box select (count slowly to 10), it it necessary to painstakingly individually click on each unit/object I wish to add to the multi-select. If at any point that fails, you don’t just not get that item, but you lose all the other items you had painstakingly selected. I currently have been using NATO icons in the editor as those seem more recognizable to me. I have run into multiple occasions where I clearly clicked in the NATO icon bounds, yet my selection was rejected and I lose everything and have to start again. That is a very poor user experience. I think what is happening is the actual region for selection that will work is NOT the currently displayed icon, but only the Russian icon which can be different size than the NATO icon. However when displaying NATO icons I cannot see that and it is not conveyed in any way and can lead to seemingly random select failures and much frustration. So maybe the ability to use NATO icons was added at some point but the hotspot region for selection was never updated. Example...the screen grab didn’t include the mouse icon but I marked where I clicked in the NATO icon. Clearly within the bounds of the NATO icon, but selection failed, all other selections discarded. If it is large like a tank, clicking on the model also fails. That would could be argued, but it would be nice if that worked as well, but I can live with that. Just mentioning it in case it confused someone. In reality, the only thing that seems to work is clicking on the area the Russian icon would cover even if it is not visible and might be smaller than the displayed NATO icon. It seems to me the proper behavior, would be to honor the boundaries of which ever icon is being displayed. A less desirable solution might be to at least change the cursor color or shape (arrow to crosshairs maybe) when I am over this invisible hotspot so I don’t click wrong and loose all my other 19 0f 20 selections. (Note: I wouldn’t have even run into this if I had a box/region select). Or maybe when more that 3 items are already selected, make un-selection require an esq key so I can at least try again without losing all my other selections. Failing all of that, maybe document in the users guide that attempting multi-select with NATO icons can be unreliable and it is suggested to do so only with Russian icons. That might at least help some avoid frustration trying to figure out what is going on. In the short-term, probably the best workaround is to use Russian icons when doing multi-selects to avoid the pain of losing your other 19 selected items. Oh, and add a box/region select. $0.02.

Sorry. That's what I had done. Not turn icon off, but turn it to Russian. Interesting. That makes sense. The Russian's wrote it to pick up the click on their shape. They just didn't change it's click boundaries to the NATO icon when you switch. So it makes sense it is the Russian icons that are driving it which be a different size and be hidden by the NATO icon. So lesson learned, until they give us a box select, use the Russian icons for seeing the proper select target.

For the OP... Here is what I think will help if you have to try and copy a large number of units in ME sorta reliably. It's still painful and a very poor user experience, but you gotta do what you gotta do. If you have an object that is larger than the NATO icon like this tank, you can't click on the model or you lose everything. You can often click inside the NATO icon and still lose everything. If you turn off model and icon, you see there is a smaller icon hidden underneath the others. This is the shape that appears to control the selection and it can be quite a bit smaller than the NATO icon in some cases, like infantry,etc.

For instance, this screen cap didn't capture the mouse icon, but I marked where I clicked. If your mouse moved ever so slightly off the center, even though you are still clearly within the visible unit icon, NOPE! You lose everything and get to start over. There is no visible clue WHERE it is safe to click, you would assume anywhere in the rectangular icon region, but NOPE, there is some hidden area inside of that you have to hope to strike upon, or start over.

Agreed. My main point is something like this has to be low hanging fruit that can make life a LOT easier for people trying to provide ED free content. There are a lot of other cool stuff that would be useful that I understand would take a lot more effort, this is not one of them. The ROI on that should be obvious. Every little bit they can improve the editor's usability provides them with even more free labor and content creation from the community. In the meantime, you got to do what you got to do, but you don't have to pretend you like it.

That's what I been doing. If it's one or two objects I can live with that, but it is a huge burden when trying to manipulate complex collections. One really annoying thing I've run into, you can click in the unit icon and still get a deselect. It seems you often have to click in the exact center of the icon to ensure reliable success. Sometimes you do carefully click into the icon rectangle, and then you still lose everything. It's very frustrating to click in the icon and still lose 20 items you had painstakingly selected. Even if it just didn't get that item it would be bearable, but to lose everything else? I'm wondering if you need to not show the icon and make sure you are clicking on the actual item model. But if icons are being displayed, clicking anywhere in the rectangular area of that icon should be a successful select. Maybe it is more of a problem for models noticeably smaller than the icon. I'll experiment more with it. Regardless, not to be too dismissive , it can make for a very frustrating user experience to have to fight so hard trying to so something so simple.

I might be wrong, It could take 16min. Relax. Hyperbole aside, my point isn't to be dismissive, but to express confusion. But you can't tell me that for a team that can produce the Apache-64, that adding a simple box/region select to the editor in the 11 years of posts I've seen it begged for is an insurmountable task. It's pretty much a standard feature any editor should have and can't be that difficult. I get AI is hard, you'd have to explain to me why a box select couldn't be accomplished in a decade. What exactly is it that makes that a harder problem than I am assuming?

I cannot for the life of me fathom how an editor for a commercial product, in this day and age, not have such a basic and fundamental tool such as box/region select. If you have something like the measuring tool, you are 90% of the way there. I spent a day googling assuming I was just missing it somehow before I came to the shocking realization that it just didn't exist. An 8yo script-kiddie could write that for them in 15 min if they had access to the source. And worse, in searching I saw posts of people complaining about it's lack for a decade. I wish they would open source the editor so people with coding experience could make improvements themselves. A powerful editor is a massive force multiplier for DCS to unleash armies of content creators. They then could focus on internal issues like better AI.