-
Hi all,
Figured it was worth kicking off a discussion about the wilds. I'd like to hear everyones thoughts on what you're actually looking for.
I've attached an old copy of my wilds (this version is much closer to the wilds code you're probably still using because mine grew from the same wilds snippet originally) - old because after this version my wilds added things like adaptive maze creation and terrain events like flooding, flowing lava trails etc which depart so far from stock rom that it would be pointless to go into here just now. I wondered if you'd like to take a quick look and see if it's the kind of thing you wanted to move towards.
The wilds.c and wilds.h are the basic definitions and routines that allow handling of the wilds datastructures. I tried to keep as much of it as possible seperate from the rom code itself - mostly because noone has ever released a decent wilds code snippet for rom and I figured to release it to the public domain when finished. There are of course a number of routines in the rest of the code (for moving chars into virtual rooms etc) that are also required.
Features:
* The wilds are a linked-list subset of the AREA_DATA structure, which means not only can you have wilds in any area, you can have multiple wilds in any area. For example, quite apart from the huge world wilds you can create, you could have say a courtyard sized wilds area in a castle, an arena-sized wilds in an arena area etc.
* We do not load all the rooms in the wilds into memory. Instead we have a 2D array of ASCII chars, each signifying a terrain type, and a lookup table of terrain types - room templates for a particular type of terrain that can be loaded up at any coordinate in the wilds map at any time. So for 1000x1000 (1 million room wilds) we have a million bytes in memory instead of (sizeof(ROOM_DATA)*1mil + required string mem).
* Only Rooms that are occupied or have something happening in them are loaded up at any one time. This has little value in very small wilds, but the benefits are obvious when using wilds over say 255x255 in size. This method is very efficient because:
a) We're only using the memory we actually need.
b) We're not repeatedly accessing an HD file (thrashing/contention etc).
c) There is no update_area lag due to having to process a huge amount of rooms seqentially.
d) When we do create and destroy virtual rooms, we do so from the heap list rather than allocating/deallocating memory all the time.
e) We decouple the size of the wilds from the performance of the wilds. I've successfully tested wilds in excess of 50 million rooms.
* mobs and objects in the wilds are held in wilds lists, containing their coordinates and various states. When a char moves into a room, the lists are checked and anything in the room is loaded up on the fly. Operations and scripts can still run on these entities - just because they're not actually in a room doesn't mean they don't "virtually" exist. Think of it like the matrix. The world doesn't actually exist - the world is created around entities as required. "There is no spoon".
* Ranged effects are workable because all that is required is a vector (south, 3) or euclidean coordinate calculation to find the room that an effect will be applied to. The entities affected in that room are easily looked up via indexing the coordinate.
* If you want to implement terrain effects, we can hold a second copy of the ASCII map in memory - we can apply flooding transformation algorithms to the 2D array to do some really crazy shit like a river bursting its banks and flooding a plain, or a volcano spilling lava down a mountain side. We simply apply a new terrain type to the room to change its nature on the fly. Adaptive wilds - very cool. Incidentally, this would necessitate adding a "height above sealevel" variable to every room in the wilds to give the terrain "form".
* Later, if you haven't gotten sick of me, we might talk about sound. An explosion at coordinate 1000,1000 would be of volume 100 in that room, and the immediately surrounding rooms. Depending on terrain (a thick forest might muffle the sound a bit for example), we can calculate the diminishing volume of the same sound in the rooms radiating out from the epicentre of the sound. I've done some other really crazy stuff with sounds like echoing down corridors, monsters growling on the other side of a door etc. Could be fun.
I dunno. The basic premise of dynamic adaptive wilds is that you start with your basic terrain map and apply transformations to it so that the terrain can change on the fly, and all the while you're only using as much memory as you need to, while keeping all the entity information required to hand in memory instead of resorting to accessing a file.
Please ask questions. Adding wilds like these will not be a simple or trivial task by any means, but the bulk of the code is modular so I know it's doable within a reasonable timeframe. From a code management point of view I was thinking maybe we could support both the old and new wilds in the code for a bit, since I'm going to need probably months of coding and testing access to the code, but you guys won't want to hold everything else up in the meantime. Perhaps we could work out a way that the current wilds can be disabled in-game, so that I can conduct testing on the testport when required but still be able to flip back to the 300 meg version if needed. (How much memory does our server have btw? =)).
A final thought. A new thing I was working on (before I came back to Sent, and got lost in levelling =p) was sector-based compression of the wilds ASCII map in memory. It should be possible to use the zlib API to compress/uncompress sectors of the ascii map on the fly in memory. I hadn't managed to get to the point of producing prototype code or doing any performance testing, but I can see a point in the future where I'd want to go to what i like to refer to as "really really seriously huge wilds(tm)" - to do that we'd have to implement memory compression.
Anyhow - Sorry for the rambling. Check out the code and the thoughts above. I'd really appreciate any comments or suggestions or flames you might have about any of this.
Vizz.
-
Can I say… I love you? Heh, Areo and I had been talking about wilds like what you were describinging, having a sealevel and being topographrical almost. I'm still rather new to coding, and still learning (when I have time :P) But yeah. Alot of what you are talking about is what we've been thinking. So I would say I am excited to see what kind of changes we could make. One last note, wilds in excess of 50 million? Damn...
-H
-
From the looks of it I'm pretty impressed, and it looks like you covered your bases pretty well in handling virtual rooms with things like ranged effects, . It falls along the line of things I have been wanting to implement, but lacked the manpower/time.
Although it will be a considerable effort, most of our code is tucked away in a wilderness.c file. I think even though the wilds use the same room data struct, they are coded different enough from regular rooms that we can scrap what's there fairly easily. After a little bit of familiarization with code, I think you'll be able to adapt what you wrote here with minimal scunt-work.
Currently our wilds are permanent rooms, although exits are virtually managed (i.e. only the exits 8 rooms or so in all directions around you actually exist in memory). It's pretty simplistic and will be easy to take out or replace.
Huger wilds areas and multiple wilderness maps per area sound like a god-given blessing to me.
Nib developed a GIMP plugin that can be used to draw wilderness maps.
Use of vectors, terrain types and transformations, and especially terrain height look very elegant to me. One of the problems with the current wilds is that it's pretty static, for obvious reasons (nobody in their right mind would write a function that goes through 2,000,000 rooms to do anything), and if we cut down the number of rooms cool stuff can be done much more easily. Terrain height could be used to simulate 3D to some effect.
Zlib compression is a good long run idea. For 20 megs it isn't worth it (see below), but if you want to do a **really** big wilderness, you'll probably need it. With more space we could create stuff such as intergalactic travel. Well, just a thought 8)
Here's a snapshot of the machine's memory usage:
````
top - 14:12:22 up 11 days, 15:21, 3 users, load average: 0.20, 0.15, 0.10
Tasks: 40 total, 1 running, 39 sleeping, 0 stopped, 0 zombie
Cpu(s): 3900.0% us, 100.0% sy, 0.0% ni, 56600.0% id, 0.0% wa, 0.0% hi, 0.0%
Mem: 983172k total, 927880k used, 55292k free, 52012k buffers
Swap: 1048568k total, 28k used, 1048540k free, 472668k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32701 sentienc 15 0 343m 340m 1908 S 13 35.4 1350:31 sent
````
Code management: I am going to set up an SVN server on an extra computer I have. If my understanding of it is correct, we can have "new wilderness" in a development branch away from "old wilderness" and have code updates in non-wilds areas of the game without releasing any transition wilds code.
Edit (10/5):
One thing that interests:
> e) We decouple the size of the wilds from the performance of the wilds. I've successfully tested wilds in excess of 50 million rooms.
Do you mean that game performance scales negligibly as more and more wilds rooms are used up, to a certain point? Also, is there any noticeable processing power sucked away in creating and freeing rooms all the time? I can't remember how powerful our comp is, I'm sure Soup or Jonas can tell you, but I think it's quite fast.
-
> Do you mean that game performance scales negligibly as more and more wilds rooms are used up, to a certain point?
Exactly. I mean, performance will scale depending on the number of chars in the game, but as you say, negligibly. The loop handling a users input and output in the game is actually relatively simple and efficient - it's the update loop that causes all the lag most if not all of the time.
It's the old "If a tree falls in the woods, and noone is there to hear it, does it make a sound?" argument. A char in the wilds is only aware of what is directly about them. The rest of the wilds doesn't actually have to exist. Mobs moving around simply increment their coordinates rather than having to bother taking them out of one room and putting them in another. A char who scans around them would see the mobs listed as being in the coordinates that radiate out from their position. There are many other examples, but I don't wanna ramble. =p
> Also, is there any noticeable processing power sucked away in creating and freeing rooms all the time?
Ok, we're into the hardcore stuff now. We create the required room in memory based on the fact that a PC moves into a wilds area. We allocate one room struct worth for it and copy the terrain template for that position in the wilds over that room struct. That's a memcpy - so it's about as fast an op as you can get. After that, regardless of where the char moves, there's still only one room allocated. If they want to look east, we can either create the room east temporarily for the look, then destroy it, or a more elegant solution would be to simply do a look for the terrain type, and map in any chars/mobs/objects in that room as required, without creating another room. But just remember all of this is possible without having to do the massive sequential walk of the entire wilds. It's all just pointers - this char at this position, with these mobs and these objects.
When someone walks out of the wilds, we can free up the vroom they were occupying (assuming noone else is standing in it of course!). All these operations are very fast, so even with 500 chars running around the wilds all at once, you're still only allocating 500*room struct+strings - quite a bit, but still smaller than most of your normal areas i suspect. The only reason you can't really apply this virtual logic to normal areas is because by definition they are content rich - lots of unique descriptions etc. This is not the case with the wilds, altho it should be possible to have a unique list for the wilds too in case you want to put custom descriptions in certain places in the wilds. In that case we'd simply override the terrain type template and copy in the unique features we need.
I suppose we could stress-test the alpha code for the new wilds at some point, by writing a small user bot utilising sockets to connect to the game, log in, and run around the wilds aimlessly until terminated. If your machine (or some other one) can handle a couple of hundred forks of these (I'm hiding from multi-threading right now ok? =)), we could compile the testport with profiling support (-p in the compiler command line in your Makefile), and actually see first hand how well it handles it. I think you'd be surprised at how many this approach will support without any noticeable performance hit.
=)
Vizz.
-
> When someone walks out of the wilds, we can free up the vroom they were occupying (assuming noone else is standing in it of course!). All these operations are very fast, so even with 500 chars running around the wilds all at once, you're still only allocating 500*room struct+strings - quite a bit, but still smaller than most of your normal areas i suspect. The only reason you can't really apply this virtual logic to normal areas is because by definition they are content rich - lots of unique descriptions etc. This is not the case with the wilds, altho it should be possible to have a unique list for the wilds too in case you want to put custom descriptions in certain places in the wilds. In that case we'd simply override the terrain type template and copy in the unique features we need.
I think you've assuaged my fears about any sort of performance problems, esp. when the code we are using now is so much more inefficient 8). Adding support to allow some uniqueness in wilderness areas would be great, and I don't imagine it would be that difficult to do. At the room struct level, the wilds is really about "quantity" more than "quality", at the higher map and region levels the potential for emergent properties becomes incredible.
For example, whenever we get boats in, I wonder if we can use your terrain type codes to create currents in the oceans? Huge whirlpools leading to underground areas? Flying machines possible with a settable "height" of each room? This all looks do-able with what I've seen and what you've described, since the possibilities are limitless when you aren't held down by the burden of eXtreeem memory and cpu usage.
I've looked at the code modules you've attached, and they look very well compatible with our code. Not completely a simple cut and paste job, but that's okay. I understand this is an earlier version of your latest work on this, but it's already a lot better than what we've got.
> I suppose we could stress-test the alpha code for the new wilds at some point, by writing a small user bot utilising sockets to connect to the game, log in, and run around the wilds aimlessly until terminated. If your machine (or some other one) can handle a couple of hundred forks of these (I'm hiding from multi-threading right now ok? =)), we could compile the testport with profiling support (-p in the compiler command line in your Makefile), and actually see first hand how well it handles it.
This is definitely something I'd like to try out, not just for the sake of the wilds, but just to probe different aspects of the code and see how well performance scales with number of users. It'll help us from running into difficulties when there __are__ 200 PCs running around.
;)
-
I should also point out at this juncture that I also have quite a bit of OLC stuff for the wilds as well. Things like "stat wilds", wedit (wilds editor), enhancements to aedit to allow the list of wilds sectors to be displayed, size tweaked etc. Prolly should post that here too for your perusal. I did start work on an in-game wilds editor for smaller wilds sectors, but actually I can't remember how far I got. Plenty of time for that I guess.
With the flying machines, there's absolutely no reason why you couldn't have (x,y,z) coordinates. the z-coor would simply correspond to the entity's height above the ground/sea, i.e z = entity height above terrain + terrain height above sealevel. You could do stuff like casting an airship-shaped shadow on the terrain simply by dimming the terrain colour, or using grey. You'd have to give me more details about how you'd want work work it. I assume an airship would be quicker than a mount, but slower than say, a flying dragon. Flying should not be the same as floating (mebbe rename the "fly" spell later on).
Vizz.
-
Just for shits and giggles, I took our current map and placed it on a MUCH BIGGER map, then took a screenshot of that to give perspective on how BIG this could get…
-
Well, something that came to mind when hearing about this and the thought of having to make a NEW map (or several) .. It occured to me that we could add more to the game as far as emersion by ONLY dealing with the TERRAIN on the wilds map. No named regions like "An Elven Forest". Just have the terrain type "The Open Ocean". That would simplify the terrain tiles greatly by consolidating ALL duplicate terrains that were different due to their NAME into a single tile code.
But what about the names? Well, we could create zones in the game that hold region specifications. The names could either be globally known, OR have them done as player memory lists. A player could associate an area or region to a particular name. Of course, we could also do both. Have the names already defined, but then have exposure to them being required to KNOW the names of them just by sight alone. Maps wouldn't count.
Speaking of MAPS… with the newfangled wilds... we could introduce a cool new MAP object that can show the wilds when looked at. They would take the map info, throw in a scaling factor to shrink the map and some other stuff.
````
v0: scale (level of detail, 0 being NONE to disable the feature on the map)
v1: map number (which map to view from)
v2: center X
v3: center Y
v4: radius
v5: flags (what all can be shown, not sure right now)
````
-
Other things… yes... more!
Stuff mentioned about elevation sparked the idea of having the ocean FLOOR mapped out, giving them negative elevations or just give them REALLY low elevations. Then, it occured to me that we could do this for all bodies of water. Put the underwater surface as part of the terrain map, then use WATER regions, each having a type (fresh, salty, brackish, swamp, blood?!), level and dimensions. If you are ABOVE the level, surface is shown along with all surface terrain. When you go below, the terrain switches to the underwater surface (with a color hue shift for each type of liquid possibly?) with all above surface terrain gone (displayed as black spaces). This could lead to have places like Undersea as an area you actually have to SWIM down toward. This could also have things like having too much weight could make you SINK.. and TRULY drown. :D Ships could sink and their wreckage could fall to the ocean depths!
Now what about the air? Well, I think I saw mention of altitude based flight. Well, I think that as you get higher up, the smaller everything below gets. Imagine looking down and seeing the world like Eagle Eye! Hell, what about this... from the ground, looking up will show the sky (weather? clouds? stars? constellations? MOON?! floating cities! flying creatures, etc). While flying, looking around will either show the terrain or sky (depending on your altitude). Looking DOWN from an altitude will show further down. Looking up will do the same from the ground, only closer.
Now some questions:
How would links from normal areas to these new wilds work? For instance, the east gate of Plith would have an east exit that goes out to the wilderness, but how would I, as the builder, do that? Also, what about exits like the PoA door in the Abyss work? Doors have two sides (or not, depending on your universe!), so things like "bar" would need to be workable on both sides.
-
Heya!
Lots of food for thought there Nib - thanks! The thing to remember is that we have to work within the constraints of the interface we have available to us right now, which is effectively an 80x24 text interface. Perhaps later we could use some funky routines to generate a medium-res picture to the user via something like XML or MXP. I think you would need a higher res interface to do the kind of altitude map-scaling you were talking about.
To turn to your more immediately relevant point about area links, I considered the very same problem. The issue as I saw it was that both the static area file (say plith, for the sake of argument) and the wilds area both have to have exits defined and pointed at each other in order to have a two-way link between them. To this end, I implemented what i called VLinks. Essentially, the definition for the two-way link is defined only in the wilds area, with a blank wall at the appropriate position in the static area to be linked to. The static areas are loaded up by bootdb() and if there's a link into the wilds, the exit is mapped onto the static area at that point. The link back from the wilds to the static area is created/destroyed as required when someone is standing in the wilds room containing the VLink.
Using this method, the static area files don't have to contain any inter-area links at all as they are applied when the wilds are generated. The other nice thing about VLinks is that you can (potentially) use scripting to manipulate the link. For example, a mob could change where a VLink goes depending on some interaction, like a different object being handed over etc. I had been experimenting with shifting-mazes - mazes that auto-randomise while morts/mobs were in them. In order to do this, it was sometimes necessary to relocate the VLink to another part of the maze. (make the maze no-recall too, add a few deathtraps, and suddenly you have a maze that is practically impossible to use an unattended bot in btw).
Vizz.
-
Actually - I just had an idea about the scaling thing you were talking about. I have a nice piece of code that properly handles telnet option negotiation, and part of that is NAWS support. Effectively, with NAWS support, any time the user resizes their viewport window, the server will be informed of their new screen size. So for example, myself with my 1600x1200 TFT, could select small fonts and have a mud window of in excess of 132x100 characters. There's no reason why we couldn't work out the appropriate algorithms in conjunction with NAWS to generate a wilds map for the user that contains more or less detail depending on how big their viewport is.
NAWS is an RFC standard - I refer you to the IANA site if you really really want to know how it works. =)
Vizz.
-
Well, what I meant by scaling was more of using the same display size and applying a dominance algorithm to the terrain such that the most dominant one is chosen over a grid… such as taking a 5x5 grid on the original scale that is 75% grassland and just showing the tile for grassland for that 5x5 grid.
Now a taste of having underwater stuff! You know Undersea... well... How about having the area itself UNDERWATER, far below the surface of the ocean? Imagine if you will a palette of cyans, blues, greens and a few yellows in this environment surrounding a domed area.
-
Yeah that's entirely doable without any more coding work. Please have a look at my wilds editor 'wedit'. It provides you with an illustrative palette of terrain types that you can both define and use. You'll continue to use your plugin for much bigger wilds, but this should give you some idea of the flexibility of the terrain token based wilds:
-
Can the editor handle multiple width tiles? Because, let's face it, the available space for single character tokens is getting slim, and if we add ALOT more to the map, that will require more named zones and such.
Also, could it be done such that the loader (and possibly the editor!) can read the pixel color from the image to identify what it is. Perhaps have an internalized tiling scheme for use with the editor, and have a global list of types that can be modified by an imp IN-GAME.
Another idea that I've tinkered with on virtual maps regarding elevation. Since it makes no sense that you can see the other side of something that blocks your field of view, I added a way to conceal the terrain beyond tiles whose effective elevation/altitude blocked things behind it from your position. It was fairly straight forward, where by it went out radially, extending a sloping height that was used to conceal things as it went along. If more distance locations were above what the threshold was, it set the new threshold and displayed that tile.
-
> Can the editor handle multiple width tiles? Because, let's face it, the available space for single character tokens is getting slim, and if we add ALOT more to the map, that will require more named zones and such.
I don't see any reason why not. I stayed with the 1-visible char per tile format because it was easy to handle while i experimented. Right now I figure you've got A-Z, a-z, 0-9 and the visible punctuation from the keyboard available to you for tile tokens. We could always move to an integer-based system, potentially giving you 65535 possible terrain types (/geek in the strictest sense, an "int" is 16-bit - in practice most if not all 32-bit C compilers provide 32-bit integers that look and operate just like a "long" - unsigned longs can provide storage for values up to 4.2 billion or thereabouts /ungeek).
My problem with doing this is in the inevitable question, "What would this give us?" Since we only have 26+26+10+34(ish) visible tile characters available to us for use in the displayable map in-game, and only8-10 unique colour variations (ANSI), we're never going to be able to use all the integer space for terrain types. It might seem worth it ostensibly, given the extra few terrain tiles you'd gain, but the implications for memory management of using tiles 32-bit in size instead of 8-bit can't be ignored. That said however, you would still be in a better shape than right now with a process size of over 300 meg. Nib I think you and I need to have a geek chat session about how to better utilise your image converter plugin with the new wilds.
> Also, could it be done such that the loader (and possibly the editor!) can read the pixel color from the image to identify what it is. Perhaps have an internalized tiling scheme for use with the editor, and have a global list of types that can be modified by an imp IN-GAME.
Two parts to that one - answered in reverse order. My wedit code already allows you to create/destroy/edit terrain types in-game, although the terrain type is a subset of the wilds itself, so right now there's no global level list of terrain types that can be imported into multiple wilds. There's no reason we couldn't do that tho - each terrain type is essentially a room definition tied to a terrain tile token. We could have a linked-list of generic terrain types available for import into the discreet wilds sectors - or are you talking about moving the terrain type out of the seperate wilds sectors themselves, and have them as inheritable entities from a larger central store in the code? IMHO, terrain types are data, and as such should be kept in files, not in the code (but I'm willing to listen to argument heh).
Read the pixel colour… hmm. You're talking about parsing the image file directly and matching the colour code to a terrain type. I remember we talked briefly about this before, and it's an intriguing idea. How many colours does the image type your plugin produces support? I don't see any reason why we couldn't lift the terrain type straight from the colour code.
> Another idea that I've tinkered with on virtual maps regarding elevation. Since it makes no sense that you can see the other side of something that blocks your field of view, I added a way to conceal the terrain beyond tiles whose effective elevation/altitude blocked things behind it from your position. It was fairly straight forward, where by it went out radially, extending a sloping height that was used to conceal things as it went along. If more distance locations were above what the threshold was, it set the new threshold and displayed that tile.
What you're talking about here sounds a lot like 3d-clipping algorithms, of which i do have some experience. The problem is, how do you get a decent representation in text where you are limited to a 25x25 effective resolution in characters? I could see clipping getting used if we decided to go graphical, certainly. I did actually play briefly with 3d-representations of the wilds map in-game on continuum, playing with sloping map prints, but the staff I had at the time gave it a mixed reception so I decided to shelve the idea in favour of more in-demand features. It would be cool, IMHO if we could render a map on the fly in-game for the players visible surroundings, and deliver it to the user with the likes of MXP support but then we'd be tying the games performance to the amount of bandwidth the user has available to download the picture after every room move. I'd be worried what that would do to both the servers link and the hosting company's good will! =)
Better stop now. My capacity for excessively long posts is legendary. Food for thought tho.
Vizz.
-
> My problem with doing this is in the inevitable question, "What would this give us?" Since we only have 26+26+10+34(ish) visible tile characters available to us for use in the displayable map in-game, and only8-10 unique colour variations (ANSI), we're never going to be able to use all the integer space for terrain types. It might seem worth it ostensibly, given the extra few terrain tiles you'd gain, but the implications for memory management of using tiles 32-bit in size instead of 8-bit can't be ignored. That said however, you would still be in a better shape than right now with a process size of over 300 meg. Nib I think you and I need to have a geek chat session about how to better utilise your image converter plugin with the new wilds.
Well, the reason I mentioned multiple width is, being able to handle, say, two character tiles would only be needed if the used tile space for one character (keep in mind, non-control characters! so it's anywhere from 0x20 to 0x7E, minus the tilde which is the string terminator) is reached, and it is pretty close as it is now.
With regards to the png->area utility, I merely assign a tile code to a particular color value, much like you would in indexed color palettes in GIFs. When the utility reads the png image, it takes each pixel, matches the color to the list of valid colors, and converts it to the particular tile code. Nothing overly magical. 8)
Also, what's your AIM!
-
Contact details:
Email:sc0jack@yahoo.co.uk
YIM: sc0jack
AIM: sc0jackuk
ICQ: 173402032
MSN: sc0jack (i'm still trying to recover my password for this one)
Skype: sc0jack
I have a cam and a mic as well, so please feel free to conf me if you have the same (this goes for any of you in imm-land). I'm working and living away from home right now so apart from anything else I'd appreciate the company! :mrgreen:
Sitrep - spent today building a new ubuntu vmware box on my laptop, so i've got a dev environment again. Just need to get my work-in-progress code off my home machine and I'll be back in business. Gotta talk my gf through tar'ing up my dev folders - that'll be fun lol. (she hates PC's).
Scott. (Vizz)
-
AIM: Xevira
Email: mdkurtz@gmail.com
That's in… don't have many messengers. Don't have a mic or cam. *is a stone age geek*
-
Conversation:
Me (7:48:57 PM): question, … two actually
Vizzini (7:49:05 PM): uh oh
Me (7:49:09 PM): 1) how would one make a one way exit TO the wilds
Vizzini (7:49:31 PM): that's an interesting question
Vizzini (7:50:01 PM): i'm sure i could make it so you could have those
Me (7:50:04 PM): and on that question, how do you transfer someone to the wilds?
Vizzini (7:50:21 PM): we'd need a modified transfer command
Vizzini (7:50:23 PM): like
Me (7:50:26 PM): *nods*
Vizzini (7:50:40 PM): transfer
Vizzini (7:50:44 PM): or
Vizzini (7:50:52 PM): it could look at where you are
Vizzini (7:51:03 PM): and pick out whatever information is relevant
Me (7:51:13 PM): *nods*
Vizzini (7:51:16 PM): but yes - good point
Vizzini (7:51:21 PM): write that down lol
-
Me (8:03:20 PM): idea: exit colors!
Me (8:03:42 PM): for the vlinks
Vizzini (8:04:36 PM): yes good one
Vizzini (8:04:45 PM): so you can have blue underwater ones
Me (8:04:55 PM): *nods*
Me (8:05:14 PM): I had done that before by specifying a different color for codes 0 - 9
Me (8:05:40 PM): so if you wanted a dark grey O, you'd use the tile for dark grey
Me (8:06:04 PM): hrm
Me (8:06:20 PM): another idea… allow for a string for the exit link itself
Vizzini (8:06:28 PM): you need to write this shit down in the coding forum or i'll forget
Me (8:06:49 PM): instead of a {BO (blue Oh).. we might want to do a {B@
Me (8:07:02 PM): oh, I've pasted :D
Vizzini (8:07:18 PM): oh ok
Vizzini (8:07:57 PM): well if we allow different chars for vlinks, how will people know what to look for?
Me (8:07:57 PM): like the last one I pasted
Me (8:08:18 PM): well, it would have to be carefully chosen
Me (8:08:56 PM): like the vortex for Undersea (which I think should ALL go away whenever we can do underwater stuff)
Me (8:09:16 PM): @ looks like a vortex
Me (8:10:18 PM): could do stuff like ... a {y= for a drawbridge. or some such like that
Vizzini (8:10:30 PM): interesting. ok point taken
Me (8:10:37 PM): *nods*
Me (8:10:45 PM): granted, most will likely be O's
