Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Dangerzone

  1. I'm not sure if this is of any help - but IRL when trimming I was taught never to chase the trim. What I mean by this is if the aircraft is going down, don't trim up to make it level (or vise versa). Instead, we're taught to hold the aircraft in level flight with the yoke. Once the aircraft is flying level - then we start trimming until the yoke is no longer pressing against our hands - that's when the aircraft is trimmed right. Chasing the trim means forever going up and down and we won't nail it. The latter approach means the aircraft is level before you're trimmed out correctly and remains that way right through to the trim. I find myself using the same technique in DCS. I hold the joystick where it keeps the aircraft level, I'll then apply a bit of trim and as I do so - I release a bit of pressure from the joystick to keep the plane in level flight. I keep doing so until the joystick is centered. TBH - I have no idea whether or not this makes it better in DCS - just that it's what I've carried over from real life - and it seems to work for me. Might be worth a try?
  2. +1. Not only can we only do this with scripts at the moment, but IIRC these scripts require desanitisation of MissionScripting.lua file too - which is really ideal - and limits the applications.
  3. Their FAQ in their discord says "when it's ready". I don't think many devs are game to give a date due to backlash if they don't make it, so are opting just to work at their own pace (which may be dynamic depending on personal circumstances - as it is a hobby), and when they're ready to release, they will. Takes the pressure off and makes it more enjoyable to work on too I would imagine. I understand the curiosity though - I too am hanging out to have a go at this, and would love to know if it's 'close' or 'some time off' yet... but respect their decision to remain silent.
  4. Thanks Newy - however theme option doesn't show up for me. Signatures aren't showing up either. (I'm running dark theme).
  5. I can't see it being easy to actually have the buttons synced with DCS as it is now. I think that would take even more technology and cost - and the simpit would need to be perfect, along with reference markers that would communicate with the headset so it auto-aligns itself. The better way I can see this happening is to have an augmented reality headset. Something where you have the simpit, and then a green backdrop for everythough outside of the aircraft, and where the VR display has camera's on the outside that 'passes through' video footage of the simpit, and wherever it is green it would render in external view. In order for this to work though I imagine you would need: 1) A headset that supports such features 2) DCS to have an option where it allows for rendering of external graphics only, and 3) Software that would take DCS's external graphics and 'paint' it onto the green screen parts. There may be other ways as well - but from what I can tell - at the moment we're a fair distance away from having something available on consumer market. Wouldn't surprise me though if such setups were already available commercially. I dream of such things, but in reality - just VR alone at the moment is darn incredible. yes - it's a pitty we have to choose between either simpits or VR - but I'm amazed at what we already have. My next wish is for VR graphics to be as good as 2D graphics, and for us to be able to record high quality content in VR easily.
  6. Sorry to tell you guys, but this has been asked and answered already, and you're probably not going to like it: That was ~15 months ago, so unless anything has changed - it seems as though DCS VC will be a closed feature. For me, that means DCS VC will be unused. We have too much relying on externals (Overlordbot, LotATC, and external text2voice in scripting, etc) as well as additional things such as radio stations for a more immersive experience, so it's going to be SRS all the way for me. Hopefully ED have reconsidered and I've missed it - but I haven't come across anything since that would say otherwise. I'm disappointed by this - but the good news at least is this part: .... so long live SRS!
  7. I thought it was all missiles, but could be wrong. If not - it could be tweaked. CFRAG has shown how it can be done above. The only difference is that the script I saw allowed the missile to get close first to allow practicing of evasive maneuvers and notching. For me - I'd use invincible. You know if you've been hit so it's better for practicing - but if the idea is to create a 'top gun' training center sort of experience with simulated weapons instead - then that may not be the best approach.
  8. Hanging out for it myself. Expecting to see AH64 of course, and dynamic weather. Very keen to see what may be hinted at though in the video though - beyond what we already know is in development...
  9. Two potential ways you could do this: 1) Use the immortal option 2) Use a script (can't remember where it is though) that will detonate missiles just before they hit aircraft. This won't work for bullets however, so if you're wanting to include guns and not just missiles, then #1 may be the better option.
  10. 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.
  11. 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.
  12. 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.
  13. +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:
  14. 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.
  15. 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.
  16. 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?
  17. 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?
  18. 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.
  19. 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.
  20. 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.
  21. 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
  22. 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.
  23. 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.
  24. Hi, I've been working on a large (full map) style multiplayer semi-dynamic mission that may run for days (or weeks), and one of the problems I have identified is running into CPU issues and managing performance in a way that isn't over taxing with the mission editor. I'm trying to work through it at the moment, and I'm working on the following - but I'd be very keen to know if anyone has any additional tips or tricks that they use in order to allow for a large scale mission to operate without hitting CPU issues. (I am pretty green with both DCS mission editing, and LUA - so I'm not sure whether there are better ways of achieving this or not). The main thing I am working on at the moment is using Late Activation & Uncontrolled in the mission editor, and then setup many zones on my mission, and many units. I figure if they're not activated - then they shouldn't be using CPU resources? I then create tables of the zones and units, and then have a generic scheduled function that runs that does checks to see if the units need to be activated. I use this approach instead of the mission editor as it makes it more efficient to add new units and zones later without having to do a lot of triggers, all I need to do is add them to the table. Here is an example of the table and function I'm planning on using. (I hope I haven't reinvented the wheel here - but open if there is a better way to achieve this!) activationunits = { -- begin zone section {zonename = 'zone1', activated = false, zonedesc = 'yeah, whatever', activationtype = 'bluforall', groupinfo = { {groupname = 'TestGroup1', intel = false}, {groupname = 'TestGroup2', intel = false}, } --group info }, --zonename -- end zone section {zonename = 'zone2', activated = false, zonedesc = 'somewhere', activationtype = 'bluforair', groupinfo = { {groupname = 'SAMGroup1', intel = true, inteldesc = 'SAM Alert!'}, {groupname = 'TestVehicle2-1', intel = false}, } --group info }, --zonename -- ... etc } -- activationunits zonesched = SCHEDULER:New(nil, function() for i = 1 , #activationunits do activateflag = false if activationunits[i].activated ~= true then if activationunits[i].activationtype == 'bluforair' then if bluforair:AnyInZone(ZONE:FindByName(activationunits[i].zonename)) then --blufor declared in InitFlags activateflag = true end else -- if activationunits[i].activationtype == 'bluforall' then if bluforall:AnyInZone(ZONE:FindByName(activationunits[i].zonename)) then --blufor declared in InitFlags activateflag = true end end if activateflag == true then k = 1 thisactivationgroupinfo = activationunits[i].groupinfo for j = 1 , #thisactivationgroupinfo do myactivategroup = GROUP:FindByName(activationunits[i].groupinfo[j].groupname) if myactivategroup ~= nil then if activationunits[i].groupinfo[j].startuncontrolled == true then myactivategroup:StartUncontrolled(k) else myactivategroup:Activate(k) end k = k + 1 if activationunits[i].groupinfo[j].intel == true then MESSAGE:New('Enemy Activity located near '..activationunits[i].zonedesc, 10):ToAll() end --intel end --myactivegroup not nil end --for j activationunits[i].activated = true -- Does not work :-( end -- if activateflag end -- Not activated end end, {}, 1, 15) --zonetrigger Scheduler A better solution maybe (although I'm not sure if it would create it's own problems) is to scan through each group and check for any activity within xxx distance from that unit and activate or deactivate accordingly. This would eliminate the need for zones, and less maintenance with mission designing - but I'm not sure whether or not that is practical. Very keen to hear if someone has done something else better than the above. Another option I'm toying with is dynamically spawning random units within zones but I haven't yet perfected script for that yet. I know dynamic spawning with Moose is easy - that's not the issue. Figuring out how to decide what units in what general areas that would be practical for the mission is what I'm working through. Another small thing I'm doing is making sure wake turbulence is OFF. I believe (from reading on threads here) -that can have an impact with performance. Lastly - I'm looking at using script to save the mission so the server can be reset every 24hrs. It seems that if I leave a mission running for days on end - that performance can end up being an issue, so it's my current understanding that restarting the server helps with CPU and resource management. I'm not sure if anyone has any additional tips over these that they use that they're willing to share - or if you have any better solutions to the above thoughts that I'm looking at using, but I'd be keen to hear.
  • Create New...