Dangerzone

Is this open beta, or stable release. I've had no issues with stable release in FA18 with multiplayer. Just make sure that the brake is on so the aircraft isn't rolling.

Like others have mentioned - it depends on what from, and then to what? I've gone from Logitech 3D pro - to Logitech X56, then to Virpil CM3 with VKB MCG for the stick. From the 3D to the current VKB/Virpil setup - yes... it is night and day. That doesn't mean that you will magically be able to do it easy - but there is definitely a significant advantages to having the right gear. Think about it like trying to hit a baseball with a broom handle, and then a proper baseball bat. Night and day - however - even so - just because you have the right gear doesn't mean that you're going to be able to hit that ball right up - you still need practise and skill. (Thus a skilled person can probably still hit a baseball with a broom handle better than I with no experience could with a proper baseball bat) - but the right tools definitely help. For AAR - constant micro movements is what gives for a smooth AAR experience - and the more accurate a HOTAS is, plus the more travel it has (to give you that accuracy) - the easier the experience will be. FWIW - The X56 was the biggest waste of money I've ever spent. Too much deadzone in the stick, ghost signals, etc - it's anything but a 'quality' controller - and even though I could AAR with the X56 - moving to 'quality' HOTAS was definitely worth it for me. What also helps with AAR is to stop trying to AAR. Start flying formation, and get closer and learn to stay in formation. Huge progress for me when I started doing this instead of chasing the basket.

If that fails, another solution (while not elegant - does work as a workaround) is to have all the buttons on your throttle mapped with a mod button as well on your stick. So - in order for a switch to work / be recognised in DCS - it will only work if you're holding down the designated MOD button on your joystick while flicking the switch. I had the same problem you're experiencing, and went to this - until I finally got so over the X56's issues that I went out and purchased a CM3 instead. Re trackir - I have no idea sorry.

+1 on horstweihraunch's post. That is my first question too. You should be seeing these in your VPC Configuration first. Also - how have you got it configured. I have the following which is working OK for me:

Wow... things people are doing to raise some funds to buy a 30xx series graphics card. Jokes aside - some photo's and/or more information about your RV environment may help. I'm not sure whether monstertech hotas mounts might work or not in your environment.

Hi PravusJSB, Thanks for your reply once again. If I understand you correctly - spawning dynamically could actually be working against me because it's expensive for ground units? Does this mean I'd be better off having them all on the map at the start of the mission after all, but just set to inactive? (Knowing that they will still be included in any iterations). The idea behind making the DB of existing units is to have a cache, because the units would be destroyed. ie: At mission start: 1) Create a database / Cache ground units on the map (could be a few thousand) 2) Destroy ground units from map, so that clients connecting have very few ground units - good performance 3) When client flies into certain zone - recreate ground units for that zone only, using the database created in #1. If I'm not mistaken (and I quite well could be - I'm very much a noob here ), the code above would only obtain the units that still exist in the mission editor, which wouldn't be available when I get to step #3? The reason why I was toying with this idea was to make it easier to design large missions with the ME but still 'cheat' and have it CPU friendly. I could use the mission editor almost exclusively. The script would automate the destroying and recreating of units based on what I did in the mission editor. (Maybe even to the point if I could make it 'good enough' that I could distribute the code so other people that don't know scripting could use it to make large missions friendly on the CPU cycles). However - it seems from what you've said this will only move the burden on the CPU from one area to another, and not fix the issue. If lots of units alive in the mission create problems, and dynamically spawning units in is also expensive on CPU, I'm not sure there's any other option remaining to achieve what I'm wanting to do. Thanks for saving me from spending countless days (or weeks) on trying to get this to work and then finding that it doesn't help with CPU performance. I'll have to rethink and see if there's yet another approach.

Oooh - I didn't realise that mist had all this information stored. I'll have to dig deeper into it. Thanks very much! This gives me some hope that I may be able to have my big missions after all. I'll have to also look at how you do the mob spawning. IIRC I think you have some missions on the dcs website in the files section?

Or can I.... I don't know if this is even possible, but I'm just thinking out loud. Would it be possible to create a script that does the following: Iterates through every zone that is on the map, and obtains data for every unit that has been placed there (from the mission editor). Create a table and inserts ALL attributes of each group that's in each zone. (Unit name, type, attributes, waypoints... basically everything needed to recreate it). Destroy every group that has been added into the table Have a once off trigger for each zone that when a player enters that zone - all groups will be spawned using the table created in (2). I have no idea if this is possible, but the idea would be to allow for very simple mission designing with thousands of units that don't impact the CPU much. The designer simply designs a mission like they would now, and then adds zones in various areas. My idea is to do the hard work (scripting) once, and then have it as simple as possible for designing scenario's later on, being able to re-use the script as much as possible. Does anyone know if this is possible (or better still), if it's been done before and being successful, or if this is a worthy thought worth pursuing?

Hi Cfrag, Firstly - thanks so much for the time you've invested in getting back to me with your thoughts and help. Just to confirm - it definitely works on multiplayer, and they're definitely not included in the .miz file (nor installed on the clients side). I invoke the code simply with a single trigger that calls "DoScriptFile", and I have a load script file. The script file that it imports has: missionpath = "c:\\missionscripts\\activemission\\" env.info("Loading Dependencies and scripts") dofile(missionpath .. "Moose.lua") dofile(missionpath .. "mist.lua") dofile(missionpath .. "ctld.lua") dofile(missionpath .. "csar.lua") dofile(missionpath .."missionscheduler.lua") dofile(missionpath .."missionevents.lua") env.info("Scripts loaded") ... with the above files being available on the dedicated server only. This actually works a treat. I have a dedicated server which this runs on. It definitely only runs on the server (clients don't have access to any of these), and anything spawned in, triggers, etc definitely show on the clients that are connected. I've tested with over 5 different clients simultaneously connected to the dedicated server, and it works 'as expected'. The only problem I have identified (which is fully understandable, but a non-issue for me) is if clients try and replay their own track files. They simply won't work because they haven't got the scripts available locally to replicate - but as far as the actual live mission/gameplay goes - I can confirm this definitely works. These scripts definitely use Objects, Units, Groups as well. That's why I was wondering if this helps CPU usage by denying clients access, yet the events still execute on the server, and the end fruit of it's calculations still appear on the clients. (ie, new units spawned in, events trigger, etc). I'm aware this would not work if I was to distribute the mission files for others to use (unless I distribute in such a way that they have access to all the files, and setup their servers the same), but at this stage my focus is more on trying to develop a large scale mission that by the end will have many thousand units that have populated the full map without CPU hits. If executing code externally from the .miz file on the server alone assists with this, I'm happy to use this method. Maybe I'm onto something here? (Although I can't take credit for this - I've seen this used elsewhere, I just didn't think until I saw your comment that this could be a potential CPU saver on the client side) This is what I was afraid of. I think I'm going to have to really change the way I develop. This approach is OK for non-moving units such as non-directional SAM sites in the open- because I can create a template and then spawn them in places out in the open when I want. I guess I can also add some randomness to it too - as to where it spawns inside those zones. I've also been toying with both A2ADispatcher and AUFTRAG for spawning airborne units (although now wondering if I should revisit due to not using Moose for CPU optimization). But even so, I'm struggling to figure out to: Handle spawning in units that I want specific pathing done (driving down a road, with turns at particular intersections, etc) in a particular manner, Precision spawning. (Where I want a group where each unit is placed in a precise location such as a corner of a building, or under a tree, etc) Direction of spawning. Such as Patriots or NASAM's that only have a 270° view Spawning in units with specific parameters/attributes assigned. (Such as going back to waypoints, changing attributes at certain waypoints, etc) ... basically all the more precision stuff that is far easier to just dump on a map. It seems like these would be a lot of extra work to do via script than via the mission editor, and I'd likely end up with hundreds (if not thousands) of zones to have that level of precision. I'm beginning to think that what I'm wanting to achieve just isn't going to be possible with DCS at the moment, at least not without putting far more time development into it than I currently have available. The glimmer of hope I have is that maybe the way I'm doing scripting means that it only executes on the server as it iterates through all the groups - and that may allow me to get away with a lot more than I normally could for now until I can come up with something better. But all in all - it looks like you've confirmed for me - putting units down that are inactive is not going to help me with CPU cycles. (It may help, but it won't eliminate the problem) so I can't just cut sick with units in the mission editor.

Thanks for that. It looks like I've been doing it all wrong right from the beginning: I've been using Moose instead of coding direct - Check I've been using Syria instead of Georgia - Check I've been routing vehicles via roads to use CPU cycles - Check I've been using SRS hooks - Check I've been using tables (a lot) - Check I've been adding all my units to the map (although most inactive), but looks like they'll still take up cpu cycles. Although I did disable tacview and tracks so I guess I managed to get something right. So I guess if I continue down this path I could get myself into a lot of hurt. Thanks for the tips. I'll have to try and reevaluate how I'm going to do everything - but I'm beginning to think it's going to be beyond me. Even something as simple as having a squadron of planes take off when there's threats in the area, be able to respawn x times if shot down within y minutes, and land when there's no air activity is something I was so grateful to find MOOSE - and even then am struggling to get it to behave the way I want... I think I'm out of my depth if I get rid of libraries altogether and try and code directly. As for I'll be thanking you in a year or two... I'm thanking you now... but I'm also kinda hoping my missions won't be needed then - and we'll have dynamic campaigns. Thanks cfrag! As for the lua code, I've done mine a bit differently. I have it executing external code - it's not in the mission file (or .miz file) at all. I don't know if this means it only runs on the server, and whether or not that is an advantage? (The reason I'm executing it externally and not including it in the .miz file is simply so I can make changes very quickly and restart the mission to continue testing, so I don't have to open up the mission, remove the unit, re-add it again, and then re-start the mission for testing). So - since the .lua files are server-side only - does that mean only the server is executing them, and will that be helping to reduce CPU hits on the clients? OK - that's a bit of a concern too. I was planning on having thousands of units on the map, but not activating them until they were 'needed' hoping that would help. I'm guessing this is going to be a bad idea, because with MIST (which is also in my mission as I use some modules such as CTLD and CSAR which depend on it) - it's going to create performance issues even though the units are inactive. One alternatively I've thought about is recoding so that I just 'spawn' or 'dump' units dynamically onto the map. This will work OK for some basic stuff - but will limit what I'm wanting to do by customizing the units and their functions depending on the locations of the map. I'm beginning to think that the idea's I've had are bigger than Ben Hurr and may not be achievable with DCS now. Neat idea re the pathing property in the zones though to control how vehicles will behave in the said area. I'll have to give this some more thought, but in the end - I'm beginning to think that each direction I take, I'm going to hit walls: If I go down the route of adding late-activated units (which I thought I was being cute with and would help)- I hit a problem with MIST and cycles once I get into the multiple thousands of units. If I go down the route of dynamically spawning units in when I need them - I hit a problem with not being able to be 'particular' in what they're doing easily, plus needing to learn how to do this all again without using MOOSE to optimize CPU. And then there's the problem of having more A.I. controlled air units that can take off, land, refuel, etc without using Moose (so no AUFTRAG or AI_A2A_DISPATCHER, etc) So maybe to start with I need to limit which units will actually move to avoid pathing CPU issues, and then limit what units have customised functions and just dump the same 'template' unit at various parts of the map and forget about doing the more involved individual customising stuff that I was planning on doing through the mission editor. Thanks so much for your replies. I was kinda hoping it would be easier to avoid CPU pitfalls but it seems as though it's far deeper than I first imagined and will be difficult to avoid unless I really become an expert in lua coding directly as opposed to using MOOSE.

Would refunding on steam and buying direct be a work around to this? Just a thought. FWIW, I personally prefer to buy direct so 100% off my purchase ends up in the hands of the devs and not a %age going to a middle man anyway, but that’s personal preference. ED do a great job and I try to support them as best I can.

Hi CH, Thanks for the tips. yes - I have a dedicted machine for hosting. My main concern is learning the best techniques in allowing for a large map with many assets without being a burden on netcode and/or client CPU cycles. (As well as the server). I'm using mist and moose, as well as a few other small addons. Moose is very large. I'm aware that some things have more of an impact than others but not sure exactly what they are. I'm trying to avoid trial and error as I've spent weeks setting up a scenario in Moose just to then ditch it because of performance issues which I'm sure is me asking too much of it and/or misusing it as you say (making things too complicated). I don't blame moose - just looking for techniques on what to do and what to avoid at the moment for large scale maps. Re your last point - are you saying it's best to get vehicles to ignore roads and just go offroad for both tracking as well as CPU? Cheers DZ

Hi PravusJSB, Thanks for that. I'd be really keen to hear about what code to use and what code to avoid plus what to set up environmental wise. Interesting re the reboots. That may make hosting more simplistic. At this stage almost all scheduling is done exclusively in Moose.

LOL - Of all the helicopters I would vote for - none are in the poll... OH-58 Kiowa AH-60 Blackhawk or SH-60 Seahawk V-22 Osprey CH-47 AS365 Dauphin Airwolf (Someone bet me to it I see) Obviously this is unrealistic so wouldn't happen, but still... Kiowa I believe would be a great complementary helicopter working with the AH-64 and would make for some great co-op missions as well as multiplayer environments. I'd like to think it's the next helicopter we'll see - but from what I can tell we're 12 months past with little to no information so I don't know if we'll see that before the next helicopter or not, but here's hoping. The Osprey and Chinook would add a whole new experience into the simulator, not just another attack or transport helicopter - but something with a big difference. The Blackhawk is one I've dreamed of for a while. In fact - I'd vote all of what I've mentioned above anything that's listed in the poll first.

UPDATE 14th Oct 2022 I have changed my approach given that there are CPU issues with late activate units. Skip to the following post on my current approach. https://forum.dcs.world/topic/287638-cpu-resource-optimizations-tips-for-large-multiplayer-dynamic-or-persistent-missions/?do=findComment&comment=5064098 _____________________________________________________________________________________________________________________________________ OLD/ORIGINAL POST From 2021 in spoiler:

Quite possibly. Not sure if this is of any help. I know that I can mount and dismount troops from vehicles - it may be possible to implement with trains as well. (Although I imagine with trains, once they're hit - they stop permanently - so such a script may not be required). Re the script above, the way I found out the iniUnitName was by basically having something similar to the following: evh1 = EVENTHANDLER:New() evh1:HandleEvent(EVENTS.Dead) function evh1:OnEventDead(EventData) if EventData.IniTypeName == "Coach a tank yellow" then MESSAGE:New("You have hit "..EventData.IniTypeName ,30):ToAll() end end --OnEventDead / evh1 ... and then I started blowing up each one to get the unit names. (There may be other references to this but I didn't know where to find it, so I did it this 'hack' way). I'd love to see the ability to name individual carriages and refer to each one - but I'm not holding my breath on that one. Good luck with your designing. Glad this was of help!

There doesn't appear to be much - however I have been able to identify if particular carriages are hit by their IniTypeName (using Moose): ie: evh1 = EVENTHANDLER:New() evh1:HandleEvent(EVENTS.Dead) function evh1:OnEventDead(EventData) if EventData.IniTypeName == "Coach a tank yellow" then MESSAGE:New("You have hit a yellow tank carriage!" ,30):ToAll() end if EventData.IniTypeName == "Coach a passenger" then MESSAGE:New("You have killed civilians!" ,30):ToAll() end end --OnEventDead / evh1 Hope this helps.

Hi, Just wondering what is the best way to automate CTLD commands (if any) using either voice attack, or VAICOM. At present I'm going through each menu option and was hoping there's a better way. For instance, on one server if I want to pick up a crate I need to: - Open the menu - F10 - F3 (for CTLD menu) - F7 (for CTLD Commands) - F2 (for collect crate). On another server, the menu's may be slightly different, such as F10- F4-F7-F2. I'd love to just say "Collect Package" and have it pick it up without going through the menu options. But I'm realising that I can't just do a simple command to execute what I'm chasing (because the menu options may be different) and was wondering if either VAICOM has a solution to this, or how other people handle CTLD with either Voice Attack or Vaicom? I'm not sure - it may not even be possible with such dynamic menu's - but I just thought I'd see incase I'm missing anything. The only option I can think of at the moment is to have a different profile for each server/mission I play on.

Thanks for the clarification. I was sure I read somewhere that some people had disabled it using firewalls because when ran it automatically looked for updates each session and would automatically apply if found and had caused some people issues. My memory may not be what it used to be - so thanks for confirming. Good to know that the software (either way) isn't required to use the controls after initial programming. Thanks

To be fair - that will always be. VR requires 2 separate renders - 2D only requires one, so regardless of technology improvements - 2D will always have better performance. If VR gets 500FPS, 2D will probably be 800 or more. I would suggest that instead of comparing one to the other, it's a matter of drawing a line as to what is acceptable and not with VR, otherwise you're destined for disappointment forever if continuing to compare 2D to 3D.

Hole in one. Understood.

Doesn't Winwing have software that you have to run with it - that "phones home" each time you use it too? The Virpil and VKB software I've used just writes to the devices, and then doesn't need to be used again, or even loaded into memory. Have Winwing changed the way they do things to be the same too, or do you still need to run their software to use their products? Virpil HOTAS hasn't let me down one little bit and is solid as. I'd love to see what the Winwing collective is like if it's supposed to be a superior build!

Wags does. I'm sure he'll share it with us with a few YouTube video's in the near future, and then we'll get the actual manual with the chopper when the AH-64D is released for early access. Going by previous releases - I wouldn't expect to have access to the manual prior to the aircraft though. (Happy to be corrected if I'm wrong).

Thanks. I'm suspicious that the slippery Huey problem creates additional problems when being used on a dedicated server as per my tracks above with extra rocking. However according to that thread, this is a known and old problem - so I'm guessing that what I'm seeing will only be fixed when the slippery Huey problem is fixed and won't hold my breath. I guess the other solution will be just to fly the AH64 instead when it comes out and forget the Huey for a while.

OK - I may be onto something with the whole 'dedicated server' bit. I've just ran the attached mission on a dedicated server and it behaves differently to single player. Dedicated server has it rocking around on the deck prior to startup. (I haven't been able to find out the parameters that had it rocking to the extent where the tail was going through the deck yet) - but there's definitely rocking going on with the dedicated server that wasn't with the SP. So it seems while in single player... the Huey 'edges' forward. Same mission in multiplayer and something must be done differently to keep the helicopter in the one spot, yet it doesn't rock - instead it slides forward until it falls off the front of the ship. client-debugmission-20211110-180947.trk server-20211110-180404.trk