03 Jan, 2011, RoFAdmin wrote in the 1st comment:
Votes: 0
Hey everyone-

So im moving along rather nicely in my projects here, and have come to another section where i decided i would like to get some input and ideas from people on how exactly to go about handling what i would like to do.

I would like to make my world as persistent as possible. Meaning i want to be able to save all objects and npcs that are currently active in the game world and then load them up at reboot. The process itself isnt hard, my question really stems from what is the best way to go about saving them.

Important information to know.
Every loaded object and npc has its own uniqueID, no thing of the same type can have the same uniqueID. So a NPC and an OBJ could in theroy have the same UniqueID, but since different system handle them there is no need to worry about the overlap.

uniqueID's are: "[VNUM]-[LOAD_COUNTER]"
So for example say the vnum of the NPC was 500, and the NPC that was created was the 15000 one, the uniqueID would be "500-15000".

THE WAY IM THINKING OF DOING THIS:
Im thinking of having the server create a new file for each persistent entity, and then saving all related information in that file (stats, nested objects etc).
The files would be named as follows [UNIQUEID].(npc|obj)

PROS:
  • easy to find and edit any single persistent entity without being in the game and scrolling through a HUGE file.

  • a single file getting getting jacked up in anyway doesnt cause the whole set on persistent data to not be loaded, just that entity.

  • I just feel this overall is a cleaner approach.


CONS:
  • Alot of files could potentially be created. This could overrun the directory limit for files if this is ignored


QUESTION:
What would be the best way to go about creating some sort of system to save all these files so that i dont overrun the directory limit?

MY PONDERED SOLUTION:
Im currently thinking obviously two directories NPC and OBJ, then within the directory i create 32 folders (limit of 32k vnums currently, yes i know i should extend this). Each folder holds a block of 1000 VNUMS.
SO….
NPC with VNUM of 500 and LOAD_ID of 15000 would be stored in directory NPC/00001-00999/500-15000.npc
NPC with VNUMof 1001 and LOAD_ID of 15000 would be stored in directory NPC/01000-01999/1001-1500.npc

Does that make sense? Does this seem like a good approach?

And before anyone asks, i already decided i didn't like the idea of storing all persistent NPCs and OBJs in a single pers.npc and pers.obj file. I have my reasoning, which if you would like illl be glad to share, but as it stands i don't feel that is an option i want to peruse.

How would you improve what im attempting to do here? or how would you do it differently?


Thanks in advance
03 Jan, 2011, Cratylus wrote in the 2nd comment:
Votes: 0
Sounds like a candidate for a DB.
03 Jan, 2011, RoFAdmin wrote in the 3rd comment:
Votes: 0
Hey Crat-

Yes it does sound ideal for a database doesnt it.
Sadly im currently developing on Cygwin, which doesn't appear to have any native support for any type of Sql connection except PostgreSql which i would prefer not to use.

Has anyone else gotten MySql working on Cygwin, or more accurately the client libraries (since i already have a DB host using MySql)?

Thanks
03 Jan, 2011, Cratylus wrote in the 4th comment:
Votes: 0
That doesn't sound right at all.

I'm pretty sure there's MySQL for Windows. Why you'd need to run it in Cygwin is beyond me, but
I'd be willing to wager if you really had to you probably could.

Your main problem would not be Cygwin, it would be your codebase's ability to talk SQL.

-Crat
http://lpmuds.net
03 Jan, 2011, Tyche wrote in the 5th comment:
Votes: 0
RoFAdmin said:
Hey Crat-

Yes it does sound ideal for a database doesnt it.
Sadly im currently developing on Cygwin, which doesn't appear to have any native support for any type of Sql connection except PostgreSql which i would prefer not to use.

Has anyone else gotten MySql working on Cygwin, or more accurately the client libraries (since i already have a DB host using MySql)?


Did you notice that there wasn't a ROM package available for Cygwin either? Nor from Debian or Ubuntu? ;-)
Yet we all manage to compile and run the code.

One of the criteria for a package being available in the "official" Cygwin package list is that there be a maintainer.
There isn't an "official" Cygwin MySQL package because there isn't anyone interested in being an "official" Cygwin MySQL maintainer.

However there is a project for Cygwin that contains many orphaned distributions.[1]
http://sourceware.org/cygwinports/

You'll find a MySQL distribution there. No guarantees on it being up to date, because it don't have a maintainer.
In any case it comes with source code just like ROM.

Personally I'd go for SQLite or Postgres over MySQL if you want to go with an RDBMS.
I'd alkso consider hash dbms like BDB and GDBM.

[1] Quite likely a better source for getting it compiled on Cygwin would be the MySQL project itself!
03 Jan, 2011, Tyche wrote in the 6th comment:
Votes: 0
Cratylus said:
I'm pretty sure there's MySQL for Windows. Why you'd need to run it in Cygwin is beyond me, but
I'd be willing to wager if you really had to you probably could.

Your main problem would not be Cygwin, it would be your codebase's ability to talk SQL.


A Cygwin version of the MySQL client code can certainly talk to a MySQL server running on native Windows or Linux or Cygwin.
However you can't link a Cygwin application to the Windows MySQL client dll without problems.
03 Jan, 2011, plamzi wrote in the 7th comment:
Votes: 0
Even if you have a great machine, I would advise against running MySQL under cygwin. There shouldn't be a problem running it natively under Windows, with significant performance benefits, I'd imagine. I don't think there would be a problem getting an API from inside Cygwin to connect to a db running natively on the box. You'll just need to compile the API if it's not already available as a Cygwin package. For instance, the C API seems to compile fine as per this thread: http://cygwin.com/ml/cygwin/2006-05/msg0...
03 Jan, 2011, Tyche wrote in the 8th comment:
Votes: 0
plamzi said:
Even if you have a great machine, I would advise against running MySQL under cygwin.


Why? Have you tried it?
03 Jan, 2011, RoFAdmin wrote in the 9th comment:
Votes: 0
@everyone:
Im a windows developer, not a linux one. My familiarity with linux goes as far as a class i took back in high school (12 years ago), and what i have learned mucking around with MUDs. So some stuff that seems easy or obvious to you, is simply just things im not familiar with. I do attempt to do my research before posting, but if im not finding the answers i need in a timely manner i do turn to the boards here since i know most of you have already done such things and can give better guidance then a poorly written tutorial on how to do xyz.



@crat:
Wasn't trying to run MySql server in Cygwin, i just needed the client libraries. I have a windows server setup elsewhere where i already have MySql running that i was planning on connecting into. As you pointed out my problem is getting cygwin to talk to the MySql server, which is why i need to compile it in cygwin to get the client libraries.

@tyche
LOL, yes i did notice that ;)

I actually had previously downloaded the MySql source, and attempted to install it as per this article
http://www.drk.com.ar/docs/windows/mysql...
however when i attempt to ./configure –without-server it says "./configure: no such file or directory"
Im assuming im going about something wrong. More then likely the article is outdated since its for version 4.something and im using version 5.5.8

i do however see a configure.cmake fiel in the directory…..

Any insights into this? and yes im sure its something easy, and obvious that im missing, but as i said i r linux n3wb. So please enlighten me sir.

Also i was wondering what was making you recommend PostgreSql or SQLLite over MySql? My only real reason for choosing MySql in the first place is my Server i have setup is currently already running it, and im familiar with it, beyond that i have no particular reason to not choose something else.

Thanks for the responses people. Yall rock.


[edit]
Also Tyche i was wondering if you had considered putting up an 800 number with a per minute charge for people to call and you answer questions since you seem to be a human library of MUD/*nix knowledge. lol
04 Jan, 2011, Idealiad wrote in the 10th comment:
Votes: 0
1-800-YO-TYCHE
04 Jan, 2011, plamzi wrote in the 11th comment:
Votes: 0
Tyche said:
plamzi said:
Even if you have a great machine, I would advise against running MySQL under cygwin.


Why? Have you tried it?


I haven't tried it. But while I was running my MUD under Cygwin someone noticed that ticks, which used to be exactly 70 sec. apart, actually took additional 5-6 seconds. I never got to the bottom of it, but it seemed like either a CPU cycles or machine time issue. A virtual environment is never as fast as a native one, that I know for sure and would not attempt to run anything under virtual when I can just as well run it under native.

RoFAdmin said:
@crat:
Wasn't trying to run MySql server in Cygwin, i just needed the client libraries. I have a windows server setup elsewhere where i already have MySql running that i was planning on connecting into.


I hope that by "elsewhere" you mean another local box connected to the server over ethernet. If you plan to run any MySQL queries after the game boots, you're going to need very fast response time–otherwise there'd be noticeable 'hiccups' for everyone in-game. This I have first-hand experience with.
04 Jan, 2011, RoFAdmin wrote in the 12th comment:
Votes: 0
@plamzi:
Nah, i do mean a remote box hosted elsewhere. I only plan on reading from it at start up, and then writing to it randomly to save certain information. There wont be any query of the database to get important game data while its running.
04 Jan, 2011, Scandum wrote in the 13th comment:
Votes: 0
I think software runs about 3 times slower under Cygwin than natively, which is somewhat of an advantage development wise as bottlenecks are more apparent.
04 Jan, 2011, Tyche wrote in the 14th comment:
Votes: 0
plamzi said:
I haven't tried it. But while I was running my MUD under Cygwin someone noticed that ticks, which used to be exactly 70 sec. apart, actually took additional 5-6 seconds. I never got to the bottom of it, but it seemed like either a CPU cycles or machine time issue. A virtual environment is never as fast as a native one, that I know for sure and would not attempt to run anything under virtual when I can just as well run it under native.


Cygwin is not a virtual environment (like VMware of VMLinux). It's a native Windows application. I haven't experienced any timing issues with my mud code. However I do know that some muds written for Linux expect select() to change the timeout value on return, and use that in subsequent timing calculations. This will porting problems to most other Unixes (including FreeBSD and Cygwin). While POSIX allows both ways, it treats timeout as undefined.
04 Jan, 2011, Scandum wrote in the 15th comment:
Votes: 0
The most likely cause is that the cpu load isn't evenly spread out over the MUD's heartbeats, causing the most intensive heartbeat to last too long, resulting in unstable ticks as delays accumulate.
04 Jan, 2011, Cratylus wrote in the 16th comment:
Votes: 0
Scandum said:
The most likely cause is that the cpu load isn't evenly spread out over the MUD's heartbeats, causing the most intensive heartbeat to last too long, resulting in unstable ticks as delays accumulate.


Depending on the matrix mapping of the hash array, of course. And its polarity.
04 Jan, 2011, Tyche wrote in the 17th comment:
Votes: 0
RoFAdmin said:
I actually had previously downloaded the MySql source, and attempted to install it as per this article
http://www.drk.com.ar/docs/windows/mysql...
however when i attempt to ./configure –without-server it says "./configure: no such file or directory"
Im assuming im going about something wrong. More then likely the article is outdated since its for version 4.something and im using version 5.5.8


I prefer developing for Windows myself.
It looks like MySQL now uses cmake to build instead of GNU autotools.
I imagine all the links presented here on how to compile it on Cygwin are out of date.

RoFAdmin said:
Also i was wondering what was making you recommend PostgreSql or SQLLite over MySql? My only real reason for choosing MySql in the first place is my Server i have setup is currently already running it, and im familiar with it, beyond that i have no particular reason to not choose something else.


MySQL is the only RDBMS I have ever run, where I've encountered database corruption. One bitten, twice shy.
04 Jan, 2011, Tyche wrote in the 18th comment:
Votes: 0
Scandum said:
I think software runs about 3 times slower under Cygwin than natively, which is somewhat of an advantage development wise as bottlenecks are more apparent.


I think it don't.
Of course profiling and benchmarking is far more useful than thought experiments.

Scandum said:
The most likely cause is that the cpu load isn't evenly spread out over the MUD's heartbeats, causing the most intensive heartbeat to last too long, resulting in unstable ticks as delays accumulate.


Since Cygwin don't do "virtualization" or scheduling, that's the least likely cause.

Murk++ doesn't exhibit any interesting or unusual behavior in regard to TICKS whether it's running on Windows, Cygwin, FreeBSD, or Redhat.
I would conclude it's an application problem.
04 Jan, 2011, plamzi wrote in the 19th comment:
Votes: 0
Tyche said:
Murk++ doesn't exhibit any interesting or unusual behavior in regard to TICKS whether it's running on Windows, Cygwin, FreeBSD, or Redhat.
I would conclude it's an application problem.


For what it's worth (could be off topic entirely), the codebase in which I experienced tick slowdowns under Cygwin is pretty much vanilla circle. I believe it uses machine time to schedule a pass every 0.1 seconds. I haven't looked into that part of the code in depth, but it seems that if passes take more than 0.1 seconds on a regular basis, or if machine time itself is for some reason imperfect, one would experience a tick slowdown. That's just one possible explanation, and it could be a red herring, but it made me wary of Cygwin.
04 Jan, 2011, Scandum wrote in the 20th comment:
Votes: 0
Tyche said:
Scandum said:
I think software runs about 3 times slower under Cygwin than natively, which is somewhat of an advantage development wise as bottlenecks are more apparent.

I think it don't.
Of course profiling and benchmarking is far more useful than thought experiments.

My own codebase takes 6 seconds to boot using Cygwin and 1.5 seconds using Slackware. CPU load is roughly 3 times higher.

Tyche said:
Scandum said:
The most likely cause is that the cpu load isn't evenly spread out over the MUD's heartbeats, causing the most intensive heartbeat to last too long, resulting in unstable ticks as delays accumulate.


Since Cygwin don't do "virtualization" or scheduling, that's the least likely cause.

Murk++ doesn't exhibit any interesting or unusual behavior in regard to TICKS whether it's running on Windows, Cygwin, FreeBSD, or Redhat.
I would conclude it's an application problem.

Virtual machines are worse than Cygwin, but Cygwin is still slow.

The reason Murk++ doesn't exhibit unusual behavior is probably because you load it with 10 areas, 1 player with a small inventory, few mob progs, and little bloat in the update routines. If Plamzi was to add a log call each time a heartbeat exceeds its allocated time he'd probably get warnings even on Linux.

Cratylus said:
Depending on the matrix mapping of the hash array, of course. And its polarity.

This is more of a driver related topic, I suggest you stick with simple mud lib stuff like creating skills, areas, and talking about the great things you'd create if you weren't a talentless douche-bag.
0.0/33