jross194

Any info on this yet? Tried again to get this to work via a script. Still no go. Works 'manually' via the F10 map as advertised however. Thanks. Pretty sure it worked in 2.7.

I could kiss you. Been trying to get away from LDT for months. Never had time to figure out how to get this 'attached' in VSC. Thank you SO MUCH!

5900X / 64GB RAM / 3080Ti / Reverb G2 - keeping my entire system as clean as I can. Medium+ settings... In VR -- with 10k lines of lua code running - custom mission generator to make it the combat flight sim I've always wanted ~35% FPS increase. FWIW, in 2D it never strayed from 180 (fpsMax value in graphics.lua). 70+ FPS on the Supercarrier deck; turning to look at it and it stayed steady (I tried not to look at it before as things would deteriorate). And - the Simulation value (Ctrl + Pause X2, middle of the output) never got off of 0 - ZERO! I believe this means it's churning through all the trains/planes/automobiles (and missiles, bombs and bullets) pretty quick. Or that value is broken? It doesn't like switching F-10 and back. CTD three times. In it's defense I do have a couple dozen drawings there (polygons, lines, arrows, text) but nothing too, too, crazy. Now, where's the bug thread for that...searching...

I'm the opposite, but to each his own. My main point was, if you prefer specific effects (G-force for instance or stalls), with the ability to pick-and-choose (ala SSM/SSA), then, like FFB joysticks, having the DCS engine spit this data out directly should eliminate or greatly reduce the latency. I think it's been mentioned above - as is it goes through lua (Export.lua), then an external application, then to your sound card (real or virtual. I use a cheap USB sound card and it's better than a virtual one but still noticeable, but not so much that I'd turn it off. I'd think if this process was the same for a FFB joystick (or racing wheels in a race sim) you would notice more delay from action to response [feel]. When I yank on the stick for instance I "Feel The G" (scaled to how hard/quick I pull) but it's just a tad later than the observed motion. I haven't used a FFB joystick in many years but I don't recall that being an issue, cus the [at the time] DX input stuff spit it all out directly to the hardware, without having the extra middleware. For those that have never used haptic feedback: if they supported it directly more people might try it (the sellers of the hardware - Butt Kicker, et.al - might be happy?). And IMO it has become mandatory (at least in VR): I can't 'fly' without this anymore. FEELING the sim is a game-changer, using sound only (and all the extra 'noise' that produces) or physics/specific output only.

Everyone, including me, feels that their One Thing is really important. My Wish List post was viewed 100+ times; no response (positive or negative); scrolled off; never to be heard from again. So...It's _tempting_ to feel like ED doesn't WANT me to expand on their sandbox. I know, I know, that's bordering on hyperbolic but around the "water cooler" this sentiment has been emoted by myself and others. I get it. I understand how complex this all is. It just feels like I, we?, are shouting into a void. My "Wish"[1], again in my opinion, could go a long way towards me providing the player a useful AI wingman - but I get crickets (I'm not the only one that's broached this subject BTW). Yet I don't know if ED is planning to do this (add this feature) and therefore ignores it. Would be nice to know, even if it's just a "We're looking into this". Anyway... Off the cuff: might there be an additional button here, in this forum, people might punch to "elevate this" - the "Like" button would seem obvious but doesn't appear to me to be used, or thought of, in this manner. Just a thought. The ME is "okay" but I don't realistically expect them to spend the man-hours required to rebuild it - ick. LUA is, IMHO, the only real way to do anything useful (complex) - the ME gives you a start and, I suppose, is a necessary entry point (for learning and to kickoff your lua code). Meaning: I personally don't need you to support all the possible paths an underlying function might produce in the ME - I'll do it myself. It's the low-level, basic, functionality that is important. Finally, and my over-arching point: The creative types that seem to haunt this sub-forum can - will (cus they 'have to', by nature) - expand on your product in ways the ED team doesn't have time to. This will give DCS the 'legs' it needs to engage customers for years to come. MSFS would, IMO, be a fraction of what it is if support from third parties (and not just building texture maps) wasn't in place. Oh, and thanks to those that have provided help here - and ESPECIALLLY to @Grimes I'd be lost without that wiki and your responses here over the years. [1] Making your AI wingman semi-useful. In addtion to: I've written about 10k lines of lua, using only single page of triggers (would be maybe 2 triggers if another 'requested feature' was implemented) that, for Single Player mode, does: - Air Traffic Control (simplified but the structure is there to expand on it) - Audio comms between the player an my AI 'agents' (ATC, ABCCC, etc) to include a text-to-speech engine (using nothing but lua) - Whole lotta other useful things that bring the "World" part of DCS World to 'life'. All in lua. Using less than ~2% of LUA CPU usage (difficult to measure exactly) I'm sure others have done the same, and better. I'm just trying to give an example. The point is: give us the low-level functionality and someone will do really cool stuff with it. Stuff that might keep your other customers more engaged (and therefore more likely to purchase more of your products).

I was really happy to see that. Might this be done on a regular basis? Say, once a year, when you do the "20xx and Beyond" thing?

Request Generate an event (or some other mechanism) when the PLAYER (in Single Player mode) identifies an arbitrary unit visually, allowing me to use that specific unit for some purpose. Background Currently the "Cockpit Visual Recon Mode" mechanism allows the player to 'look at' (point their head) and select a unit. This unit is, somehow, being used internally to make all AI aware of this object. However, it appears to have several dependencies based on the AI logic - they will only 'see' the unit under certain circumstances (for example: what sensors my wingman has; the number of units in the group, etc). Rationale & Benefits As the "Flight Leader" if I can see the unit (single APC for instance, in a grove of trees perhaps) then it can be reasoned that my wingman should be able to see it also - imagine that I have "talked him on" to the target. Obviously I can't talk to the AI as I would a human being. IMO this one item will allow the Single Player, player, to get much more combat functionality from their AI wingmen and broaden the game play for air-to-ground missions from any era simulated in DCS World. The existing API will allow me to expand on this selected unit: get the entire group; evaluate it (type/speed/position); decide actions allowed; etc. Thanks JR

Does this ONLY work in MP now (I don't do MP so haven't check)? Before I could, via a lua script, use markToCoalition(..) and it would pick it up. Now it only works using the F10 map interface to place a marker. So something has changed either in the way markToXXX() is implemented (I haven't found anything in the change notes) or how R-Bam is doing it, or both. I've tried it with markToCoalition/groujp/all and no joy. The string output is: #TPn where n = tostring(nextIdvalue), where nextIdValue starts at 1 and increments. As follows: local nxtMarkId = 1 ... local outString = "#TP" .. tostring(nxtMarkId) markToXXX(nxtMardId, outString, vec3, etc, etc) nxtMarkId = nxtMarkId + 1 ... Thanks ahead of time. This was really, REALLY, useful in SP mode.

Thanks for updating your post with a solution. Doesn't always happen.

I've found that you have to, as mentioned above, treat your AI wingman like they are of very limited capabilities (cus they are). Drive around with the 'Bot' in mind at all times, to include departing the field (once you've been able to keep him from colliding with you on the taxiway or during takeoff). Departing: make sure you actually get airborne first, ahead of them; if you rotate too soon before Bot does then extend a bit, wait for the "Airborne call" [from him]; keep your RPM at around 90 percent-ish - they are horrible at joining up (related to AR below) and tend to follow a bread-crumb trail to you, not understanding lead pursuit so much. Keeping your speed below max will help them rejoin sooner. This, to me, kinda of makes sense in real world terms too - if you understand it is Training Day 1 for your wingman (they are new to flying). AR: I like to have them move in closer (F10..."Close Formation") and if doing AR from the KC-130 (2 baskets) put them on the left (not a big deal but why not). Then I 'fly' us up to about 1 NM behind the tanker before giving Bot the "Goto Tanker" command. I've not examined this in great detail (would be easy enough I guess to watch the replay) but there's a point behind the tanker they will move to regardless of where you are when you give the command; roughly 1 NM seems to work fairly well - they get on the basket much quicker. It also appears they set their speed to about 5 knots faster than the tanker no matter how far back they are - give the command too soon and you will be waiting a long time for them to creep up to the basket. You can also give them a "Rejoin" command to prevent them from filling up to 100% in cases where you don't need them too. It's very helpful to know how much gas they actually have but I had to write a script for that (keeps them from running outta gas during the mission by checking with them at various points along the way). I _think_ ED has added this? Or will. I'm so used to using my own script so haven't paid much attention to this historically missing feature.

This fxn has always (V2.5 - V2.7) been hit or miss for me. So much so that I've stopped using it, which does add extra work. Needs vary but, for me, if want a 'thing' to go somewhere I build a new 'mission' task. Yes, a PITA, but only have to do it once.

FWIW, I've had issues with scheduleFunction() working UNLESS I added some amount of time to it, never 0 seconds. Was intermittent enough that I just started adding it by habit. Not sure this is correct procedure though. My take on it was, by the time DCS did "Other Things" and got back to your fxn call that time has come and gone and that call was 'purged'. Basically it must be some amount of time > timer.getTime(), even if only, say, 0.01 - I have routines that splice multiple calls to this fxn, one right after the other in essence, and I have to have _some_ amount of time here or they get 'skipped'. This is going back to DCS 2.5, so try this: timer.scheduleFunction(TRMS.DisplayCountdown, TRMS, timer.getTime() + 1)

Yeah, they are really NOT efficient when it come to maneuvering. It doesn't look much better now that I've watched it more (since seeing this thread). So, I try to keep things _really_ simple in the case of: depart airport; fly a simple route; wait for some event; blow something up; RTB. If - IF - I keep the initial climb such they don't have to make a big turn, while climbing, they do fine. I stay under about, oh, 30 degrees. Otherwise they spin around seemingly waiting for -2 to get into position, before resuming the climb. If I make it a 'gentle' turn the do okay. I insert what I call "transition" points for the climbs, no closer to the airport than about 25 miles (with the less than 30 degree turn above). It seems they do their own thing until about 20 miles after takeoff and you can't change that. So my routing for them looks, roughly, like this: Home -----> T-Point(alitude, speed) ----> Waypoint[1](alt,speed) -----> waypoint[2]...etc. Do the reverse after bombing - they could be at any altitude. It is tedious but only have to get it right once. And I've given up on getting the AI flights to refuel in an efficient manner for instance: it take 10+ minutes for a flight of 2 Vipers to fill up (only about 10 minutes after departing), even when they start within 10 miles of the tanker. They're not real good a 'joining' on the tanker in an expeditious manner. So, I just don't do it (except on the return leg but timing isn't an issue then).

This is likely a dumb question but where do you get "base_code_dir" from? For use on another machine. I use a similar scheme but, in my case, the 'base_code_dir' is specific to my install and won't be the same (different user for one) on another machine. For a 'release' build I use DO_SCRIPT_FILE and to get them all into the miz but would like to skip that chore (there are about a dozen files, 12K lines of code, all in separate 'modules'). Coding it all up is one thing but I'm sure I'm ignorant or missing something here. Thanks ahead of time.

I just ran my scripted mission. Not seeing this - however, I've been micro-managing the routes/speeds/altitudes for some time. Only way to keep them under control. All done via lua with what I call "transition" points for climbing and descending.