Can I somehow DISABLE the animation of a wind generator? I found out that if someone builds a windgen farm it literally EATS and MELTS my CPU down. It would be really convenient to have it working without animations.
+0 / -0
|
Animations are not run locally. There is no reason that the animation would 'melt' your CPU though, it's way less complex than most animations, unless it has an error in the script. Possibly this is a result of overdrive grid updating becoming too complex? Or maybe it's a coincidence, how many games has this happened to you?
+0 / -0
|
Well I'm having this problem in most games. It only SEEMs like the windgens are making me lag. I'm almost pretty sure now. If there's a windgen farm somewhere in the map my CPU usage rises dramaticaly. I know my CPU is reaaally old (7years), it's an AMD athlon x2 4800, overclocked to 2600MHz per core... The game is starting to be unplayable for me atm.
+0 / -0
|
Windgens do lag but rotation wont make them lag less I fear. Its the model complexity and the overdrive grid calculations..
+0 / -0
|
quote:
Its the model complexity |
Doesn't spherebot have like 2000 poly? It can be spammed just fine, and models get replaced by icons if you zoom out anyway.
+0 / -0
|
try update drivers. i had huge lag whe trees was on the map. then shit happened to my pc, so i needed to reinstall windows. Now trees dont do lag for me
+0 / -0
|
Would it be worth it to disable ed models and play with icons only? How is it done? (i think ddab did it before) How can you tell the facing of a unit in this mode? (needed for microing big slow units and correct possitioning of such units) Since all windgens produce the same amount of e would it be possible for them to be considered one single "object" per team by the overdrive algorithms? If we get rid of the elevation bonus the 'object" could have an output of [base vind factor (variable)]x [number of modules built]... or something along those lines... of merging many small things into a big one... hopefully without making a small problem bigger...i should probably stop now and go find neonstorm...
+0 / -0
|
go into springsettings.cfg 10 lines from the bottom there is UnitIconDist = ... UnitLodDist = ... do: UnitIconDist = 1 UnitLodDist = 1
+0 / -0
|
Spherebot has 1000 polys, it's not the model complexity. It would only be OD grid calculations, or some script error.
+0 / -0
|
You can't consider all widgens as one even if you disable height bonus because they can be parts of separate grids. The calculation for grids isn't that heavy anyway, all you do is check grid coherence on creation/destruction and do total_grid_E += output per update which isn't that expensive anyway.
+0 / -0
|
The winds are not what costs cpu for overdrive. The grid is calculated only once during the process (and the e values are stored per grid, so after that the winds aren't even looked at). The time consuming part is distributing the e, which grows with the amount of mexes and grids.
+0 / -0
|
The time consuming part of wind generators is probably some incompatibility between your computer and spinning animations. The only stupid part of the overdrive gadget occurs on pylon destruction.
+0 / -0
|
Vehicles use 4-8 spinning parts per unit, BTW. They're even variable, like wind. You're probably just having an issue with big games in general, and big games tend to have windgen farms, so it's probably correlated but non-causative. Unless you can offer any more info.
+0 / -0
|
I always thought all grids are reconstructed from scratch every time a single eco building is destroyed. Is that wrong?
+0 / -0
|
That is incorrect. Only the grid which the building was attached to is reconstructed from scratch.
+0 / -0
|
Oh so that's only true when players connect all their grids. Well, since nubs don't know how to windgenfarm and pros know they need to connect grids, chances are high that when there's a windgenfarm there's a very big grid too.
+0 / -0
|
HEY, did you guys know that shield bot is also using somekind of a "grid" too. Its the "Shield-Link". Each second it loop thru every Shield unit to check which unit is connected and which is not, if this doesn't happen as often then how could it know whether unit walked out of (grid) range or not? -It always do this grid 're-detection' every second to make it work the way it is and I don't think it cause any lag... So, I think the grid algorithm (in OD) is not expensive in itself, maybe the fault is in the timing when the grid recalculate... maybe it recalculate in 'burst' instead of 'periodic'? or maybe its not as efficient as Shield-Link? (but I doubt it use different algorithm. I think both use same algorithm) Its hard to believe that Shield bots can recalculate grid every second without issues and (we suspect) OD grid cannot?? its just strange...
+0 / -0
|
If you have the same amount of shields linked as windmills in a windfarm + other grid stuff, it lags, too. And just because something is distributed in a network doesn't mean it's done the same way everywhere. Ford Fulkerson is pretty different from Traveling salesman. "but I doubt it use different algorithm" What kind of algorithm do you suspect OD and shields to use?
+0 / -0
|
quote:
"but I doubt it use different algorithm" What kind of algorithm do you suspect OD and shields to use? |
It is a cluster detection algorithm. It detect which unit (is close to) which group and group them together. (It is a way to make computerz understand that certain points or units are in a "group" just like humanz do intuitively, and this same algorithm is the same everywhere even in this solar system except maybe some tiny tweak there and there) http://en.wikipedia.org/wiki/File:Cluster-2.svg
+0 / -0
|
Cluster detection is very broad. You could just as well say it groups units. It's not even the right direction though, in cluster detection, you don't have fixed ranges on the individual points. However, building the grid/shieldball is only the first step. For shields you have drain/charge rates. If i understand the shield system correctly, you can, for each edge in the network of shields, instantly determine the flow of shield charge. After that it's just adding all the edge flows to the node values. This takes only as many steps as you have shield links (of which there can be a lot, though). For OD, you have to calculate e distribution. This may take a while, since the algorithm has to take into consideration all grids at once in order to optimally distribute the e for OD. It's been a while since i looked at that code though, and it's pretty late here, too.
+0 / -0
|
