MeerCaT

I really don't think it's possible, sorry. From what I understand of the DCS 'track record/playback' mechanism there is no way to skip ahead or chop off the beginning. During playback the state of the the DCS 'world' at any given moment is merely the product of all 'actions' and 'inputs' since the 'beginning of time'. It would be nice to have a 'reset track' feature (applicable both to playback of a track and recording of a track during 'live' play) to record the state of all entities at that moment in time and make it the new 'beginning of time' (thus discarding the previous track history up to that point). Incidentally, running a 6 hour track at x10 time acceleration should take about 36 minutes. Set an alarm and go read a book? :) (I can't remember, what's the maximum acceleration rate? x15? That would only take 4 minutes to playback a 6 hour track.)

Ah great that's fantastic, thanks for pointing it out. I'll give it a go tonight. Well, forget I said anything then I guess :) (Although it would be nice to have the on-screen components, such as kneeboard and the controls indicator panel, be mouse-draggable.)

Ha :D, such clarity and precision in their naming. "Big Explodey Thing #12"

Thanks, I've not looked into that naming system before. Inspired me to have a quick glance around the naming system for bombs and came across this: http://www.aerospaceweb.org/question/weapons/q0166.shtml In my naivety it still feel like the AGM-62 would be more accurately designated as a "GBU" - Guided Bomb (not self-propelled), Unit - A piece of equipment that can function on its own. Perhaps the capability to control it post-launch via datalink confuses the matter? But let's try not to lose too much sleep over it.

From my experience in the A-10C, rightly or wrongly I've acquired the habit of releasing Mavericks while in a nose down attitude pointing towards the target - intention being to help the Mav on its way by giving it a straight line angle of attack to the target immediately from launch. I don't recommend the same procedure with the Walleye (AGM-62). Its free-fall bomb not a powered missile - the 'M' in AGM is a lie! I just managed to 're-collect' the thing after release and turn myself into a smoke cloud ("Pink mist" - ew!).

I recently discovered wake turbulence too; not sure when it was officially introduced but I encountered it for the first time about a week ago on a multiplayer server; I don't think I've ever deliberately disabled it in my options so I'm guessing it was originally introduced as disabled by default. Seems that when its enabled within an online server's config then it is forced on for all clients too, regardless of local client config. Yes it really steps up the difficulty of AAR for those (like me) not used to dealing with it. I'm not at all claiming to be rock steady and in full control but after a little practice it is eventually possible to deal with it. I can't advise on the real world correct approach procedures for AAR but I find that coming in at a slight angle from the outer side helps. E.g. if the basket/drogue is deployed on the left wing then try approaching from a little further out on the left side of the wing tip. While within the necessary area to make connection (what I refer to as 'The Box'), I seem to find it necessary to maintain the stick somewhat left of center (for a left-hand drogue deployment). The aircraft feels like it is constantly being sucked right - into the engine wash of the tanker. Perhaps having spent some time with helicopters has helped me get accustomed to prolonged off-centre 'stick' handling (Trim? What trim? :)). But definitely expect, and get used to, holding the aircraft in position with significant off-centre stick position. Another point is, the 'sweet zone' in which connection and refueling is possible feels to be kind of on a knife edge. Just a small movement towards either side can result in the aircraft getting sucked/pushed with rapidly increasing force further in that direction - just like balancing a pole vertically on the tip of your finger ... or like hovering a heli, in fact, which again experience of this could help here maybe?

Well it's been a month since the last one so its time to bump (vote) once again the wish for a movable kneeboard (simple static configuration even, if not dynamically dragable with the mouse at runtime). (Quick reminder to those who don't/rarely visit online multiplayer servers: the kneeboard can be repositioned - https://forums.eagle.ru/showthread.php?t=129097) The 'SRS' (Simple Radio Standalone) mod manages to produce a small moveable overlay window within DCS. On the face of it, its easy to make an uneducated assumption that it would not be very much work or technically difficult to apply this same/similar mechanism to the kneeboard. Would the fine chaps and chapesses at ED be willing and able to either confirm or refute this assumption? A couple of people share this same desire: https://forums.eagle.ru/showthread.php?t=260350 (Jan 2020) https://forums.eagle.ru/showthread.php?t=250740 (Oct 2019) https://forums.eagle.ru/showthread.php?t=244728 (Jul 2019) https://forums.eagle.ru/showthread.php?t=212220 (Jun 2019) https://forums.eagle.ru/showthread.php?t=238243 (Apr 2019) https://forums.eagle.ru/showthread.php?t=232017 (Feb 2019) https://forums.eagle.ru/showthread.php?t=230065 (Jan 2019) https://forums.eagle.ru/showthread.php?t=194846 (Oct 2017) https://forums.eagle.ru/showthread.php?t=188165 (May 2017) https://forums.eagle.ru/showthread.php?t=162426 (Mar 2016) Though I've not used it (yet) myself - having only just discovered it - here is another plug for the very impressive looking Kneeboard customisation tool: http://www.dcskneeboardbuilder.com/ Of course, as most are already aware, applying unofficial modifications to core DCS files (i.e. kneeboard postion) will prevent connection to multiplayer servers that mandate file integrity checks (i.e. most servers).

My gentle recommendation would be to try not using these 'artificial' aids. Doing so will likely slow your progress in developing your natural sense of positioning within the virtual 3D space (i.e. knowing where you are in relation to cargo, objects or points on the ground that you cannot see below you). I don't claim great expertise myself, but I do now feel much more comfortable creating and maintaining in my mind the perception of where I am in relation to points below me. When approaching a cargo, I'll automatically build a subconscious awareness of reference points around it (buildings, trees, patterns/textures on the ground etc.) and from my peripheral vision I use these references to help me triangulate where the cargo is likely to be once it dissapears out of view below me. Also, we have verbal callouts guiding us ("forward 10", "left 20"). Arguably, some real life cargo operations in the Huey would likey use a cargo mirror on the skids. A mirror might not help us much though since having such reduced peripheral vision in a sim like this means that it could be very tricky to maintain a hover while having our head down trying to focus on and understand what we see on a small mirror down so low. Well, I guess practice can solve most problems.

Agreed, it would definitely be nice to have, perhaps as an additional radio call if not part of the initial response to the 'Intent to refuel' call. Not forgetting of course, the F/A-18 has the technology for us to find out this information for ourselves; giving the tanker a good old blast of radiation will tell us its speed in machs. What's the official/typical/courteous distance from the tanker at which the radar should be silenced?

I've tracked down the building model that was giving me cause for existential concern. (Is it the building or me that does not exist? It is not the spoon that bends...) Attachments 1 and 2 are some images of the specific instance I just tested with. (The first one is a game of "Where's Wally?") Attachment 3: "I done gone shot me a dang Huey and hung that little critter's head on my wall". This instance is located just North of "Fujairah Intl", at: 25'07'09"N 56'19'44"E Other instances can be found near "Dubai Intl", such as: 25'18'13"N 55'21'57"E To widen the scope of this thread a little I've found another few building models to draw attention to, after having another quick 'bounce' around from rooftop to rooftop. (Do heli pilots all have an inner desire to be Santa or something?) Though this time the problem is that they are ... um ... too solid!? Feisty little beggars, they actually punch back! Made from some exotic high-vibration material perhaps, when you touch them they actively exert a short sharp repelling force. If you manage to bear down on them with full weight they constantly kick up on the heli causing it to bounce around. Examples of these 'punchy' buildings can be found here: 25'18'16"N 55'21'57"E 25'18'16"N 55'22'01"E 25'18'24"N 55'21'58"E 25'18'26"N 55'22'02"E Attachment 4 is an image of one of them getting so frustrated with me sitting on it (fair enough I suppose), it catches fire (sure, a natural response under the circumstances). This is after having fully 'landed' on the roof; you can see the skids at the front have been kicked up by the 'special' forces at work. All testing done with the Huey, but I don't imagine the building model physics would differ by module.

Refueling... In the air... I think it may have been mentioned a couple of times during the last decade of DCS so forgive me for bringing it up again. I just want to share something that, for me, has been the single most useful/helpful thing to consider during air-to-air refuelling, which I've not seen mentioned in any of the recent AAR discussions I've read. I call it: The "BOX". Put simply, 'all' you need to do is stick your aircraft's nose into the box, slowly enough and steadily enough for the connection to 'snap in'. Now then, the only slight and very tiny issue (hardly worth mentioning really) with this method is the fact that 'the box' I'm referring to is entirely imaginary. Invisible. Non-existent. Finding it should be no problem at all! To begin learning where 'The Box' is exactly watch some videos of others doing it successfully. Also, your own trial and error - pick a sensible point where it could be, get there and see what happens. After a few successful connections (no matter how brief) you quickly start learning the basic location (and size) of the magic box. COMPLETELY IGNORE the position of the refuelling boom/basket (and your port/probe) and focus entirely on driving your nose carefully into 'the box'. COMPLETELY IGNORE the HUD, the instruments and everything in the cockpit. There is no cockpit; there is only your aircraft, floating nice and controlled in the air. The moment I stop trying to 'do a refuel' and instead attempt to simply fly in a small area relative to the tanker I find I have a lot more success. My control of the aircraft noticeably increases and I am more relaxed. As your eyes take in the 2D image projected by your monitor(s) your mind processes the information and formulates a mental model of the 3D space represented by that 2D image. Concentrate on the position of your aircraft relative to the tanker within the 3D space. Deliberately evaluate and appreciate the distances within this space, between you and the tanker. Now start imagining where that 'box' sits relative to the tanker. Focus on the position of that box and drive towards it, as controlled and steady as possible. Approach with no desire to connect; we are just going there to sit in the box, nothing more. Sometimes while in the box connection will be made, sometimes not. Staying calm and relaxed, we are doing exactly what we came here to do: just touch the box. Touch it, float in it if possible, and then come out again. In, wait a bit, out. Your aim is formation flying only. Get to the box. Get in the box. Stay in the box. Connections come and go, but that's not important. The box is key. Ignore the booms and baskets. When initially approaching a boom it will be sitting lower than it will eventually be for connection. Driving towards the boom at this stage will put us too low. IGNORE the boom and go for the box. Once in the box the boom operator will do his job and come hunting for YOU, don't go chasing him. Your job is to just sit in the box. While approaching a basket it will be floating all over the place. Don't chase the chicken. It will pass through the box frequently so just sit in there and it will come to you and snap onto your probe. (Probe/basket magnetised in real world, or 'assistance' provided by the sim?) A couple of other points, discussed to death a hundred times over the years, but just to reiterate again here for convenience: - Get the aircraft reasonably well trimmed (perfection is not necessary) - Physical joystick and throttle controls (as opposed to keyboard/mouse) is surely essential - Control axis 'curves' and/or 'saturation' applied to help soften the sensitivity of controls (dampen your movements) - Constant gentle 'prodding' movements of both the throttle and joystick is necessary the whole time (rotorheads might appreciate this as a likeness to the movements required for hovering) And finally: Wake turbulence ... wow, just WOW! Probably best to disable this effect during the early days of practicing this procedure, but learning with it from the beginning will sharpen your skills to a razor edge and give you patience of a rock. ...or a computer-shaped hole in the nearest window.

I know nothing about mission building for a multiplayer environment but I am aware of something called "SLmod", written and refined over many years, providing common functionality for use on multiplayer servers. (Just in case you've not heard of it yet.) I've not looked much into this myself but with it being so mature in its development and widely used I'd be suprised if it didn't contain some features and functionality useful to what you are working on.

Control of the Viviane camera takes on strange/difficult behaviour when having lateral and/or vertical motion of the helicopter, or when the heading of the helicopter and the camera are offset more than a couple of degrees. I appreciate the general gist of this has been raised previously in another thread (https://forums.eagle.ru/showthread.php?t=239478) but I wanted to create a new clean and concise thread to see if we can lay down a definitive response to this behaviour and what, if anything, we can do within our own DCS controls setup (or something else) to help address it. I've not yet to nailed down the exact causes (helicopter movement, helicopter/camera heading offset, other factors) but from my observations having even slight movement of the helicopter makes the camera more difficult to control. By this I mean the camera's response to control inputs is more 'sluggish' and do not always feel like they entirely correspond to the control inputs being made. Sometimes, as reported by at least one other person, it even very clearly moves in the exact opposite direction to the commanded input. A couple of 'known facts' to reiterate and acknowledge here: The camera system does not fix/stabilise on any point in space or on ground (though my experience of it does appear quite similar to ground stabilisation). Likewise the camera system does not 'lock' on to objects; it has no locking functionality at all. Based on my own experiences and a couple of reports I've read from other people, it does indeed 'feel' like there are circumstances when the camera control is being unjustly effected by certain factors. The degree of helicopter movement I am referring to is too small to justify the magnitude by which the 'difficulty' of the camera slewing increases, and there's absolutely nothing I can think of to explain the 'inverted' control that arises at times. I've no real world experience of the Viviane camera system or even observations taken from videos, so ultimately this is all subjective opinion and instinctive 'feelings' based on past experiences of comparable but very different systems. Therefore I would very gladly appreciate comments or explanations from those more knowledgeable. Would the development team be willing to provide their thoughts and interpretation of how this system should/does behave? Any clarification possible on the factors and flight parameters that are known and deliberately intended to take such effect? Even better, perhaps there is something 'wrong' in my setup that can be resolved? Many thanks.

Give a man a fish, and you'll feed him for a day. Give a rotor-head a city full of tall things and you'll keep him busy for, well, frankly too long. There's no way he will be able to resist the temptation to spend a worrying amount of time excitedly bouncing around the city 'sitting' on every pinacle and shelf he can manage to squeeze his mistreated bird onto. But lo, what is our poor rotor-head to do when he plonks his pride and joy down onto yet another roof top only to find himself sinking down into the vacuous innards of the building? Is there an intention to make all structures 'solid' within this terrain (and probably applies to others too), or are there some technical limitations, not immediately obvious to us great-unwashed and unknowing plebs, that will prevent that ever happening? Cheers. (phew - resisted the temptation to call this thread "Sitting on hard things"!)

I know I'm late to the party on this but I've only just now discovered there exists such a thing as a 'powerline detector' - a device installed in helicopters providing an audible and/or visual indication to warn of proximity to powerlines. I discovered it in a youtube video about the UH-1(H): "zunO6iUVUT0" [16:07] (And this video gives a demonstration of the device: "CxsR_aA5XN8") What a great 'little' addition that would make, though I know right away the complexity of the technical implemenation would not be trivial of course. I don't know how the powerlines are implemented within the terrain technology of DCS but this would likely require an additional 'layer' of information in which to indicate electro-magnetic distubance zones to be simulated and 'detectable' at a stregth relative to the distance of the obsever from the epicentre of the zone. <Insert scientific-sounding ramblings here pretending I know anything at all about physics and electricity> Perhaps there is a 'cheap-and-cheerful' way of accomplishing some kind of close approximation (re-use of the existing radio signal attenuation mechanisms/algorithms). Well, just a thought.

I've recently played through that campaign too and yes I recall some difficulty with the first few night missions. Luckily though NVGs are not prohibited for the entire campaign, they become available a little later on. As suggested by someone else in this thread, a small 'cheat' that made the mission possible for me was to increase the "Gamma" value in the DCS settings. It wasn't necessary for me, but bear in mind you could also adjust the settings on your physical montor too (brightness, contrast, gamma). Keep us posted on what, if anything, works for you in the end.

Apologies if I misinterpreted, but was there a potential plan (back in 2017) to revisit and enhance the simulation of hydraulic failure? (Some very articulate and comprehensive comments were made by customers to suggest a better simulation is possible than the current 'random cyclic wandering' model) Is there anything the team can now share with us regarding whether such work made it on to a todo list and has or will receive some attention? Many thanks.

[sOLVED] As suspected there was a small unintended, undocumented feature (zarro boogs in my code, I tell you!... Plenty of features though) in my menu item removal code. With that feature knocked on the head, the whole menu-management process is conforming a lot more to expectations. Thanks for listening!

Are there any known quirks or issues with the radio menu management functions? (missionCommands - addCommand, addSubMenu, removeItem) These functions are too mature and too widely used for them to contain any obvious flaws, so the root of the issue I'm having must surely reside in my own code. Nevertheless I've been stumped for two days on a particular strange behaviour I'm seeing. Without looking for the time being at any code that comes before it, can anyone make sense of what is happening in this small snippet described below: [color=SeaGreen]-- where: child = "ccc" and parent = { "aaa", "bbb" } -- ... output to log file the values of 'child' and 'parent' (simple serialised version of the 'parent' table) ...[/color] newMenu = missionCommands.addSubMenu(child, parent) [color=seagreen]-- ... output to log file the value of 'newMenu' (simple serialised version of the table) ...[/color]And what I see in the log are the correct values of 'child' and 'parent', but for the value of 'newMenu' instead of being { 1=aaa, 2=bbb, 3=ccc } is the same as 'parent' { 1=aaa, 2=bbb }. So at the moment immediately prior to calling addSubMenu() I can see the parameters I am passing are correct and sensible, but the returned value indicates the 'child' parameter has been ignored or something. Are there circumstance in which it might be valid for the addSubMenu() function to behave like this? (I.e. simply return the given parent, without actually adding the child to the path) It may be relevant that prior to the point at which this issue occurs there have been several submenus and commands added and a submenu removed, all of which appear to have been performed correctly with no such issue. One thought I have at the moment is that perhaps after having made a call to removeItem() (to remove a submenu), some kind of corruption has occurred to the radio menu data structure internal to the DCS environment. But like I said at the start, I imagine this code is far too mature by now to have any such issues gone unnoticed. So what factors on my side could be influencing this? Thoughts appreciated. Thanks.

Thanks for your time and effort on this 'unclothed-toes', it's very much appreciated. Yes I get what you're saying. It requires a different approach and thought process to be applied. (Though I was kind of hoping to get through life with as little thinking as possible - brain-cycles are costly) I do try factor my code into generic, 'black-box', reusable components as much as possible. (A place for everything and everything in ... a huge disorganised mess in the middle of the floor?) I currently have such a 'utility' function doing a thing, and I'd really like it to have completely finished its thing before handing back control to the caller, so that the calling code can then proceed as appropriate, safe in the knowledge that the 'thing' is done. (As an example: reporting back to the user "Thing complete" - wouldn't make sense if in fact the thing was still in progress.) The root of the issue stems from the fact that, the work of our utility function (which is a well-behaved little function that has no knowledge or direct interaction of the world outside of it) involves scheduling a bunch of processes, each to occur at varying times in the near future. (Just a few seconds, which is why I would even consider 'sleeping'.) It is only after all of those sub-process are complete of course that our good little function should advertise itself as finished. I can see the road ahead, and it's a somewhat obscure web of scheduled processes, callback functions and state/finished flags. Asynchonicity ... what a city to live in! Just to think out loud for moment, here are my initial thoughts (ideas, criticisms and helpful hints welcome): The original calling code can pass in a callback function (thingComplete()) through which it can be 'notified' of completion (i.e. execute its 'post-thing-processing'). The util function kicks-off (schedules) each of the sub-processes. Each process invokes their own specific code, which all finish with a call to a common subProcessComplete() function to declare completion. That common function must then somehow monitor overall progress of the sub-processes (it will need knowledge of how many were started and maintain a record of how many have checked-in as finished) Then of course, when startedCount = completedCount it can finally call thingComplete() I can't help feeling this is either over-engineered, or not nearly engineered enough. Something doesn't sit right with me. For a start, this means the original thingComplete() callback reference needs to be passed down into every sub-process, which in turn must each pass it further down into the subProcessComplete()function, so it can eventually invoke it. What a mechanism just to work around an inability to sleep for 5 seconds :) Thanks again.

Hi all Within LUA script I am trying to implement a thread sleep/wait/pause, but in attempting this I am running up again a whole chain of blockers. I have read the 'official' line on the subject (http://lua-users.org/wiki/SleepFunction), and they all require the use of the "os" module or other 3rd party libraries. Brick wall number 1: Accessing "os" module The "os" module doesn't seem to be 'automatically' available to my lua script. Is this right? For example, trying to call "os.clock()" gives me: "attempt to index global 'os' (a nil value)" Brick wall number 2: Calling "require()" Perhaps it is necessary to 'import' the "os" module? But trying to execute "local os = require("os")" throws up: "attempt to call global 'require' (a nil value)", suggesting that not even the require() function is available to me. I'm sure it's something wrong on my side because I've seen posts referring to the use of os.clock() (even seen it with my own eyes in SLMod code hosted on GitHub). So I'm hopeful it is indeed possible to call os.clock(), but where am I going wrong? Simple 'clean' steps to reproduce: Create new mission Add a player unit (TF-51D - Takeoff from ramp) Add a ONCE trigger to DO SCRIPT: trigger.action.outText("os.clock(): " .. tostring(os.clock()), 4, false) [*]Run mission [*]"attempt to index global 'os' (a nil value)" Thanks

Preliminary test results are in and it's looking good. Thanks once again for the pointer Grimes. ('Grimey'? 'The Filth-Meister'? Sorry, Mr G) With a quick and dirty probing (hello sailor!) using the suggested function I've been able to determine the 'ID' values of the doors on the Huey: Cockpit Doors: 38 Closed = 0 (Fully) Open = 0.89999997615814 [*]Left Gunner Door: 43 Closed: = 0 (Fully) Open = 1 [*]Right Gunner Door: 44 Closed: = 0 (Fully) Open = 1 These 'draw argument' values seem to represent an analogue 'position' of the component at any given time within it's possible range of motion. Presumably all values ranging from -1 to +1. For the doors on the Huey it seems 0 is the lower bound representing fully closed and, for the gunner doors at least, 1 is fully open. Curiously the cockpit doors don't open fully to a value of 1, instead consistently coming to rest at a value of 0.89... (Note to mechanic: the cockpit doors need calibrating!) Of course these IDs are subject to change at the whim of the developers at any time, but I can't imagine them wanting/needing to do that often/ever. I'll look to build a more comprehensive list of these 'component' IDs over time, especially for the Huey and the 'Humble' Eight. (Unless developers of modules would care to save us plebs some time and open their windows a little to let us peek in) Cheers

Thanks that's great, it gives me something to work from. I'm thinking a small piece of brute-force inspection should help figure out the 'bits' of interest, like doors: Trigger a script on demand that logs the result of Unit.getDrawArgumentValue(n) for values 1 to, let's say, 200 should do it. Comparing the values returned before and after jiggling the 'bits' of interest we should be able to see which values are changing and to what. I'll try it out tonight. Thanks

There's no API available to LUA scripts for "SET INTERNAL CARGO" is there? Just checking I'm not missing something blindingly obvious. (I have the natural work-around in place, but it's not a very elegant solution having a separate trigger configured through the mission editor for every possible internal cargo value we may want to assign.) Related to assigning 'internal cargo', for immersion purposes it would be really nice to monitor the state of the doors on a unit and implement cargo loading procedures accordingly. Specifically, of course, I'm interested in the UH-1 Huey and the Mi-8 Magnificent (and so modest!) Eight, but the broader question still applies: How do we inspect the state of 'components' on an aircraft from within LUA script? I think the 'devices.lua' file (and probably others), for each aircraft is going to be of use with this, but it's not entirely clear what we're looking for in those files or how to make use of the values. The immediate, direct, question is: how to detect left/right side door open/closed on the Huey, and equally for the Mi-8 (side and cargo doors)? But I'm also looking to learn more about general concept of monitoring the state of 'components/devices' on an aircraft from script. Thank you kindly (Slowly learning how to spell lua)

...it floats! ... until you throw a rope at it and break its concentration from its levitation act. On these cold, dark, November winter nights (Northern hemisphere chauvinism!), if there's one thing that is sure to lift the spirits then writing scripts to randomly spawn cargo all over the place always does it for me. But is it right that a crate spawned on water is immune to those pesky effects of gravity? (It sits perfectly still on the surface of the water). It's only when attaching to a cargo rope that it suddenly 'crashes' back to reality and dies like it should. On a somewhat related note (if you squint hard enough and stand back a bit), is there a means of specifying an altitude for dynamically spawned statics/cargo? Thanks!