DROP itself is 99% done.
Rev's part with modules will be done when they are DONE.
Cherokee will be updating the Drop site...
I made it but its moving to Ck's Cold Fusion Server.

Res Judicata

hrmm, isn't drop the code thats being collaboratedd on to basically play the entire (for the most part) game for you start to finish? And if so whast the point of playing whatsoever. Be no different then scripting 24/7 in majormud. Sure major props for writing something so complex but heh sheesh, or is it more like a command structure with every option imaginable to use at your fingertips?

Information regarding DRoP will be available soon. In short, it is a feature rich socket proxy, with attachable data parser and in-game data model. It makes use of an ODBC database for persistant data storage, allowing for easy reporting. It also features proxy to proxy communication so users can passively share and mine corpie data. Other features available, but don't want to get into it right now.

every one I know uses MYSQL
GAY

Res Judicata

edited to add

PS my company is contributing member or FSF

Free Software Fondation

Free Software Free Society

Res you suck..... I hear pretty well.

quote:Originally posted by Res Judicata
Cuz DROP IS ON THE WAY TO ENHANCE TW like TWX did times 1000

Didaskalso and the re\/erend are going to Bring TW to a whole new LEVEL of play and really put the game back into Glory and New Horizons


more like hack it down to an even smaller elite of competent scripters/automated corps/data junkies

heh

or depending on how it was released it really 'could' "bring data management to the masses"

but i doubt it

So how much for registering DRoP? I assume they will be making money off of it.

MySQL I have used, will it work with any other database besides MySQL? I am trying to design a MS Access one, and I have a MSDE 2000 (Mini-SQL Server) database as well. MySQL doesn't seem to be as clear cut as other databases and misses stored procedures and other key elements that I want. Firebird is another database like MySQL that is open sourced, but hard to use and administer. Firebird is based on Innerprise from Borland.

The problem as I see it is that there is no way to plot a path between sectors using SQL language that I know of at least.

You have:

SectorID
SectorNumber
Warp1
Warp2
Warp3
Warp4
Warp5
Warp6

This for a basic table design, ignoring other things like ships, planets, players, mines, nazhaz, etc. That can be added later based on scans.

You would have to have the program read in the info for the first sector, and then read in info for the other sectors and keep doing so until a path to the second sector is found. Unless there is an easier way that I am overlooking? Or do you just load all sector records into memory, and do a quick sort by warp numbers until you find a path to the second sector? It would have to be done in the program itself, and not the database SQL queries or stored procedures.

There are common shortest-path-first algorithms that will quickly return the (you guessed it) shortest path from point A to point B in a node based system. It would probably be best to do this in the program though and not in the DB. For the DB, you'd want to normalize the data instead of having warp1, warp2, warp3, etc.

Something like this:

Sector Tables
SectorID - auto assigned by SQL
Sector - Number
<Other Sector Info>

Warps Table
WarpsID - auto assigned by SQL
StartSectorFID - foreign key to SectorID
EndSectorFID - foreign key to Sector ID


I'll have to look around for the actual algorithm -- the language you use will need to allow the use of linked lists or collections/ArrayLists (in VB or .Net.) I had to write a program for a college class (a while back) that did this for the road system in KY. The same algorithm is used by MapQuest and any other road trip planner software.

For some reason though, I was thinking TradeWars used something other than a node system. Doesn't it actually use a simple 2x2 matrix of some kind with the sector numbers randomly placed in each square?

typhoon - i think you will be pleasently suprised.

orion - i understand what you are saying, and i have two responses.

first response - there will be no cost to register drop. there will be a small cost for having script access to the in-game data objects, but no cost to write scripts, have access to the socket/data stream, etc etc. the 'payment' concept is really a tertiary objective. I am happy just giving the stupid thing away, but others have put work into it.

second response - drop will export data to an odbc data source - it will use it to store data in a persistant format, but it won't be used in calculations, reports, scripts, etc. it's really a tool for persistant storage, and easy generic reporting. relational databases aren't the optimal tool for recursive calculations in the first place. if the odbc database was sql-92 compliant you COULD do it, it'd be considerably slower than an in-memory breadth first search tho.

ddavidson - the tradewars 'universe' is for all intents and purposes a directed graph structure, with weights of 1 on each adjacency. implementing graphs in an rdbms as opposed to an oodbms is unpractical. recursive queries even in sql-92 are very memory and processor intensive, especially the deeper the path. if you WERE to normalize the tables i would have something along the lines of

pk_sector_id (arbitrary primary key)
nm_sector (originating sector) <-- there is really no reason to make this a self-referencing foreign key
fk_sector_id (adjacent sector)

something like taht i guess. you COULD normalize it again, but really there's no point.

Yeah, normalizing the sector information would allow you to store additional information per sector. Benefits of that approach might be an "Ether Probe" type look at each sector along the final completed path. It could also have a port FK stored with each sector (that would be cool.)

Storing this in a database wouldn't be as optimal time-wise as doing it all in memory of course, but as the number of sectors grows, it would be the most scalable. The memory requirement would remain fairly static but the CPU time to calculate would vary. If you were using .NET or classic ADO, you would only need to define the command and parameters once and then change the parameter(s) value and re-execute each time. Of course, it was back in '97 when I last wrote a BFS algorithm, so I'll assume you're more up on the matter than me (at least concerning the benefits of an OODBMS compared to using a relational system.) I'm not sure what the time comparisons would be against an RDMS that sends a lot of highly optimized round-trip requests to the database.

Well I made it as simple as possible without normalizing. Yes a linked list would have to be used with some sort of function that can plot a course using it and figuring in for avoids. Figure no more than 20000 sectors in memory at once. Each sector can have up to six warp links.

I would like to make a database that links up to your ODBC source. Are you giving out any info to programmers to interface with it?

Orion_Blastar: Considering only database design, there are several benefits of normalizing what you suggested.

With a

Sector ID
Sector #
Warp1
Warp2
Warp3
Warp4

type system, you'll find that simple queries like "How many warps does sector #444 have?" and "Is sector 444 adjacent to sector 555" become much more complex. If these queries are complex, imagine what a more complex query built on 1 of those concerns will be. Putting a NumberOfWarps field in with the sector will solve the first issue but still leaves the remaining issue. If this data is normalized, it would be easy to answer these types of questions, find 1-way warps, etc. There is also a benefit in storage requirements since you will only be storing exactly the warps that are in the system instead of having a [SectorID=1][SectorNumber=4444][Warp1=8231][Warp2=NULL][Warp3=NULL][Warp4=NULL], etc.

orion - we are going to assume that the USERS of DRoP will provide their own ODBC compliant database/data source. We will simply require that the user provide us with the DSN and then we will create the tables and such. It will be up to the user to secure the database if required, and the table formats will all be open (obviously).

Didaskalos, there still has to be a table design that the ODBC connection can hook into. A UDL file would be easier and the user can change it on the fly, as in password, user id, location, database type, etc.

DDavidson, I understand normalization, like having an employee table link to an address table instead of storing the address in the employee table. Address and employee would be linked via employee_key, so it can have multiple addreses in a one to many relationship. My Access and DB skills are rusty, but not that rusty. I knew that queries wouldn't work in this example that a programming function would have to find the linked sectors, so I made a basic table structure that would let the program read it into memory and then process it with a recordset or a linked list. It still could be done with linked tables too, but I didn't want to make the problem too complex or else others may not be able to follow it. I think we lost many people talking about database structures and advanced programming technuiqes in this thread.

Anyone still awake out there?