-
> 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
-
Progress note to self.
Wilds integration continues at a slow pace. The more i add, the more i break.
1) Need to sort out the terrain template loading. Sent uses a custom routine called new_load_room(ROOM_INDEX_DATA *room, AREA_DATA *pArea), which is incompatible in format to my own routine. It makes more sense for me to port the actual wilds code to utilise this routine, rather than the other way around.
2) Sent's char_to_room() and char_from_room() routines are wildly different from both stock rom and my own routines. These will need some serious porting.
3) My join_world() routine will need ported into the sent code. This handles the chars entry into the world, and handles whether or not they pop into a wilds room or a normal static room.
4) All the nice code optimisations I worked in around not using vnums in the wilds anymore will have to be reengineered for sent all over again. rooms, mobs, objs, scripts x3
5) Consider ramifications of token logic for virtual rooms.
6) update routines will also need audited.
Scott (Vizz).
-
Me (7:34:54 PM): yo sco!
Vizzini (7:35:06 PM): wazza!
Vizzini (7:35:14 PM): man i'm nearly finished!
Me (7:35:19 PM): *nods*
Me (7:35:29 PM): I… added a field for terrain passability
Vizzini (7:35:42 PM): ya cool
Me (7:35:45 PM): instead of trying to keep a list of terrains that are impassable
Vizzini (7:35:53 PM): nods
Me (7:35:55 PM): I added a field that defines passability
Me (7:36:03 PM): so you won't care which tile is which
Vizzini (7:36:23 PM): nods
Me (7:36:25 PM): it's a line above the Terrain 0
Vizzini (7:36:26 PM): that'll work for now
Vizzini (7:36:32 PM): till we come up with something better
Me (7:36:34 PM): a number
Me (7:37:03 PM): basically you have the 0 for the Terrain section before the standard room section
Me (7:37:22 PM): before that on a line by itself is a number.... 0 = impassable, 1 = passable
Vizzini (7:38:11 PM): yes - that's how my terrain format works
Vizzini (7:38:20 PM): uhm
Vizzini (7:38:27 PM): can't remember which way around it was tho
Vizzini (7:38:37 PM): 1 was impassable i think =p
Me (7:40:58 PM): ?
Me (7:41:07 PM): oh, that's what the 0 means?
Me (7:41:26 PM): that's the impass field?
Me (7:41:38 PM): (you never did tell me what the fields were for Terrain! :P)
Vizzini (7:42:02 PM): oh yeah sorry - i gave you the vlink thing
Me (7:42:09 PM): *nods*
Vizzini (7:43:23 PM): if you have a look at the wilds.h file i uploaded to the coders forum, it's in there
Vizzini (7:43:35 PM): it's the wilds_terrain structure
Me (7:43:35 PM): ok
Vizzini (7:43:43 PM): mapchar
Vizzini (7:43:46 PM): showchar
Vizzini (7:43:48 PM): showname
Vizzini (7:43:52 PM): briefdesc
Vizzini (7:43:54 PM): nonroom
Vizzini (7:44:01 PM): room template
Vizzini (7:44:11 PM): nonroom is the 0 you were talking about
Vizzini (7:44:14 PM): it's a boolean
Me (7:44:26 PM): ahhh
Me (7:44:31 PM): ok
Vizzini (7:44:32 PM): 0 = normal room, 1 = nonroom, as in, never load it cos it's impassable
Me (7:44:35 PM): ok
Me (7:45:10 PM): there
Vizzini (7:45:14 PM): crap - it's 1:45am... do i go out for smokes and continue, or go to bed?
Me (7:45:14 PM): figst it!
Me (7:45:26 PM): both
Me (7:45:36 PM): you have a laptop
Vizzini (7:45:42 PM): lol
Vizzini (7:45:45 PM): twisted logic
Me (7:46:03 PM): though.. I hate laptop mice
Me (7:46:10 PM): err.... trackballs
Vizzini (7:46:18 PM): it's a touchpad on this one
Me (7:46:23 PM): *nods*
Vizzini (7:46:34 PM): sony vaio
Me (7:46:39 PM): heh
Me (7:47:18 PM): yeah, getting the PNG writer to work was fun at first..... until I had the brilliant idea of swiping GIMP's source and looking at its PNG plugin
Vizzini (7:47:36 PM): ah yes - nice one
Me (7:47:38 PM): to see wtf it did for the api calls
Vizzini (7:47:44 PM): why re-invent the wheel
Me (7:47:59 PM): to make it out of a different material!
Vizzini (7:48:05 PM): the sign of a good coder. i think i'm going to enjoy working with you =)
Me (7:48:12 PM): *cackles*
Me (7:48:34 PM): ;.; damn ... I just realized.... after next sunday.. I'll have two years til I'm 30
Me (7:48:51 PM): *feels old suddenly*
Vizzini (7:49:03 PM): fucksake - i'm 34 next year
Vizzini (7:49:07 PM): thanks for reminding me
Me (7:49:08 PM): heh
Vizzini (7:49:34 PM): man i gotta get some serious amounts of sex in in the next 6 or so years
Vizzini (7:49:53 PM): after that it's too gross to think about
Me (7:49:53 PM): my oldest cousin is 46!
Me (7:50:18 PM): he was 18 when I was born *is the youngest*
Me (7:50:43 PM): well, around 18
Me (7:50:48 PM): I forget!
Me (7:50:52 PM): he may be 45
Me (7:50:55 PM): who knows!
Vizzini (7:51:08 PM): right fuck it. i'm gonna nip down to the garage for smokes. you bad influence you.
Me (7:51:15 PM): actually
Vizzini (7:51:17 PM): i'll be like 5 mins - you gonna be here?
Me (7:51:20 PM): k
Vizzini (7:51:35 PM): actually what - you gonna go mary poppins on my ass now?
Me (7:51:54 PM): depends on what woman you're with.... there are some damn fine sexy 40 somethings out there!
Vizzini (7:52:03 PM): oh right
Vizzini (7:52:04 PM): lol
Vizzini (7:52:15 PM): yeah but how much of it is fake man
Vizzini (7:52:20 PM): think about it
Vizzini (7:52:22 PM): brb
Me (7:52:31 PM): does it matter?!
Me (8:03:55 PM): :D you're gonna kill me for this
Me (8:03:57 PM): bbl!
Vizzini (8:06:56 PM): ok
Me (8:24:00 PM): back
Vizzini (8:24:15 PM): ello
Vizzini (8:24:37 PM): just sorting char_from_room, then got do_look to rewrite
Me (8:24:42 PM): *nods*
Vizzini (8:25:01 PM): i'm a bit fucked off actually
Vizzini (8:25:17 PM): i asked for another testport to be opened up on the sent box, so i could run a second testport
Vizzini (8:25:31 PM): and the admins started giving me static about it
Vizzini (8:26:37 PM): i thought they were cool. wtf?
Me (8:31:44 PM): O.o
Me (8:32:15 PM): which admins?
Vizzini (8:32:46 PM): Jamie = Soupboy?
Vizzini (8:33:24 PM): Dunno - started talkin bout ways to crash the server using code... bleh
Vizzini (8:33:35 PM): maybe i'm being oversensitive, but it was a bit off
Vizzini (8:36:43 PM): you can't accept files... oh ok
Me (8:42:44 PM): I'm behind a proxy
Vizzini (8:42:57 PM): s'ok - no big deal
Me (8:43:05 PM): yeah .... that's what gmail is for!
Vizzini (8:43:29 PM): s'alright - i'm just being a big girl about it
Me (8:43:40 PM): ... girl?
Me (8:44:05 PM): *peers* you have anything you wish to tell me? *peers*
Vizzini (8:44:15 PM): no - it's just an expression
Me (8:44:18 PM): heh
Vizzini (8:44:44 PM): man that would shock you all if i turned out to be a girl after all these years lol
Me (8:45:30 PM): yeah, an interesting twist of fate
Me (8:46:13 PM): all these years I thought you were that drab geeky guy and you turned out to a hot, sexy buxom blonde
Vizzini (8:46:43 PM): rofl
Vizzini (8:46:46 PM): if only
Vizzini (8:46:57 PM): nope - just a drab geeky guy
Me (8:53:16 PM): hrm... I wonder...
Me (8:53:45 PM): would it be possible to have adaptive tile names?
Me (8:53:59 PM): based upon what is around it
Vizzini (8:54:01 PM): what do you mean
Me (8:54:04 PM): like
Me (8:54:11 PM): a sand tile
Vizzini (8:54:16 PM): char_from_room done
Vizzini (8:54:22 PM): ok
Me (8:56:10 PM): completely surrounded by water and itself.... it could be called "A Sandbar"... but if it's next to say... grass it would be a beach
Vizzini (8:56:31 PM): yeah i could code that
Me (8:56:39 PM): though it would be tricky
Vizzini (8:56:44 PM): naw
Vizzini (8:56:58 PM): we just do a check as to what the adjacent terrain is
Me (8:57:11 PM): well, say you have a five pixel wide span of beach?
Me (8:57:45 PM): it would need to be somewhat intelligent to do that
Vizzini (8:58:08 PM): well we'd consider each pixel as the centre of a 3x3 square
Me (8:58:21 PM): *nods*
Vizzini (8:58:35 PM): if the pixel is surrounded on at least 6 of the adjacent squares by water, it's a sand bar
Vizzini (8:58:47 PM): or something like that
Me (8:58:50 PM): something like this though could be used to alleviate the need for making special terrain tiles
Me (8:59:03 PM): that are not named
Vizzini (8:59:07 PM): well yeah that's an interesting idea
Me (8:59:44 PM): and if the sand is surrounded completely by enough non-sand land tiles... it would be a sand dune
Vizzini (8:59:51 PM): perhaps it would be easier if there was the height above sealevel thing
Me (9:00:04 PM): well, general elevation
Vizzini (9:00:12 PM): as in, if the squares around are not only water, but -1 sea level
Me (9:00:36 PM): I don't want absolute above sealevel... I want an absolute elevation.... from the ocean floor
Vizzini (9:01:10 PM): yeah but if you do that, where do you measure from?
Vizzini (9:01:25 PM): the ocean floor will be at different heights in different places
Me (9:01:30 PM): one unit below the lowest level
Me (9:01:42 PM): or THE lowest level
Me (9:02:01 PM): or have a normal sealevel "0"
Vizzini (9:02:04 PM): the water will always be at the same level, and if we measure from sea level, we can modify sea level to cause flooding
Me (9:02:06 PM): and have negative elevation
Vizzini (9:02:12 PM): yes
Vizzini (9:02:17 PM): sealevel is 0
Vizzini (9:02:21 PM): normally
Me (9:02:35 PM): except when you take into account tides :D
Vizzini (9:02:53 PM): -100 is below sea level, but depending on where it is, it doesn't mean its underwater
Vizzini (9:03:04 PM): but it does mean that if you connect it to the sea, it'll flood
Vizzini (9:03:15 PM): dams, etc
Me (9:03:19 PM): *nods*
Vizzini (9:03:27 PM): so i can flood an entire area by blowing a dam
Me (9:03:34 PM): 8)
Vizzini (9:03:41 PM): or tsunami's etc
Me (9:03:53 PM): exactly
Vizzini (9:04:03 PM): make areas accessable at low tide, inaccessable at high tide etc
Me (9:04:41 PM): yeah, and with the tidal function I provided (albeit, likely highly simplified) ... that would be computable :D
Vizzini (9:06:01 PM): have i seen that?
Me (9:06:10 PM): it's in the coding forum :P
Vizzini (9:06:28 PM): ah ok
Me (9:06:29 PM): been there for over a month
Vizzini (9:06:34 PM): i've been a little preoccupied
Vizzini (9:06:56 PM): prolly read it and went, oh wow that looks nice, and went back to this mess
Me (9:07:04 PM): heh
Me (9:07:31 PM): I still want to see about having the UNDERWATER part of the wilds part of the map and not HAVE ocean tiles
Me (9:08:07 PM): which will require having an elevation map
Vizzini (9:08:13 PM): yes
Vizzini (9:08:20 PM): i suppose we should start looking at that
Me (9:08:26 PM): *nods*
Me (9:08:34 PM): hrm
Vizzini (9:08:40 PM): how will you reflect elevation on your util?
Me (9:08:48 PM): not sure
Me (9:08:59 PM): I guess we need to figure out what kind of range we want
Vizzini (9:09:00 PM): hues of blue?
Vizzini (9:09:42 PM): or you could go for a contour map - but that would be complex to calculate i guess
Vizzini (9:10:12 PM): in effect that's what we're going to end up with tho
Vizzini (9:10:48 PM): a steep drop will consist of adjacent rooms with a high delta in elevation
Me (9:15:38 PM): *nods*
Me (9:16:02 PM): well, what I meant was.... how LOW will the oceans be and how HIGH will the mountains be?
Me (9:16:45 PM): so we can decide what the elevation elements would have to be
Vizzini (9:17:04 PM): well there's the thing
Me (9:17:11 PM): yeah :P
Vizzini (9:17:17 PM): we know that sea level will be 0
Me (9:17:31 PM): I mean, will we have Everest mountains?
Vizzini (9:17:34 PM): but we have to decide how high the mountains will be, relative to that value
Me (9:17:44 PM): will we have Challenger Deep channels?
Vizzini (9:17:44 PM): well i'd like to
Vizzini (9:18:30 PM): i want to implement falling/floating/flying at some point, and that will rely on the HAS of all these terrain features
Me (9:18:34 PM): we don't need SUPER high detail elevation
Vizzini (9:18:39 PM): HAS = height above sealevel
Vizzini (9:18:59 PM): well i spose it depends on how big you want the wilds to be eventually
Vizzini (9:19:02 PM): we can work up to it
Me (9:19:04 PM): *nods*
Vizzini (9:19:21 PM): gradual resizing of the wilds. let's just call this phase 2
Me (9:19:26 PM): well, it also depends on what the file format
Me (9:19:36 PM): is ^
Me (9:19:58 PM): binary format would be simple to deal with say... 16-bit values
Me (9:20:08 PM): but ASCII?
Vizzini (9:20:17 PM): yeah, we will prolly have to go binary at some point
Vizzini (9:20:30 PM): right now tho, we're just building the framework
Me (9:20:36 PM): yeah
Vizzini (9:20:47 PM): but yeah - we're on the same page i think
Me (9:20:53 PM): hell.... ha... could just have a 16-bit tile and a 16-bit elevation
Me (9:21:01 PM): stored as an RGBA png
Me (9:21:17 PM): and use a standard PNG loader
Vizzini (9:21:28 PM): we might need two - one for terrain type and one for terrain heights
Me (9:21:49 PM): you mean like a section of forest.... have the height of the trees?
Me (9:22:27 PM): hell, can just use the PNG writer and WRITE the file out
Me (9:22:35 PM): when needed
Vizzini (9:22:56 PM): well your picture format can only store one piece of detail per pixel
Me (9:23:10 PM): not really!
Vizzini (9:23:13 PM): but we need to know what the terrain type at that pixel is, and also the height
Me (9:23:23 PM): 32 bits is 4 billion values
Me (9:23:51 PM): splitting to two 16-bit groups... that's 64k each
Me (9:24:09 PM): what the numbers are to USE is irrelevant
Me (9:24:12 PM): US ^
Vizzini (9:24:27 PM): ah yes - i suppose you could use your util to split out the bit values
Me (9:24:30 PM): and I'm refering to an image file YOU can load up
Vizzini (9:24:37 PM): use the high range for height and the low range for terrain
Me (9:25:14 PM): like GREEN<<8+RED for terrain index... and ALPHA<<8+BLUE for elevation
Vizzini (9:25:31 PM): nods
Me (9:25:54 PM): and PNG loaders are not that hard to use.... I use it!
Vizzini (9:26:07 PM): if we use hex, 0000000000000000 to 00000000FFFFFFFF for terrain type
Me (9:26:21 PM): well, more like
Me (9:26:28 PM): 00000000 to 0000FFFF
Vizzini (9:26:30 PM): 000000001FFFFFFF to FFFFFFFFFFFFFFFF
Me (9:26:34 PM): 32-bits :P
Me (9:26:44 PM): not 64-bits
Vizzini (9:26:52 PM): ah sorry
Vizzini (9:26:54 PM): yes
Me (9:26:57 PM): heh
Vizzini (9:27:02 PM): i think in longs =p
Me (9:27:09 PM): 8)
Vizzini (9:27:14 PM): but you know what i mean
Me (9:27:22 PM): yeah
Me (9:27:46 PM): and you'd still need 4*W*H memory to hold all that
Vizzini (9:27:55 PM): if we assume that these are unsigned integers, that gives us the full 16 bits for each type
Me (9:28:05 PM): a 6000 x 6000 -> 144Meg
Vizzini (9:28:19 PM): yeah but it's still less that the 300 meg we're using right now
Me (9:28:23 PM): yeah
Vizzini (9:28:31 PM): so we're still winning
Me (9:28:34 PM): and you can add another 50% for your affects
Vizzini (9:28:40 PM): and look how much more that would give us to work with
Me (9:28:46 PM): yeah
Vizzini (9:28:54 PM): by that point i might have worked out a compression system
Vizzini (9:28:54 PM): or
Me (9:28:59 PM): *nods*
Vizzini (9:28:59 PM): sectorized loading
Me (9:29:04 PM): yeah
Me (9:29:16 PM): and abusing locality :P
Vizzini (9:29:27 PM): ?
Me (9:29:40 PM): you don't need the map info from 0,0 when no one is even NEAR it
Vizzini (9:29:47 PM): ah yes
Vizzini (9:29:50 PM): that's what i meant
Vizzini (9:30:00 PM): only loading the occupied sectors
Me (9:30:06 PM): *nods*
Vizzini (9:30:27 PM): anyhow - it's definately time for bed now
Vizzini (9:30:29 PM): 3:30am
Me (9:30:31 PM): hah
Vizzini (9:30:32 PM): up at 7
Me (9:30:35 PM): *so bad*
Vizzini (9:30:56 PM): gotta draw the line somewhere. mud coding doesn't pay the bills =)_
Me (9:31:13 PM): heh
Vizzini (9:31:19 PM): don't get me wrong - if i could i'd just stay up all night. made some serious progress tonight
Vizzini (9:31:31 PM): can you paste all this into the wilds thread?
Me (9:31:37 PM): *nods*
Vizzini (9:31:38 PM): we talked about some good stuff
Vizzini (9:31:54 PM): and at least some of it is actually doable lol
Me (9:32:00 PM): *nods*
Vizzini (9:32:22 PM): do you rekon you could have a think about the elevation representation thing tho?
Me (9:32:36 PM): hrm
Me (9:32:52 PM): well, I'd use a seperate image for that stuff
Vizzini (9:32:54 PM): try and flesh it out a bit
Me (9:33:22 PM): as far as my constructing it
Me (9:33:59 PM): hell, we could get rid of impassable terrain 8)
Me (9:34:19 PM): anywho... night!
Vizzini (9:34:37 PM): nods
Vizzini (9:34:40 PM): nite =)
-
I'm 22 going on 40\. It's all about how young you feel :D
-
Ok, testport2 is now up on the mud server for those not aware of it. The port is 7000, although only a small number of imms have their pfiles transferred onto it, so if yours isn't there you may need an imp with shell access to set you up.
Wilds v2 core code is there, although this is still a very heavy work in progress. Lots of things will crash it, but don't worry too much about that - it should bounce back up within a few seconds.
UPDATE:
I've had to move into a hotel until I go home on Friday this week - I'll be off the net until then (they only provide net access to those who enjoy consentual rape by credit card companies). I'll continue to work on bug fixes and further code-integration until then, hopefully with a decent update on Friday/Saturday.
Vizz.
