-
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.
-
Offline fixes:
* Fixed do_where() crash bug. This is to do with the legacy use of the in_room->parent pointer all over the place for the old wilds. I'll strip them all out.
* Fixed wilds exits not being correctly loaded with their destination details.
* Fixed vlinks being displayed in the wrong place on the map.
* Fixed do_exits() showing "none" in the wilds even when this was incorrect.
Vizz.
-
Awesome work! 8)
-
More progress.
* Fixed Vlinks finally. Seems I got confused and introduced some really dumb-ass logic into the linking code. Sorted. Only outstanding thing with vlinks is to link all of the reverse sides of vlinks to their wilds *AFTER* all the areas have been loaded. Right now, you can't start in Plith say, and walk out the east gate and into the wilds. The reverse link isn't there. I'll do that in the next night or two - not major.
* Had to realign the coordinates of all the entrances in the wilds. This follows on from the previous point. A vlink's "location" is the vroom where the link exit actually exists, NOT where the "O" is placed on the vmap. That's dictated by which direction you choose for the vlink. It's kinda awkward to explain, but once you get using it no doubt you'll either love it or hate it - in which case I'll rewrite it the way you want. In any case, a new copy of sentwilds.are is now in the testport2 dir.
Next on the list is rewriting act_info.c, create_map() routine. Actually there's this one, and a couple of other related routines that will also need rewritten. This is partly because the existing code doesn't check its own pointers (so causing a crash when you walk into a city from the wilds, and a map+description is to be displayed in that room), but equally, since the vroom the char came from doesn't actually exist anymore the pRoom pointer is invalid. Another reason is that Areo asked me to reimplement it to support displaying diagonals as well.
Anyhow, work's real heavy right now, so I might not get to this till the weekend. Looks like a couple of days work for the rewrite of these routines.
Cheers,
Vizz.
-
Hey Vizz,
just a quick request. Wondering if you might be willing, at your convenience, to strike up a brief list of functions that you have completely redone, to make the merge easier. For example, I'm sure you have either completely reworked or planning to rework functions like create_wilderness_room() and create_map(). Since I know the wilderness is currently your big focus, I've stayed away from making any changes to functions like that, as well as to wilderness.c. It'll make it a little bit easier for me if I can just copy over your big blocks of wilderness-specific changes firset, so that I don't end up with as huge patch files. Using diff I can then merge in your smaller changes to functions such as those in act_info.c.
Excellent work so far!!
S.
-
Well no, actually I haven't changed them at all yet. I wanted to speak to you first, cos I remembered someone talking about consulting previous implementors of code about fundamental changes to them - might have been Areo actually. Anyhow, I should have made that clear in my post.
I do have to modify create_map() because right now it's unprepared for rooms that don't exist so it crashes. I planned to add a few checks to the existing code to avoid that. As far as the diagonals thing goes, if you're happy for me to do it I will - if you'd rather I focused on the wilds for now, or want to do it yourself that's entirely cool with me.
On your other point, I've been marking the majority (sorry - I forget sometimes) of amendments I've made with a tag in the code of /* VIZZWILDS */ to make a nice simple grep easier. If that helps you then cool, but I suspect that a diff will be the only way to get all the little changes. If you want I can mail you a copy of the testport2 code so far so you can get some idea of where i am and how much has had to change, but there's still a lot to do, especially in the olc.
Cheers,
Vizz.
-
Right - got the vlinks 100% now. New version is now up on testport2 so please see if you can crash it. If you do (I don't doubt it), please write a note in here about it and I'll fix it.
I'm not going to tackle mobs and objects in the wilds yet. With the core code at least in a running condition, I want to get the netherworld wilds sorted out and implement a couple of things Nib and I have been talking about, like configurable vlink entrance chars, altitudes and a couple of other things, then get the netherworld wilds converted. After that I'll start removing the old wilds code I've commented out and reinsert a few things that had to be disabled, including the wilds darkness fog view.
Let me know if you have any immediate requests. I'll monitor this thread as much as possible and work on the code as much as possible over the next week. Hopefully I'll have internet access from my hotel next week so I'll be able to continue to make updates, but otherwise assume that my updates will only be at weekends.
I'm enjoying the hell out of this right now. It's all coming together slowly, but there's a load of testing to be done. Any volunteers? ;)
Cheers,
Scott (Vizz).
