Here are the systems that I want to chop out and rewrite in Newtopia at the moment:
* The equipment system. Presently I use a slot-based, one-item-per-location system. I've been considering moving over to a one-item-per-limb system and allowing all other equipment to be dynamically worn and layered on the body using a series of coverage locations. If an article's "locations" list has a location that your character doesn't have, the article can't be worn by your character, which allows species-specific clothing to be made with relative ease. For instance, an Ant's shirt could be made with four arms, so any Being without four arms (i.e., all except Spiders) would be unable to wear it.
* The event system. Yeah, this is significant. The event system as it exists is quite impressive, but it has a shortcoming: it assumes that an action will always be witnessed by everyone. I can hack the existing system to include an "excludes" list, but I'd prefer to make the system a little more intelligent about who it reports to and what sense they use to gather their data -- for instance, if I can learn more about a forest fire by smell than by sound, I'd prefer to smell the fire than hear it, even if the sound is louder. The reason there's a problem here is that I had exported Newtopia's event system to Haven, abandoned Newtopia, and continued to work on it in Haven. When I came back to Newtopia after I couldn't resist working on it, and finally caved and asked Lexy for permission, I still had the old event system and not the new one. Unwisely I figured the original system would be "simpler" and that I wouldn't need to overwrite the original with its newer incarnation. Now I'm regretting that.
* The map system. The map system as it exists is disgustingly slow. It takes approximately 5 seconds to load each map, and for reasons I can't quite explain, the system allows multiple maps to load simultaneously even though I explicitly use only sleep(0) and sleep(-1) statements all around. This causes the game to turn into a stutterfest on my AMD 3200+ for 30-40 seconds when a single 7-map hex chunk is loaded (e.g., when the first player is placed into the Sanctuary, or when someone is loaded off in the wilderness), when it would take the same amount of time without the stuttering if it didn't load simultaneously. The other thing is that I wanted to have the terrain system almost like "stacks of dinner plates" -- where you have your substrata, your surface strata, your dirt layers, your cliffs, and so on and so forth all represented as individual, unique layers which you can actually tunnel up into and sideways into -- so you can make hobbit-style hillside burrows or you can dig an underground tunnel from the bottom of a cliff to the top of a cliff.
The biggest culprit for the slowdown I have, I imagine, is the fact that I'm using trees as objects instead of as turfs. This gives me better control over the layering of the trees and allows me better control over verb access than having trees as turfs... but since after some thought I figure I'm going to have the 'scale' verb present all the time anyway, to allow people to 'scale' out of pools and the like, I'm starting to consider hacking that part out and replacing it with something more robust and less CPU intensive.
Not surprisingly, I'm very demotivated. I was excited when I went into Newtopia's code today because I had found a muse and gotten some good ideas for armour and clothing and I wanted to bring them to fruition. That buzz got killed; I tested out some of my diving and swimming features again and noticed that there was no actual cue to other people (other than the player's icon disappearing) when someone submerged, dove, or resurfaced. So, I wrote a simple event to handle that circumstance, and ran into a wall -- how do I tell people on one layer that the player just swam up, how do I tell people on the other layer that the player just appeared from the depths, and how do I tell the player what exactly he did?
It was a slippery slope from there...
"Let me guess, you picked out yet another colorful box with a crank that I'm expected to turn and turn until OOP! Big shock, a jack pops out... and you laugh, and the kids laugh, and the dog laughs, and I die a little inside." --Stewie Griffin
Except the calling procedure doesn't use spawn() -- it simply calls the LoadMap() procedure directly. Theoretically speaking, it should never spawn... yet it does.
Weird stuff for sure. | |
But is LoadMap() called from different "threads"? (Remember that each verb invocation, or other client activity, starts a new "thread"...)
| |
No. LoadAdjacentMaps() attempts to load all adjacent maps sequentially and the load map routine automatically ignores maps which are already loaded.
| |
Yeah, okay, that is pretty weird then...
| |
Even sleep(-1) still allows pending events to trigger... if your map loads are being spawn()ed off into separate "threads", then that would be the reason. =)
You could create a sort of map-loading-queue system. Whenever you want to load a map, you check to see if there are currently-loading maps. If not, set the "map loading" flag to true and spawn() off the map-loading procedure. But if you are, just append the map ID to a global list. Then, when you finish loading a map, pop the first element off that list and load that map. Don't set the "map loading" flag to false until that global list is empty.
That is a bit complicated, but if you're having map loads triggered from all over the place in the code then you'll probably need it to be similarly robust.