funkyfranky

Unfortunately that is not the case - I just double checked. Both dead and unit lost events still occur at the same time. That when the unit finally explodes but long after the unit stopped to exist in game.

That was indeed also my initial expectation, i.e. that with a non-FFB joystick, you are essentially pulling/pushing with an infinite force (therefore, not being desynced between physical and in-game representation of the stick). Of course, with FFB, it is at least possible to emulate the forces on the stick. But if you are able to synchronize an FFB stick (e.g. by pulling it back to the center position whilst on ground), it seems strange that a non-FFB stick is necessarily de-synchronized. Got to dig out my good old Sidewinder to check for myself.

Here are a few short demos showing how you track the weapon and interact with it (e.g. destroy it) https://github.com/FlightControl-Master/MOOSE_Demos/tree/master/Wrapper/Weapon

Yes, I notices this too and it should be reported. It happens only in SP, in MP it fires only ones IIRC.

Wow, yeah, that looks strange!

Re: Circular zone It's a bit difficult to see but is the actual area that is removed the square encompassing the circle? That would be consistent with another (reported) bug for world.searchObjects

Hi guys, just received my new Orion 2 Joystick + extension and also the additional cams/springs/dampers kit. In the reviews I saw (Redkite etc) the cams are different from the ones I got. I guess this is a new version. Can someone enlighten my about their meaning. In the new version, one gets () NC-ARC SC-ARC NC-1S SC-1S Unfortunately, the Manual does not state anything about the abbreviations. I guess NC=no center and SC=soft center but what is 1S and ARC? [Edit]: 1S seems linear. In the older version of the kit, there was also 2S, which would increase resistance. Strangely, the default cams are NC-ARC, so the "extension" kit contains one set of cams that are also installed as default cams. Why? And which combo would you advice if the stick is used with an extension? Thanks!

Ran into the same problem quite some time ago. Cruise missiles do not obey the the radius setting. They will all impact at the same point. Thought it was a bug, too, but it is actually written in the manual. So it is by intention (even though I personally do not like it). (Attack Group/unit tasks only work for aircraft (unfortunately!))

Is a warehouse always associated with an airbase, FARP or ship? Asking, because we also have static objects such as warehouse, ammunition depo, tank 1, tank 2, tank 3, which act as warehouses, which do not belong to an airbase. Obviously for these, the warehouse cannot be retrieved with the airbase:getWarehouse(). According to hoggit , there should be a Warehouse.getByName() function https://wiki.hoggitworld.com/view/DCS_func_getByName. But that does not appear to work (not even for airbase warehouses).

Big thanks to ED!

There is actually a function to get the magnetic declination but it requires to de-sanitize "require" (strange sentence, I know ;)) See

Cool, thanks for the source! Think I already found why it's cubed (for R=1 m)

Thanks for the write up @Beamscanner. I'm trying to understand your max detection range equation and the values of the parameters you quote in the table. What does not make sense to me is the area constant You write 4π^3 but you the number you calculate (1984) is actually (4π)^3. That might be just missing parentheses but I still don't quite get where a factor of (4π)^3 comes from and why that should be an area? (I assume you take a sphere of radius = 1 m so the radius is not "visible" in the equation but still).

Last I tried, a C-130 was to big for Creech. There is no valid parking position so DCS solution is to despawn it on landing. Or can you put a C-130 on any parking position initially?

Can confirm this. BTW, it is really a spherical not a cylindrical volume that is searched (if it worked correctly). You can see this by moving the center high into the air with sphere.point.y=sphere.point.y+10000. Then it does not find anything.

Yes, to be fair, it also states that in the DCS manual p.330

Yes, that's indeed very annoying. I have reported that years ago and also found other reports here about the very same issue e.g.

Yeah, I also just noticed the two points at (0,0) in the points table, which seems wrong as @Grimes already said. What I meant is, that in order to get the points where you drew them you need to apply the following transformation x=x+mapX y=y+mapY

I agree that a method/option to have sounds played in sequence would be great. Currently, we need to put the next sound file trigger into a scheduler. And even that is difficult/tedious, because you need to know the exact length of the previous sound.

The points are relative to the origin. You have to translate them by (mapx, mapy) to get their true position.

To your first question, yes, for ground (and naval) units the "Attack Group" or "Attack Unit" task is not working... sadly! Second, would be good to know which unit type you are using where the zone radius is not working (?), i.e. not sure what you mean by HIMARS as we don't have this in game. I know that when ships firing cruise missiles, the zone radius is not working and all missiles impact at the very same point. Think I reported that years ago. Suggestion: Why not use several "Fire at Point" tasks to hit different targets using the same group? Still, as @Flappiesaid, a track with the zone radius not working for fire at point would be good for a report.

Interesting, I did not know the mark ids could not be reused. Certainly something to watch out for.

Yes, we just added that feature. Polygon zones are automatically created from polygons added with the draw tool.

First, I totally agree with you @Elphaba that the lack of proper documentation is very unfortunate to say the least. However, the naming of the getVelocity function is perfectly fitting as it returns exactly what the name suggest, i.e. the velocity by its very definition (rate of change of position with respect to time). And since you can apply the function not only to aircraft but also to ground vehicles and ships, naming it getGroundspeed would be a bad choice IMO. Also, I am not 100% sure, but I think ground speed only refers to the speed in the 2D horizontal plane, i.e. a helicopter moving just vertically up or down would have a ground speed of 0, while its velocity would be greater than 0. And that is what getVelocity would return. If you want to get the ground speed from the getVelocity function you would need to project in onto 2D, i.e. GroundSeed=( velocityVec3.x ^ 2 + velocityVec3.z ^ 2 ) ^ 0.5

Sorry, but nothing is wrong here except maybe as false expectation as to what the getVelocity function returns. This indeed returns the ground speed (GS). The speed shown in box on the F10 map is true airspeed (TAS). As soon as you accept that, all the numbers make perfect sense. TAS is constant and GS (=TAS+WIND) varies as the aircraft travels in the direction of the wind or in the opposite direction (or anything in between). This also explains the "differences" between the maps, because on Caucasus mission the wind is zero and therefore TAS=GS.