Jump to content

Dangerzone

Members
  • Posts

    452
  • Joined

  • Last visited

Everything posted by Dangerzone

  1. 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.
  2. 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?
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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!
  12. 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.
  13. 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.
  14. 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
  15. 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.
  16. 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!
  17. 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).
  18. 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.
  19. 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
  20. Thanks for trying Tanuki44... I've just tried myself - and haven't got a problem with the rocking yet running single player, but I have got a problem with the helicopter moving forward until it falls off the front of the ship. All I did was start it up (although the helicopter started moving before then)... Track file attacked. DebugTrack.trk What I'm wondering is whether or not this may have to do with the creeping forward in the track file - but it's escalated with lag / syncing when on a remote server. I don't have a remote server to try this test mission out on at the moment but will see what I can come up with.
  21. Thanks Flappie. It was the Tarawa - but don't go to any effort - I'll see if I can replicate it when I have some time on a single mission with no scripting that I can shoot through.
  22. OK - seemed as though it was easier to do than I realised... Just change the line in the CheckMovement() function to the following: From: if v.x == 0 and v.y == 0 and v.z == 0 then --Check if speed is zero To: if v.x == 0 and v.y == 0 and v.z == 0 and u:isActive() then --Check if speed is zero (So just adding an "and u:isActive()" check in there) seemed to do the job. Disclaimer - I'm a hack at lua, not proficient. YMMV... test well.
  23. Both in VR and not in VR. (My friend was having the same problem at the same time). No track - as this was on a server with server side scripts. Before investigating any further I just wanted to see if this was a known issue, or whether it's isolated to us or the server that we're on.
  24. It appears as though it detects it as not moving, and dismounts the units in the non-activated units location. I'm not great at lua, but trying to find if I can get a solution for this at the moment... Will let you know if I'm successful.
×
×
  • Create New...