Topic: A new feature for future campaigns

[Losiack]

I'm about to join Litterbox 3 and I don't know yet which side let alone which race to play. One cool addition to future campaigns could be a status board on the number of players on each side as well as on each race. The only players counted could be the ones with a lifetime prestige above a set number (say 10K).

This would give players who like to help the underdogs to make up their mind

SPQR Losiack
Correspondant for the Internal Romulan Information Service
The IRIS sees all

[KOTH-Steel Claw]

The Roms are absent. Or at least, htat is what I have heard. Hard to tell since they don't really exist.

[**DONOTDELETE**]

Check the "Roster" link on my website ...
(better yet- check the test scripts below - they're updated...)

If all goes well, this will be in place for the ISC Invasion
campaign in a portable form at the "SQL Web Map" link
on the ISC Invasion - Home Page.
(only up when testing...)

I am testing additional features as I add them here:
"The Wheel 2 Go" test scripts

The Wheel D2 server has been running on an SQL db for four months
now... Since FireSoul and I have worked out a seemingly stable chat
solution I can really start to observe the stabilty of the SQL server.
(I was not using peerchat.gamespy.com because of it's "yo-yo" behaviour,
but a local chat server (bircd) that DarkElf later determined to be the cause
of disconnects from the D2 server...)
I also recently determined a working scheme to clean the SQL db which I can
now automate! (hopefully a full set of admin pages too...)

I have done all of this on one old underpowered computer (well below spec...)
All of the servers running (Apache httpd, Unreal ircd, RWBS 0.27, TightVNC, MySQL...)
are no problem on CPU usage except the D2 server (SQL or flatfile) or atrocious php code.
For example; a tight php script executing a considerably larger SQL query than the
D2 server should in mission-matching produces about 1/10th the CPU usage.
So whether it is the way the D2 server queries the db or everything else it
is doing - it is the D2 server that is producing the large CPU load.

I noticed in writing php scripts that call the SQL db, that they may work fine
in initial testing (small db) but fail miserably later on a larger db. I edited some
scripts like this and found that a well placed, WHERE, AND and ORDER BY
clause on larger queries dramatically improved performance.
(Does the D2 server executeable need some similar scrutiny?...)

When I seperate the queries from the processing code in my scripts
it is clearly not the SQL db queries causing high processor load, but
any particularly busy (or sloppy) code that follows.

We have also learned that the My.ini or My.cnf file for the MySQL server
must be edited appropriately and the appropriate binary be selected
for the server.

Anyway, I'm rambling here...

My point in short - "Real Time Roster" = Done!  (contingent on successful D2 SQL server)  

[mbday]

rajnsaj
 Great job. Keep up the good. Work.
Also I would like to talk to you about the PHP and MySQL settings.  

[Gumby]

Quote:
I'm about to join Litterbox 3 and I don't know yet which side let alone which race to play. One cool addition to future campaigns could be a status board on the number of players on each side as well as on each race. The only players counted could be the ones with a lifetime prestige above a set number (say 10K).

This would give players who like to help the underdogs to make up their mind

SPQR Losiack
Correspondant for the Internal Romulan Information Service
The IRIS sees all  

 gonna have to agree on this one.  This round i decided to play Hydran instead of my usual Rom, cause i thought they could use some 'help?' and for a change of pace.  If i had known ahead, i woulda stuck with the rom underdogs......    

  don't get me wrong, im enjoying the hydrans immensely............
   

[Karnak]

Quote:
I edited some
scripts like this and found that a well placed, WHERE, AND and ORDER BY
clause on larger queries dramatically improved performance.

Great job, rajnsaj.

It looks like you were not accessing the fields that had indexes built on them. Queries on fields not indexed can extend the query time by 3 to 4 times a query on indexed fields.