+- Discovery Gaming Community (https://discoverygc.com/forums)
+-- Forum: Discovery General (https://discoverygc.com/forums/forumdisplay.php?fid=3)
+--- Forum: Discovery RP 24/7 General Discussions (https://discoverygc.com/forums/forumdisplay.php?fid=23)
+--- Thread: Dear devs and admins: (/showthread.php?tid=84350)
Dear devs and admins: - AeternusDoleo - 07-26-2012
' Wrote:Both model (not hitbox) and number of projectiles cause lags.LOD levels will not fix server lag. They make clientside rendering of a model easier on the videocard but do nothing serverside. Given most people have computers with hardware specs FAR exceeding the recommended specs for Freelancer, LODs are nice to have but not really a requirement at this time. That can wait till 4.87.
As for the models - they need numerous of LODs which will appear at different distances. Though making a LOD is quite a pain, I suppose it could help in case when ships are many klicks away.
Dear devs and admins: - Swallow - 07-26-2012
' Wrote:LOD levels will not fix server lag. They make clientside rendering of a model easier on the videocard but do nothing serverside. Given most people have computers with hardware specs FAR exceeding the recommended specs for Freelancer, LODs are nice to have but not really a requirement at this time. That can wait till 4.87.
I suppose.
But as I was told - for 4.87 ships LODs are must to be done. And as far as I know that was your words.
I've made my model with LOD1 for further submission, it has 6 times less polys and in range of 1-2 k there is no visible difference.
Or you are giving it up and 4.87 will be getting LODless models?
I, myself, with both hands up for LODs, because of my netbook's weak CPU.
Dear devs and admins: - AeternusDoleo - 07-26-2012
Not mine - Cannon wanted that implemented. Resolving texture conflicts, naming conflicts inside models and the likes I consider more pressing then multiple levels of detail. But all of these things take time. And it would benefit the module to have large models get multiple levels of detail. Gives it a more finished feel.
Dear devs and admins: - Swallow - 07-26-2012
' Wrote:Not mine - Cannon wanted that implemented. Resolving texture conflicts, naming conflicts inside models and the likes I consider more pressing then multiple levels of detail. But all of these things take time. And it would benefit the module to have large models get multiple levels of detail. Gives it a more finished feel.
Thank you for the information...
Dear devs and admins: - Corsair - 07-27-2012
EVE's system of base sieges run in stages- Once a base gets to 75%, 50% and 25% it goes into 'reinforcement' mode where it's invulnerable for a day. Adding such a functionality to Discovery would force sieges to be drawn out over days in shorter bursts, making each lag spike shorter and less intense.
It could be implemented by having the base consume a 'reinforcement battery' at the aforementioned stages, otherwise it would enter forced reinforcement which renders the base invulnerable for the next few hours / up to a day. During this time, the shield does not regenerate and fuel cannot be transferred. When the reinforce timer ends, the base is vulnerable.
These reinforcement batteries would force the base into an invulnerable state but allow for passive shield regen. These batteries would be stupidly expensive, however.
Or just do away with the battery gimmick but stick with the reinforcement method; at 75%, 50%, 25% shield strength the base shuts down for a day. When hull reaches 25%, emergency repairs commence and the base once again shuts down, coming out at 50%. The base can then be blitzed down to destruction.
This would break up sieges and make the problem less prevalent.
Dear devs and admins: - Blackvertigo1 - 07-27-2012
Player bases are not invulnerable, they can be deleted at any time by an Admin.
Dear devs and admins: - AshHill07 - 07-27-2012
' Wrote:EVE's system of base sieges run in stages- Once a base gets to 75%, 50% and 25% it goes into 'reinforcement' mode where it's invulnerable for a day. Adding such a functionality to Discovery would force sieges to be drawn out over days in shorter bursts, making each lag spike shorter and less intense.
It could be implemented by having the base consume a 'reinforcement battery' at the aforementioned stages, otherwise it would enter forced reinforcement which renders the base invulnerable for the next few hours / up to a day. During this time, the shield does not regenerate and fuel cannot be transferred. When the reinforce timer ends, the base is vulnerable.
These reinforcement batteries would force the base into an invulnerable state but allow for passive shield regen. These batteries would be stupidly expensive, however.
Or just do away with the battery gimmick but stick with the reinforcement method; at 75%, 50%, 25% shield strength the base shuts down for a day. When hull reaches 25%, emergency repairs commence and the base once again shuts down, coming out at 50%. The base can then be blitzed down to destruction.
This would break up sieges and make the problem less prevalent.
The issue with that would be that you could have factions hit the base very early in the morning or just on a different time zone to the base owners, if your locking down the base for a day and the attackers can continue to hit the base the next day but because of the time zones the owners couldn't do anything. I know for those of us without real life matters to deal with can easily get up at 4am just to do a bit of base seiging. Those of us who can't are screwed.
Theres a lot of factors you need to account for. If for a specific moment the bases hull level drops under 75% despite the fact that it just so happens it was a very heavy co-ordinated first hit. Does the base still lock down? Because acording to what you say it would.
What of repairs and fuels? are they just being ignored by this?
Plus thats not to mention that it doesn't really solve the problem ... well I guess it would partly, I mean the defenders arn't going to show up because, hell, whats the point if you know for a fact the base can't get killed this round? But also it doesn't solve the fact that you still need a rather large capital fleet in order to do ANY damage at all. With your 75% idea the siege is still going to take the same amount of capitals, and still take several hours to get a base down to that level. That siege in Meggelan with the LN and BAF took a good few hours, killed the server twice, 90% hull left.
To be honest, I still think the only way we can solve this problem is to find a way to increase the servers stability to account for these sieges. I'm assumeing when the devs ran the numbers to see how many ships are needed to kill these things they accounted for fleets this size, and I've seen fleets this size fighting fleets of equal size in the past and the server just seemed to shrug it off. Something has changed since 4.85 that seems to have crippled the servers ability to copewith it, its just a case of finding out which of the new features it is and trying to cool it down a bit. (My moneys on the bases.)
Dear devs and admins: - Ursus - 07-27-2012
' Wrote:we do have brainstormed about various ideas to track the real problem(s) and solve them as good as we can though without taking too much away from how we are used to the game.one thing you can try, is generating fake network messages that test certain elements of the server. For example, generate 10-100-1000 projectiles that dont hit anything, then generate 10-100-1000 that hit a simple cube, then 10-100-1000 that hit a base, all the way up to complex objects
Dear devs and admins: - AeternusDoleo - 07-27-2012
Yea, Ursus, we tried that, no such luck. These issues only arise when you have 150+ players on the server. Doing that on a testing environment won't really work. Although we -could- replace the Legate and Jorga hitboxes with a flat cube roughly matching it's geometry and see what happens I suppose... testing in a live environment.
Dear devs and admins: - Blackvertigo1 - 07-27-2012
' Wrote:one thing you can try, is generating fake network messages that test certain elements of the server. For example, generate 10-100-1000 projectiles that dont hit anything, then generate 10-100-1000 that hit a simple cube, then 10-100-1000 that hit a base, all the way up to complex objects
"...is like tryin to hit a bullet with a smaller bullet while wearing a blindfold riding a horse."
However, I do hate horses.