KnightHawk75
Posts: 1450
Joined: 11/15/2018
Status: offline
|
I'm gonna repeat things already mentioned but maybe provide more context.
quote:
civilians and neutral military units.
Minimally involved sides
1a. Do civilians\un-allied neutrals need to be able to really see\track\interact with any of the the other sides units? Maybe your neutrals might (if simulating neutrals investigating other sides as contacts), civilians (say just ships or air traffic) often the answer is nope. If the answer is yes..but only a few out of hundred+, and they don't need to be allied, consider moving units that do to another side just for the few. That decision may need to be balanced against some other considerations (ask if really interested) but can be a net positive.
1b. If no - Mark the side Awareness option as Blind. This can be a sizable perf win.
1c. If biologics, 99.9% time put on own side and Blind them (if your being super cute with bios this might not apply).
1d. auto-track civilian\commercial option considerations. If you allow a side to auto-track these units it's effectively setting auto-detect on said units (of this type(actually country-association in db) for all other sides units toward this side only), it can be a perf gain as you're saving some sensor calcs that would be applied for all these units from your side's sensors perspective. There will also be no drawing to the screen to update the detection time counter under the units, and you're saving a little space in the .scen\.saves and memory as the detection tables will not have to have the last 20 odd detection data recorded for each. The downsides of the effect for a scene where ambiguity in traffic is desired I think are obvious. Also no matter where they are you're taking the overhead of the side with it checked knowing about the contacts existing, and they be drawn to the screen unless flagged filtered out.
;nbsp
Airbases - Evaluate your airbases and ports
2. Do they really need all the units you've attached to them. If they are not intended to be attacked, flat out make them SUA's or SUP's. SUP's btw are actually flagged 3005 so they can be attacked regardless, while SUA's are 9001 and short of nukes or very few re-targeting munitions can't be targeted(and even when they can - not individually by component). SUAs not only save you 'units', but setup hassle, they generally also economize components, and static opponent 'contacts'. There are still sub-components linked to the SUA\SUP,but they are not tracked\created as units themselves, which can be a significant savings. If spotting things stored at the airbase (stuff not in hangers) is a big deal for the scene, or aircraft exact placement is 'thing' in the scene it's lost with using this option.
If answer to 2 is I need\want all or nearly all the airbase components to be attacked...
2a. Do I really need everything I added to said base, if yes continue, if no remove said unnecessary unit component(s). Yeah that 180 unit massive airbase group you just created might be neat, and mimic the actual airbase in real life but now when I right click near that thing without group view on...ooof, and the overhead is large. There are absolutely times to do it, scenes to do it in, but it comes with costs.
2b. Do some of the units added to the base have empty mags\mounts that are not going to be filled\used, if so remove them. Example you add 12 ammo dumps, you spread loads out among 4 of them, the rest are effectively decoys or maybe for points. Remove the mags\mounts from decoys - individually this is super minor but it can add up to something collectively (probably not in a 2k scene though), and at scale reduces size of scene files a bit.
2c. For each component piece of the base, does it need\will it be targeting\detecting anything, will it be hosting a sensor or mount itself? If no, then consider setting AI_EvaluateTargets_enabled=false on the unit object, if it may but doesn't need to have a primary target(manual control only), consider setting AI_EvaluateTargets_enabled=false, often you will set both, an example would be the ammo dumps mentioned in 2b, others would be hangers,raps,runways,tower,fuel tanks,etc unless your modding them to host sensors, fire weapons, etc, they can all get the AI_ modification treatment.
2d. If you need an opponent to have the ability to 'disable' a base with conventional munitions, but you still want some savings from using a SUA, you can create a hybrid-SUA where the opponent can disable it's runways and\or raps. You do this by placing the SUA, but upfront going into DamageControl menu and setting 'Destroyed' on the runways and/or raps. Then you add just runways/raps close by and group the new units with the SUA. Poof, you have yourself an airbase that will use the added units, not use it's include 'destroyed' components but the external ones, and when the separate units are later heavily damaged (runways\raps can't be destroyed) to 99%, the airbase can't launch aircraft anymore.
2e. If 2d doesn't work for you, or you're not ending up with lots of savings for unique reasons, you can always have something else (whatever criteria you want generally) trigger a script that disables or heavily damages the runways or rap sub-components of a SUA.
Units - Everything adds up
3a. Civilian unit evaluation airports\ports see 2.
3b. Assuming a Civilian\Neutral side isn't blind. Do the units by default have sensors on them? Are they all needed? If not remove them even if not ever going 'active'. Example civilian airport that needs for whatever reason to have tower, ok but does it need the doppler radar attached? Do your civilian/neutral aircraft/boats need their radars? (consider stripping them if never going to be used, it's just one more thing that has to get stored,recreated on load, an hold another couple hundred bytes of ram).
3c. Extra sensors,comms - That 3c bunker you placed on side X, are the comm links on it used for that side, or is it just serving as a target, if just a dumb target (even if part of a trigger), script remove the comms. Yeah I getting petty here for typical 2k scene 3x ain't gonna matter that much but a 15k the petty stuff can add up. :)
3d. Radar or sam units with less than 360arc.. instead of 3-4 units does it matter to the scene if I simulate 4 with just 1-2 units each with bigger arcs and more weapons\comms\sensors? Can I just put that additional radar I want on an existing unit that is already in the spot I want (careful height\mast of a unit has effects, as does units ooda times)? Ex: can I just slap that big-bird d onto that s-400 since it was gonna be in the same area anyway? Often it will matter, but sometimes it doesn't or not significantly, particularly for units on sides that aren't major players\targets in the scene.
3e. Same thing when it comes to decoys. ex: sam decoy- ok so you may the radars...but you don't need the mounts and mags right?
3f. Instead of creating 8 of this unit due to total firepower desired, can I just put 4 of them each with twice the weapons,sensors,comms,etc without affecting difficulty of the scene? Does it radically change how things playout, does it kill realism too much? What's the effect on damage accounting\difficulty in killing the uber units? Often it matters, but sometimes it doesn't - or just changes the opponents needed approach, can be good or bad. Just something to consider. Example: some ssm unit with 1 silo\launcher, you have 12 of them in basically one place, if the unit isn't meant to be 'found' or attacked and you place only 3 of them each with a rof-1 or 2 rated mount with 4 original weapons attached what's the difference to overall scene?
4. Sats -
4a. Do yourself a favor and unless you need to simulate real'ish coverage gaps, don't add 150+ sats to a scene.
4b. ASAT is basically broken and has been for awhile so no point providing them as 'targets' atm, unless scripting destruction.
4c. Use the new feature to 'dock\park' a couple sats in the area of your scene for the coverage you want to simulate. This is a fantastic new feature that lets you put sats where you want, at the altitude you want, without having to understand and generate the right TLE's like in the past. This lets you create effectively geo-sync'd sat coverage if you want. If you then want to simulate gaps, do that by scripting their comms-off, or scripting destroying\repairing their sensors for periods of time, or (and I've not tried this yet with new feature enabled), script the movement of them yourself away from the area periodically and back. Honestly anything along these lines is better imho then just adding hundreds of sats to a side most of the time vs overhead involved.
4d. If using 4c or variant, consider just putting all needed sensors you want on just 2-3 sats for each side for a scene, unless again you have some specific need to simulate otherwise or large number.
5 - Events and Lua - too long to list but here are just a couple.
5a. Regularly timed(recurring) events - Do I have significant amounts of code running at less than 1 minute intervals?
5b. If yes, how long does each take in ms to run? Do I have code running every second or every 5? If yes, have I optimized?
5c. Lua optimizing: Am I running loops through more data then needed? Ex: for each in side.units vs using side:unitsBy('subset'), or side:unitsInArea (these were added to make life easier and reduce processing waste, use them). Where taking time hits am I using for pairs() where ipairs() is available or where i,#tblcount will be faster? Am I calling get-XXX multiple times on the same object in the same run? If so is there a reason I can't reuse the resulting wrapper\data from the first call? If I'm regenerating data or needing data on every pass, can I trade memory (storing stuff in global tables) for speed and only get\update\regenerate the bare minimum per pass. If doing large amount of processing every second or 5 but 2,3 or 10 will do and 5 or 15 is not quick enough... then implement that. If doing lots of stuff on one time-boundry, can I split some stuff off to another or arrange it to be off-boundry?
Other perf things as player:
minimize the layers.
Map-Settings in highly active scenes - disable what you don't need (or don't need for awhile), set selected unit-only settings for things you don't need to waste resources drawing, merge-ranges when possible. Units launching 100's of cruise missiles, move your view so they are off screen till done if you can, disable sound during those too.
|
Printable Version
Scenario optimization - 
My own general rule of thumb is > 3k is going to run on the slower side on an avg box (even newer-ish ones on the medium or low end), particularly when you consider that figure at the 'start' of the scenario usually, and doesn't account for 100 or 300 missiles that could be in the air in addition. 2800 units existing in the scene probably isn't your sole problem, but 1800 of them actively busy doing stuff navigating, detecting, emitting, launching...could be. Also check (and it's almost impossible with so many units) but see if any of them are stuck in some kind of navigation loop, keep an eye on the message log for excessive repeated msgs, while at it clear that msglog if/when you get to a couple thousand in there. 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread