Pikey

mmm, something that might be of interest to you is the successor to DAWS, which is DSMC, a persistence tool that goes much further than mine and runs as a plugin outside of the mission environment. It can save warehouses and can handle the movement of ships and carriers and also the spawning of clients from those between restarts. I'm currently helping Chromium in AMVI to thrash out any bugs in it. It still wont create farps though. Another possible design is by creating the small farps (single helipad) and putting them near a road that has a steep incline right on it so that half of it is "roll on". It would be roughly equivalent to having a mod to make a smaller farp, of which there is a marston matt mod out there. Capturing a "Matting" isn't something players will be de-imersed by. You could put them in several places as "options" and thus not create such a linear path.

Not how you think it. I think you can spawn the 3D object of a Farp, but no services will be provided. It's just how DCS is. Also a CTLD "FOB" is not an airbase, just a location where you can spawn things via menu. So no good for refuelling/rearming. However someone did work on persisting CTLD which is where you want to go, at least for having your spawned fobs still work after a restart. The basic premise is that CTLD holds a list of tables where the FOB objects are, another list of tables for SAM's and so on. Using table.insert you can add these after CTLD has run. It's obviously more complex than that, but that's the overview. If you don't know where the Farps will be you are unfortunately SOL. But FOB's and CTLD is acheivable with some work. Rob Graham did that. it's on GitHub but I feel awkward linking it directly to the forum, even if it was public (as last time was WIP and he wouldn't want to get the blame for someone thinking it was public consumption ready if it was slightly buggy) If that is still of interest then DM me, it's not a straight road from here on. However for FARPs (and oilrigs and even the incomplete grass airstrip (oh noes they removed that half attempt from the game ;) ), nadah, please put it in the wishlist, maybe another 5 years and ED will do it, no one knows!

With the ME you would have to create the replacement infantry groups beforehand, there isn't a native "Spawn" mechanism, just an appearance of spawning by activating a group that was previously marked as "Late activated". So create them in pairs, a live group called inf and late activated group called inf2 Create a trigger "REPETITIVE ACTION" Create the condition -- "group alive less than" < % and point at "inf" Create the action GROUP ACTIVATE "inf2" group.

This earlier post discusses that right click and how to do scenery https://forums.eagle.ru/showthread.php?t=264623 You can use the object ID returned from the right click in an event handler or the mist method. The two are fundamentally different in that one does the core world search objects function and the other does nothing and just waits for something to die and checks the ID against the ID. The world search objects method is good for multiple objects in a zone, but could rely on the size of your zone, whereas the EH will only look for that ID. I've used both, leaning towards world search objects with multiple scenery in a small place or making aggregate destroyed % in a zone and EH's used singly for specific alerts when the destruction happens. Depends on a few factors which can be better/easier.

Doesnt work, have no idea why FC put it in, it's probably theoretical if it had been implemented. There's a few things like this in MOOSE. Learning DCS is harder than learning a scripting language with all it's nuances and bugs. A mission is run once from the mission file and clients will be what is in the mission and cannot be changed after runtime, much like time of day, there's no available API method for that. Check DCS Functions and singleton functions for what is avialable. EDIT: You deleted your post with the reference to the ClientSpawning in MOOSE so my quote and all the context of this message disappeared.

(worth noting MOOSE is optional, you can look up timer functions and do spawns old fashioned way or use mist, the method doesnt matter, its just the format of how to create the appearance of doing what you asked)

You were fine up until you said, "Spawn a Farp". "Spawn a client slot" Then all hope died. That is not possible. I began asking before 2015 for that. What you need to do, which is the tried and tested very commonly accepted way to do this since 1.5 released those years ago, is this: Use Ciribob's "Simple Slotblocker" Create the FARPS beforehand. Make them neutral or red and create the slots for the Harriers and lock them so they can't be used. Create a scheduler in MOOSE which checks the coalition of the FARP. Once it's BLUE, spawn in your service vehicles and set the flags for slotblock to unlock the harrier slots. Rinse and repeat. Then you have what our server is, which is a type of Blue Flag for PvE. Incidentally, I wrote my group persistence script for this: https://github.com/thebgpikester/SimpleGroupSaving so I dont know if your chap that found a way needed to write anything at all, it's a right pain to come up with solutions for that.

It's not just 2.5.6 because our severs that even have slotblocking, dont suffer from this pause as described. However I have noticed when the server is under load I have seen a new effect that does cause a delay (not that long, but nearly) and it was different, server to server and time to time. Something has changed, but it doesnt always cause that effect.

Thank you indeed for feeding back, this is a fairly common question and I will relay to MOOSE discord and sticky this information, several people will be delighted this can be done! Cheers!!!!!

I've found most of the things I've shared over the years, people improved on, and the rest, people just wanted to know how they could change it so it worked the way they wanted it. I've never seen anything that original or decent that wasn't shared already. Having said that, for our server we do call the files off the network, because it's easier to change them and share on a dev box. One mess up and you can change it in flight and the next reboot its done, whereas embedded scripts require repacking them and cannot be done to a live server whilst running, requiring downtime at the reboot or stopping it completely, neithe rof which you want to do from a phone when you are out. I could easily precompile and pack them to keep idiots away, but I find people ignore it more if you actually put it up on Github. Go figure. There's nothing worth hiding these days. Fame and fortune is for the greedy.

HA! omg, i was thinking yesterday... "I'm sure there was a tacan here, it was always so difficult to get inside the canyon"

Exactly. I just want 2.5.6 lighting with 2.5.5 right now. Rushing modules out when things are all over the place is begging for more drama

I don't remember anyone having luck with the intellisense part so you are on your own here. If you do have any luck try sharing your findings here and on Moose Discord if possible, I know a great many people would like to move away from LDT.

I think we all share that sentiment. It's a bit hard to get anyone to use it whilst it's not got those in cockpit features, that's the other edge of the double edged sword that is OB.

This has been known forever. If ED were wanting to change it, they would have.

I think so based on what I see in the design. I think to meet your requirements the message would be On demand only, and the actual menu item would be force removed each time it was called and force added on the timer. That's why I said you have to decouple the menu part as it's doing the menu higher up. It's a bit messy to consider an easy solution, but short of having a timer running for each player (not a good solution) you would have a central timer and each time the function was executed, remove the menu until the timer is up and then rebuild the menu.

Why are you asking about Lua? Lua is not where the magic happens, Lua is an embedded language. If this is about an interface between games like DCS, arma and Command you will be using Lua for only tiny parts of that, right at the end. First issue is none of these games will agree on coordinates. Assuming Arma had a PG or Caucasus map in the works. Do you have a professional profile to share with us on your design experience? Previous projects perhaps? The question didnt come across well because of the way Lua was brought up.

For VR workflow it's awkward. DCS supplies a customisable kneeboard for simple 2D work. It will accept a copy paste of most images and is quite ratio friendly, but keep to the ratio to avoid distortion. I use a small tool for copying and pasting in VR https://forums.eagle.ru/showthread.php?t=229077 good for coordinates on the fly like CAS, although nothing beats touch typing skills or binding your UFC numbers to numpad. There is a full on VR tool https://forums.eagle.ru/showthread.php?t=246970 that I am yet to try out, mostly because I can't find my old tablet. Dont bother with trackir, I gave mine away after a decade of customer loyalty, you cannot swap between them and "de-helmeting" from VR once in it is about as fun as stopping sex half way.

You purchased that in one shot? Here we go girls and boys, this is your proof that it's not worth aiming for "Fighter pilot". Airliners is where the moneys at! :P Advice... be very patient with DCS. It takes a long time to get used to it and it's quirks. It has a bit of a glass ceiling and can cause frustration. The frustration is mitigated by some of the most compelling multiplayer experiences I've had in any PC game, where humans bring everything. But there is a wide variety of experiences to be had. Finding the right group (and there are plenty of real world aviators and such in groups) is vital to help you over the bumps with the software. Take the Hornet, since the F-16 is a bit behind in development and you are getting both (and then become addicted and want to fly anything) you can afford to wait a bit whilst the development catches up. Please do look at all the modules, the current array of full modules has some extraordinary differences in them. One of the most compelling things is watching the cockpit designs and workflows evolve from Post war all the way through 50 years, like how the early Migs took something of the German and British designs both, and then trying to get your head around Russian design philosophy. Assuming you are interested in aviation in general. That might be some years down the road, the American jets will take some time to chew through anyway.

A little script to explode any unit over 50% damaged would help. I do this with AI planes that are colliding or taking their sweet time or stuck somewhere in some scenery. If DCS AI was better there wouldnt be so many "bullets to the back of the head for subordination" Most feared job by AI? Has to be boom operator on a multiplayer server.

Post back if you get it fixed at some point, I have plenty more, including Bridges that AI dont want to pass under (superstition) Flyovers and junctions and slip roads that confuse routing to go backwards Routing that was decided by an out of date Garmin map from the 1940's Hopefully one day routing is more reliable and AI moving didnt crash multiplayer servers, until then, might be best to create multiple waypoints and switch on road/offroad, or if spawning without a route template, routing off road to a zone, then routing it back on when it arrives in zone (yes, lots of code just to get a truck to go somewhere)

You talk of this nirvana, sir. I'm sure the only reason there is so much bad flying is because of four button joysticks with everything mapped to "FIRE". Also you can't say that on these forums or someone will call you an elistist nerd and attack your way of life ;)

This looks like how the A-10C pilots caused much SRS support in the begining. The volume knobs on the radios defaulted to 0 and folks didnt understand how they couldn't hear on the radio because they forget to operate their radio Raisuli - AWACS and menu comms from the game have nothing to do with SRS and player conversations. Your screen messaging from Awacs, wingman do not use your configured radio volume in cockpit. However, if you have realistic radios set, then they do observe if you have them on and tuned to the correct frequency. However, SRS, for the complete modules and not FC3, will observe everything set in the cockpit, including volume, modulation, and often the power setting too, if the set has one. Also includes encrypted raido support where the module has it. You probably didnt hear anyone because .. humans. And often you get humans log into SRS, ignore it and speak on Discord or a.n.other comms. And yes, one day you will call buddy spike, on the correct frequency and some dipshit will shoot you down anyway. Because... humans.

It's the same with normal airports. AI does it's figure 8 lineups at an airbase, usually with wheels down and afterburner and for some reason, and even more so now, on an empty airport, it just fails to line up and repeats the fig 8 approach many times. It can go either way, there's no reproducibility about it, it's inconsistent (and I believe the plane type even affects this). I've no idea what the AI algorithm is waiting for. Had the airbase/carrier had something going on on the ground, I'd understand it was queuing for some ATC, but I've absolutely reproduced with the only airplane in the sky and a free airport. Can be 2-10 times that it loops up to ejection from no fuel. Also, not sure if it was anything to do with giving the plane an RTB comand or something Task related in the SSE.

Had a quick peek. OK so, the design makes this difficult, the menu is built every 5 secs on line 179 along with th etarget collection after, and takes the settings of either having regular updates or on demand updates. Would be a lot of effort to unpick that as you would have to decouple the ondemand call from entire menu function, but If you set to only ondemand and raise the timer, they will only get the last update (I think!). That's the fastest workaround I can think of. But I dont know if your objective is to discourage player use or just give delayed updates. Depending on that, depends on whether this is useful or not. function ewrs.update() timer.scheduleFunction(ewrs.update, nil, timer.getTime() + 5) ewrs.buildActivePlayers() ewrs.buildF10Menu() end Otherwise you need to dive in to the dreaded line '666' and pull all that out into a seperate function on a seperate timer.