Topic: Bonk RM's warts and all

[Dizzy]

(I couldnt email this... my email doesnt work, surprised this does... so here ya go)

PLEASE Explain your reluctance to adjust time in the gf settings to Braxton/Hexx
and Julin/Krueg/tool. I know SQL is different than flatfile and there
are a few risks associated with it, but Im not well inform (Dunno if you remember, but
DH and the previous gang used to run the clock faster after a reboot to
clear/populate the yards. Then set the time back with no issues).

We cannot go thru so much of the late erra. Ending past 2287 is a no no. Certainly a 2294!
So something needs to be done soon. I do not know what kinda backlash this will
have, but it will be far less backlash than allowing the server to continue
with such a long run thru the Xtech era... I dunno if they'd want to keep
the hexes they've already taken or what... But we need to alter time like I
said in the last email or reset in the early and readjust time so we end on
86 and it needs to be done ASAP! So the sooner we get an answer from one
both sides... the sooner the better.

Im having MAJOR connection iissues. My cable modem isnt syncing up. I
called tech and they think its my modem. I may have no or little access thru
monday. I f*cking hope we dont lose a lot of players over this, most are understanding tho,
but oh well, its better than spending half the server in the Xtech era.

PLEASE talk to the RM's and work this out for me... I'm going to church and
will call Time warner again to try and at least get on TS. But may not be
able to. Im sorry if I misunderstood you, or gave u wrong info for when we started
... I dont remember talking to u about a mid start, but i was so strung out and tired
from all the damned work I was doing to get it to launch in time, it sounds like it could
easily have happned. I just thought u never changed  it from testing! haha. my bad.


Diz

[FPF-SCM_TraceyG_XC]

Using SQL, you cant run the server too fast, it wont keep up will produce errors. Running the server slower though will also increase the time between shipyard cycles. In extreme cases where the shipyard is not cycled adequately, the server can actually run out of ships (and is most likely to crash), not to mention the wait for new ships to come in (although with the web shipyard, this is less of an issue).

[Hexx]

Uhmm maybe SQ but
can't we just add more turns to a year?

If the turns are 5 minutes each now, and say thre's 100 in a year, can't we just make it so they
stay at 5minutes, but put 160 or so in a year?

[FPF-SCM_TraceyG_XC]

That would work, yep. Cant remember if we cange the number of turns per year after the server has started though.

[Bonk]

I will do what I can. Server coming down for edits shortly.

[Bonk]

This is the CurrentTime blob now:

EC0E0000180000006D010000FC6A0500D7080000000000000A0000001400000028000000

I need to find where the old miilliseconds per turn is in it (was 355068) and change it to 710136.


Moral of the story here: do not push admins to start a server before it is anywhere near ready. Also do not try to admin a dyna server over dial-up, lol.

[Bonk]

Found it: FC 6A 05 00 as longint: 355068

[FPF-SCM_TraceyG_XC]

The new blob should like

EC0E0000180000006D010000F8D50A00D7080000000000000A0000001400000028000000

[Bonk]

Thanks Tracey! I just got it though, but your help is sincerely appreciated. 

crap, I just had to reboot the webserver too, somone musta been on the webmap when I took it offline...

anyway, edits done. (F8 D5 0A 00 as longint: 710136)

when the server goes back up it will be 2273.172 - 365 turns per year still, 11.8 minute turns, shipyards, webyards and economy cycling every turn again.


Server back up.

[Dizzy]

Damn u guys are smart!

[Braxton_RIP]

This is just out of curiosity, since I have used SQL for a long time (pretty much since it came out) put never in this sort of application.  When the flat file server was down, I remember you could edit it to add PP to accounts and what not, and the server didn't react to it unless you really screwed up.  Since the server you made, Bonk, is, from what I hear based on the flat file server, wouldn't it be possible to export all of the player data from a server when it is down (since the database is going to remain editable) and archive it?  On a project I worked on recently which had about 3 million lines of code, we used a base SQL db and could transfer parts of the bd to other areas with two simple statements.  I am just thinking, that should something like this happen again, you might be able to export map and player data, shut the server down and reset it, and then import the data back into the db again.

Don't know if you can do this, but one SGV is over, I could spend some time with you to figure it out if you like.

[Bonk]

This is just out of curiosity, since I have used SQL for a long time (pretty much since it came out) put never in this sort of application.  When the flat file server was down, I remember you could edit it to add PP to accounts and what not, and the server didn't react to it unless you really screwed up.  Since the server you made, Bonk, is, from what I hear based on the flat file server, wouldn't it be possible to export all of the player data from a server when it is down (since the database is going to remain editable) and archive it?  On a project I worked on recently which had about 3 million lines of code, we used a base SQL db and could transfer parts of the bd to other areas with two simple statements.  I am just thinking, that should something like this happen again, you might be able to export map and player data, shut the server down and reset it, and then import the data back into the db again.

Don't know if you can do this, but one SGV is over, I could spend some time with you to figure it out if you like.

I can dump the sql db at any time to back it up, even while the server is live.

I did not write the serverkit, Taldren did. Magnumman added in the MS ADO hooks to run it on SQL. The core db engine is still geared for the flatfile.

I had to take the server down to make this edit because the server reads certan variables from the db into memory and others from the gf files on startup. The millisecondsperturn setting is one that cannot be edited on the live server. It is read from the db into memory on startup when running on SQL, when running on the flatfile it reads it from the gf file on startup.

I can edit a characters prestige on the live server without stopping it, no need to shutdown or convert it to a flatfile db (the character concerned need only hit "done" in suppy to refresh his client). I can make a number of edits on the live server, including, but not limited to hex DVs, hex ownerships... certain things are more difficult to edit, such as the politicaltensionsmatrix blob, for which the current values make no sense, but the initial values are easily read.

Hope that clarifies things somewhat. (that's part of the whole point of SQL, being able to make live edits on the server db)

But hey, if you want to help out with working with the SQL kit afterwards, all the fresh input we can get is welcome. "Many hands make light work".