Mar 10 2015, 8:07 pm
|
|
Nadrew
  |
The main issue with hosting using the old files is hub visibility, it's really, really hard to get people in when it doesn't pop up on the listing. The login html is a bit ugh too, but I can actually change that.
|
Nadrew wrote:
The main issue with hosting using the old files is hub visibility, it's really, really hard to get people in when it doesn't pop up on the listing. The login html is a bit ugh too, but I can actually change that. Is it possible to get the old files from somewhere? I don't need other people logged in to give myself a refresher | |
I'm not sure I'd be comfortable with even the legacy version being circulated. One of the reasons I haven't wanted it hosted is that it's a bit embarrassing in some ways.
| |
One of the reasons I haven't wanted it hosted is that it's a bit embarrassing in some ways. Ah, yes, the reason my games list is empty. Verbal self-harm and never being good enough for my own standards. I know that one. It's a shame, though. Genuinely, Lexy, it was one of the best experiences I've ever had on BYOND and I regret that I wasn't old enough to appreciate it as much as I very probably would now. | |
I'd be real interested in this!!!
| |
I'm posting development updates in the game forum http://www.byond.com/forum/Hedgemistress/HedgerowHall, for those who are interested.
Thanks, Ter13, for that list of resources. I never really understood how to use savefiles beyond the "cram an entire atom into a single buffer" level. Your posts about savefiles and what's going on when a new turf is created really helped streamline the burrow loading and saving. My first attempt worked, but it ground startup and shutdown to an embarrassingly long halt with just five or six of them in the world. Now I can load dozens with barely a hiccup. | |
I should thank you, actually. Burrow-saving is what led me to figure out how savefiles work in the first place. I've been trying and failing to rip you off for years. ;P
Also, if you haven't already, you might think about building a sort of queue system and tuning it in such a way that it saves over time and breaks periodically rather than capping out the world until it's done. Doing some manual testing to find the number of objects can be socked away into a savefile in a single frame and then using a percentage of that value to cap out your saving algorithm during runtime would probably save you some headaches in the long run. Also dynamically loading and unloading burrows based on who is online and who is not could also be of help to keep your world green. | |
Burrow-saving is also what led me to add lab-saving to console, each lab is basically its own /area and I just dump that area into a savefile and load it back as needed, using Read() and Write() to prevent things from saving/loading that shouldn't. It works rather well, and pretty speedy.
| |
Yeah, that's something I experimented with: horking areas into savefiles. I just didn't find it all that useful because you can't load a place in a different position than where you saved it. When it comes to something like burrows, it's probably best to not use an absolute coordinate for burrow locations in the loaded map, because BYOND has a soft-limit of about 200 million turfs (DD/DS crashes with out of memory errors when you hit 1000x1000x200 turfs in a blank project.)
I largely avoided socking away entire areas and instead did a block() iterator so that I could reinitialize turfs as a location I later would specify myself. | |
The original HRH never came near the turf limit, but since underground squares are on a different scale than the above ground and don't correspond literally with above ground coordinates, I still would rather be able to tessellate them into the world in a flexible way. Currently I can fit 400 burrows into a 1000x1000 z layer. It will add more on the fly as needed, but one should be plenty for most purposes.
Part of how the surface coordinates are saved even means I can change the size/order of the surface maps and it will still know where to put them. I'll lose some of the sardine-packing efficiency or people will lose a smidge of usable space if I decide to make the edge of the burrow anything other than black impenetrable void. Now that I'm talking about this, I think I might wall it off... even at 47 by 47 it would still be a smidge bigger than the classic burrows. And having a definite boundary that can be interacted with (the burrows on the outer edge just have the edge of the map) opens up some interesting possibilities for sideways exits. | |
Ter13 wrote:
Yeah, that's something I experimented with: horking areas into savefiles. I just didn't find it all that useful because you can't load a place in a different position than where you saved it. When it comes to something like burrows, it's probably best to not use an absolute coordinate for burrow locations in the loaded map, because BYOND has a soft-limit of about 200 million turfs (DD/DS crashes with out of memory errors when you hit 1000x1000x200 turfs in a blank project.) Yeah, I never intended to move any labs around on console so I never really worried about that, but I did have a tool that allowed me to move the area at runtime and save it in a new location after loading it into the old one -- if I needed it (never did). | |