Nice.
Clears up a lot of questions regarding the database, I'll get that rolling up to spec shortly... I just thought "file based" would be easier for getting it(vegaserver) off teh ground and functional. Once I've got the DB functional, Can expand the table later...
I'd not considered dynaverse.dat in (a seperate)DB, I'm still a little hazy as to it's purpose but from what I can make out, it'd make sense to be in one? I'm shoeless as to how this may effect nido's "markets" but would imagine long term it'd make a lot of things easier, and not just for that.
As for the heiarchial structure, I'm thinking complex, heh. Ideally, for a basic tree you'd need a "super admin" at top of the pile, The lesser number of these the better, but should require at least one... This would hold ultimate control over all functionality, including the ability to start/stop/restart the server (Ideally with some sort of timer, and broadcast message for logged in users for "fair warning"), This sort of administration could potentially take place via cli, in game via the "chat" or on web via some php admin panel. Under that, a collection of "admin" - can be delegated unto the account maintainence(needs a way for users to autonomously reset they pass, too, with human attention and recording previously used IP's and some other data may be possible to deduce genuine reset request, or if otherwise known to operator), and general responsabilities akin to a mod on a forum, including errant user eviction and banlist maintainence. Under them should exist the Faction Leaders, Responsible for the manipulation of and interaction between the opposing factions... defining and enforcing rates of bonus, tax and possibly even trade sanctions upon inter-faction trading. When Nido's markets apply, they should have control over the initial resource distrobution within their sectors, and the ability to(should they chose) delegate manage responsiblity to other faction members... with some sort of "tax" on resources pooled up to fabricate more resources(ie: mining stations, factories, shipyards etc) They should also be delegated control over their faction membership, Pilots should request to join, and be autherised (Pirates and Unadorned aside, They should have no faction leaders. Default un-factioned state, unadorned)- individuals refusing to conform to policies(Ie: refuses to cease hostile acts upon friendly factions) exiled from faction. Lastly, individual pilots... I would say "squadron leaders" but as owning more than one ship is currently certain death I think it's a bit much(But one day, one may control fleets).
If it wasn't clear from the above, each faction should have it's own internal hiearchy.. To illustrate crudely in ASCII...
Code: Select all
|¬General
|¬Admin |-----¬Major
|--------------¬Faction Leader------|------------¬ Lieutenant
SuperUser----------|¬Admin
|--------------¬ Faction Leader-----|¬Admiral
|¬Admin |-----¬Commodore
|------------¬Commander
Ranking within the faction should ideally be dealt with by the faction leader, definitions of how to attain what rank I'm unsure, but I'm thinking kill count so far.
As for fields within the database, For the basic layer of the tree above, will reqiure:
UNKNOWN, // --> ??
PLAYER, // Username
ADMIN, // Password(?)
ACCOUNTS, // Server-Assigned Serial No(?)
SHIP, // Current in fleet in use, will need later when have more than one ship... or could possibly use to change ship start with instead of making a new account.
ACCIP , // IP used to fabricate user account
LASTIP, // IP last used for successful login, ideally would need to hold last 10 unique, possibly elsewhere.
EMAIL, // Basic contact details, somewhere to send autonomous password reset. Possibly may be good to provide for other optional contact details.
ISSUPER, // A simple yes/no flag could enable for easy deployment of assigned superusers
ISADMIN, // A simple yes/no flag could enable for easy deployment of assigned admin
FACTION, // Faction to which user belongs
ISFACTION, // A simple yes/no flag could enable for easy deployment of assigned faction leaders
RANK, // Can store the attained rank in here, editable by faction leaders, in their user panel. May be good to allow for a few values, Rank as pirate and for last two factions
ezee wrote:REEDIT : Perhaps i'm wrong , but it seem to me that for your MMO project , we could use
the native http server of your server , instead of this set of .py files
lol - exactly what I was trying to do. If I could understand how it(vegaserver) talks to teh accountserver, I was hoping to make apache fulfill the same role... I'm currently shoeless as to how to feed it from forms. I was thinking once SQL, it'll talk to the database direct... Armed with .php complient user fabrication I could slide
the test signup out of /test along with the other contents, and sat on the root of the served space it should function as per the SF page(I'll maybe even make teh effort to link it) aside from my modifications ofc. And should be a nice a pro-looking interface to present to the public (The abortion I made of the .py is embarressing, I'm sure I overwrote it with the original, too, clearly the wrong one. It's in too many parts! blah!)
Currently, in single player, ships take denotion: [Faction].{Squadron}.(squdNo) - as in Morrowind.mule.2 - indicating the second Ship, which is a mule in the Morrowind squadron... In the multiplayer, user should allow for rename they fightergroup - as long as unique - It currently spawns off(at least, on my end) as per single player.