Posted - 2011.01.03 20:39:00 - [91]

 

Supported!

Posted - 2011.01.06 02:52:00 - [93]

 

Good god, this is...brilliant

Posted - 2011.01.11 23:12:00 - [95]

 

Posted - 2011.01.14 10:41:00 - [97]

 

*Blink* that might work.....

Posted - 2011.01.14 19:04:00 - [99]

 

Supported

Posted - 2011.01.22 21:04:00 - [101]

 

Bump. Because we like it.

Posted - 2011.01.22 21:39:00 - [103]

 

Originally by: hired goon

---

Though most people would like Lag to completely disappear

---

personal attack!

Posted - 2011.01.23 02:17:00 - [105]

 

I'm not really sure what to think of this one; but hey, it does make a certain amount of sense. I do have a few concerns of course. I'm also not certain; as to the difficulties involved in implementation. Maybe it's simpler than anyone really thinks; or, it may be hard, to nigh impossible, to bring into play.

Here is what I think is good about it:

Instead of each server tick requiring all events to play out in real time; the server runs through multiple ticks, prior to launching all events, for the next cycle. This is similar to old strategy games, in some respects; though, it wouldn't function in the same way, with command windows.

The fraps thing is a cool idea. Slowing down events, while maintaining decent FPS; would make for the potential to get nice video's. Unfortunately, it would also induce client-side lag; while making for huge files, and a significant amount of editing.

And here's some things; I think would help:

1.) Implementation of a Client side click prevention, would have to be implemented; so once a module has been activated, it highlights green, till the next server cycle, or click. Highlighted like this, it will only send the server one additional command; which will prevent some of the requirement, for lag slowdown. The client side would then have to allow for a module deactivation; which will allow for a module shutdown cycle to begin, and would highlight red. So maximum to clicks per module/group; that could send commands to the server. You could denote this, with a second ring; which would be available in all gameplay.

Click the module, and the command is sent, and client informs you; click it again, and shutdown command is sent, and client informs you. Nothing more will occur with that module, until the next tick, or cycle; or until it has finished its full timer cycle, in either case. Once in shutdown, it will not accept any more commands, until it has shutdown; which makes things relatively simple, as far as that goes. That would eliminate the need to click on a module; until it shows some form of activation timer, sent back from the server. Lag is bad that way.

Even if you know; its hard not to try anyway.

2.) Make the slowdown scalable if possible. As ships come into system, and fighting ensues; allow the server to scale the 'Time Dilation' effect as it is needed. 10 minutes, is a long time for a tick. Each tick would occur as normal, without executing events or actions; until the server had run a full cycle of ticks. This would be the time dilation. The server would say, "x number of ticks required, to activate all events without lag; becomes one cycle, for the purpose of handling lag in this system;" and would then proceed to inform players that the system was moving into time dilation. For physics purposes, the server would slow down all physics events, to an appropriate level; and proceed to allow the last cycles events play out, while it takes commands for the next cycle. In this way, Time Dilation could occur as needed, anywhere; and would be based on the number of active pilots in a given system.

3.) As systems become overloaded with pilots, communications could be blocked. Regional markets would become inaccessible, local markets would be shut down, and chat entries would be limited to one text entry per cycle; which would be queued client side, like the module activation indicators. Fleet communications, would be limited to external Voice or text communications. This would occur as a result of system communications bottlenecks; preventing access to regional or constellation data streams, due to datanet bandwidth overloads. Gates into and out of the system; would function based on the full cycle of ticks, as it plays out in system.

It's conceivable that multiple systems could be effected by this; and the effect would spread outwards from the primary system effected. This would be to a lesser degree; and would slow down reinforcements called into system.

Posted - 2011.01.31 00:44:00 - [107]

 

Bumpy road.

Posted - 2011.01.31 02:53:00 - [109]

 

This actually might work.

supported

Posted - 2011.02.13 15:03:00 - [111]

 

Better than what we have now =)

Posted - 2011.02.13 21:27:00 - [113]

 

http://img17.imageshack.us/img17/6380/wellactually.gif

Posted - 2011.02.15 04:36:00 - [115]

 

Morning bump. Wink

Posted - 2011.02.15 15:00:00 - [117]

 

yes

Posted - 2011.02.15 15:56:00 - [119]

 

Supported

But just one thought. There should be a limit on the time dilation. If the server ever gets to the point where its running at 20 or 30 sec gametime versus realtime, then CCP should just let the modulelag/server crash happen.

Overall its a brilliant idea.