> You did miss the point about this ... the point was the "search" part of > it.
I really didn't miss the point.. I was looking for a logical answer. >but C is also not a scripting language, How so? You do know that you can write fully scriptable game logic in plain C don't you? You don't really need an external scripting language. C can do it all by itself... >On the subject of overhead by the way, the same argument could >be used for threading, that muds have run forever without it, How so? Is this based on knowledge? Know anything about coroutines? Did you know that they are faster than processes and threading? Did you know that they also lessen the resource usage because coroutines don't access the OS kernal whatsoever? Did you know that it was first done on Linux but is also cross platform capable? > and some have functions that do take a while to run (like massive searches > through thousands of pfiles) if you use an sql database on a separate I've never seen a mud with 1000's of live, in use profiles... > logged on. I'll give you an example though, try adding 400,000+ rooms to a > rom mud (with the addition of long vnums and ivans olc) and do an asave Sorry to tell you but rom won't load them whether you use a database or not. A database with that many would make the mud so unplayable it would be useless. I hope that all of your decisions are not based on "Could be" events in the future.. I'm trying to plan for future expansion as well but I am at least trying to do it based on logical facts and not some "would be" examples.. As I said before, I see a logical solution for everything than can be mentioned.. It comes from years of research and learning.. I guess that's why I've learned to get around many of the problems associated with the standard codebase simply because I needed to do so.. Not because I thought I had too.. I'm not knocking you for your examples.. But you are a bit off on many of your interpretations of C.. Chris
