-
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).
-
List of special effects to consider when we can do eye candy (but plan for stuff like this NOW)
* colored " marks for certain mobs with eyes like that when in darkness but within line of sight.
* O room shield indicators (maybe circles when they are/can be larger)
* yellow/red tiles for showing fires with different characters for size of the fire.
* momentary darkness affects causing darkened or blank(black) tiles to show up.
All so far… more to come!
Also... spells that affect nearby rooms (directly or indirectly)
* wither - creates objects in adjacent rooms and can cause fleeing
* fire cloud - creates objects in adjacent rooms and can cause fleeing
* inferno - can cause fleeing
* room shield - blocks entry for PKers into the room
* afterburn - ranged spell
-
Some stuff that I can think of:
* Ranged code in shoot.c, specifically the function which locates the victim (search_dir_name). Since this used by do_shoot and do_throw, fixing it to account for virtual rooms should fix anything having to do with ranged. Since it's the wilds, we can use a coordinates for this which would be faster than recursively searching rooms. Perhaps since it's wide open space, we can allow people to shoot within a distance radius (e.g. you can shoot someone 3 rooms east and 1 room north, as long as there's nothing blocking them).
* We might re-enable hunting in the wilds through a similar algorithm. Currently it just doesn't allow you to hunt in the wilds because, once again, the recursion used won't fly for the vast space which is our wilderness. However, deriving a direction from coordinates of hunter and huntee will solve the performance issue.
Thanks for keeping your changes tagged, that's gonna help a lot. Don't worry if you've missed some of them - the diff will pick up whatever you didn't tag.
-
On the off-chance that anyone actually checks this forum anytime in the next couple of hours, I have a request.
I don't have unfiltered access to the internet from work, and I'm working on the wilds code (heh). I need someone to log into the main game, hop into the nether wilds and take a screenshot while standing 1 east of the portal back to rune. The screenshot must be in colour, and of a decent resolution that I will be able to make out the terrain features.
Just post the screenshot as an attachment in this thread - ty.
If ya can do this, great - otherwise I'll park this and work on it again tonight.
Cheers!!
Scott.
-
~~@Vizzini:~~
> On the off-chance that anyone actually checks this forum anytime in the next couple of hours, I have a request.
>
> I don't have unfiltered access to the internet from work, and I'm working on the wilds code (heh). I need someone to log into the main game, hop into the nether wilds and take a screenshot while standing 1 east of the portal back to **rune**.
:lol:
That and Gza cpking himself by attacking my linkdead ghost remind me of the pure hilarity that insues around here sometimes. It really makes the hard work worth it :D
-
LOL.
Oh man I'll have to tease him about that!
Thanks for the screenshot. This was needed because as with the "Wilderness", "Nether" had some terrain types in the code that didn't correspond to tiles in the area file, and the area file had some tiles that for some weird reason didn't correspond to tiles in the code… Go figure. All sorted now tho, so thanks!
One more question - I'm sure Nib kinda answered this the other night, but I wondered if anyone else knew what the actual state of play with it was. What's happening about the "Eden" wilds? I see numerous references to it in the code *grumble*. I'm assuming it doesn't exist right now? If not, then it's one less wilds file to manually convert.
Cheers,
Scott.
-
BTW, if you hit ALT-Print Scrn, it'll just make a capture of the highlighted window, instead of your entire desktop.
Useful for when you don't want to show people what music you were listening to at the time ;)
If you knew that already, you can cuff me upside the head next time you see me online.
Scott.
-
Oh yeah, ages ago I had this idea to replace the dumbass crap starfield at the boundaries of the wilds with something a little more attactive. I figured we could use something similar to a brush array - a 2d array of stars so arranged as to lend itself to being repeated at some point end to end, giving the impression of a seamless starfield - except customisable.
If we consider this in the context of Nib's idea about having red-quotes symbolising malevolent eyes in the darkness, we could use the brush array to do something similar with that - although with the Nether the way it is right now, noone would ever even see the boundaries…
Another method would be to allow some or all wilds to be spherical in nature. Thoughts?
Scott.
-
~~@Vizzini:~~
> One more question - I'm sure Nib kinda answered this the other night, but I wondered if anyone else knew what the actual state of play with it was. What's happening about the "Eden" wilds? I see numerous references to it in the code *grumble*. I'm assuming it doesn't exist right now? If not, then it's one less wilds file to manually convert.
It does exist, it was created as the counterpart of the abyss. Seems to make sense, except there arn't any areas to put in it. Therefore it's not usually loaded into the game – i believe the code to load it is there.
You can see the map in the main port's /area/eden.are. You don't have to convert it if you don't want to - I mean I always liked the map, but it is a bit simplistic. If it's a giant pain for you to convert it, don't. I'm sure we can make a better eden.
> BTW, if you hit ALT-Print Scrn, it'll just make a capture of the highlighted window, instead of your entire desktop.
>
> Useful for when you don't want to show people what music you were listening to at the time Wink
Didn't know that actually. Not that i'm ashamed of listening to lil jon.
> Oh yeah, ages ago I had this idea to replace the dumbass crap starfield at the boundaries of the wilds with something a little more attactive. I figured we could use something similar to a brush array - a 2d array of stars so arranged as to lend itself to being repeated at some point end to end, giving the impression of a seamless starfield - except customisable.
>
> If we consider this in the context of Nib's idea about having red-quotes symbolising malevolent eyes in the darkness, we could use the brush array to do something similar with that - although with the Nether the way it is right now, noone would ever even see the boundaries…
>
> Another method would be to allow some or all wilds to be spherical in nature. Thoughts?
I think the flat-earth concept deserves to be tortured to death and burned at the stake. I would really like a spherical world. Or at least an elliptical one. Or an asteroid. We should move out of this whole turtles-stacked-up-on-top-of-eachother worldview where we have no sense of space.
Since the concept of a more.. uhh.. real world, or planet at the least, surpasses the need for that starfield where the world ends, I think we can just do away with it if you're willing to do the implementation 8)
-
I would rather it be more of a cylindrical world with the polar regions covered in ice, unless you want to deal with the problems of MOVING around the north and south edges. Remember… if you use a spherical map, the longitudes get closer together the closer you get to the poles, thus all the land gets STRETCHED when put on a rectangular map. Not only that, you have contend with moving THROUGH the polar edge. If crossing it means you cross the pole, you don't appear on the opposite side of the map (north to south, or vice versa). No, you would appear half the map width to the side (east/west, doesn't matter) ... and facing the OPPOSITE direction. Doing the standard "North" at the north side of the map would put you in an endless swapping between two locations. Ships would have to switch directions to keep going the "same" direction.
With a cylindrical map, you could make two polar wilds, use them as a cap and then use special boundary vlinks to take you to the proper location on the polar map.
This brings up another interesting though about the wilds in general. This stemmed from using the boundary vlinks. Well, why not have a bounding box vlink that you could anchor over one vmap and then have it link to another complete vmap. The coordinates are used to put you in the right location in another region of the zoomed in map. For example, you could have the topmost level of the wilderness. Around a particular region of the map, say Seralia, you could have a box vlink connect that region to a larger, more DETAILED map.
Of course this might screw up the simplicity of hunting in the wilds and other things. Just something to consider.
-
Hey all,
Been a while since I posted any kind of progress update, so I guess I'd better write one. For those who don't know, I have my own company and the end of the financial year is looming (31st March), and I have a large tax bill to meet so I've been working my ass off. The wilds work has suffered as a result so there's not a massive amount to report.
* Rewrote the Terrain and Vlinks loading/saving routines to use Syn's value tags method rather than the stock ROM lazy-man's method of using absolute fixed fields. This is much more fault tolerant and makes the area files bigger, but much more readable. It also keeps the wilds files in roughly the same format as the rest of the area file format, which makes me more comfortable (and will save me lots of explaining time when Nib comes to rewrite PGN2ARE).
* Spent some time bullet-proofing various parts of the wilds OLC. Again, a lot of testing will still be required but I wanted to head-off some of the dumber and more obvious bugs before beta testing begins in earnest.
* Vlinks can be linked/unlinked from the OLC now. I wasn't happy with the way this had been done previously, so I rewrote the linking and unlinking routines so that they are more compartmentalised, so the code can be reused when it comes to putting in script hooks for allowing room/mob/obj scripts to link/unlink vlinks.
* At Nib's request I made vlink wilds entrance tiles customisable in the OLC, and also modified the loading/saving code appropriately.
I'll try to do more in the coming week. I realise you guys are waiting for this.
Cheers,
Scott.
