The Plum Gate

Time flies - I haven't actually played one of my own maps yet because of, honestly, a bit of burn out and I play at slow pace so, the ( let me stop myself there). In fact, I didn't even realize that there was an impending update because of work related things. I'm not sure I understand the quoted reference - are you still trying to push standard POI's away from the starting biome? If so there might be some avoid radius parameters that might be more effective. I'll have to take a look at new RWG files - this is always interesting to pick back up; this time they've added a new biome all together - which means they may have changed the way RWG worked. I VI'd the game files, and once again, only 2 came back as needing replacement. I will have to check the integrity of the mod against these new changes and diff the old files with the ones I have in my own archive. Could you send my a link to that mod you mentioned, I can't seem to find it on Steam.

Bumping for the sake of mentioning that the geyser feature that creates random geysers uses a single template - I'm hoping that we could specify this template in temperature relevant manner. Ie, template inherits biome temperature would fall into the idea above.

Eww, sounds like new material. Previously you would just duplicate their entry in the abc fields.. but now it sounds like they're moving geyser balance into rwg AI and out of yaml. @Winternewt, I've updated the the mod, and thanks for pointing that line out, it's how the random geysers spawn, and I don't like it, it's not at all targetable. So it looks like it was hacked into the RWG code. Looking back it's a sort of revisit of how geysers spawned to begin with, except they're using the POI system. There are geysers everywhere again..

Yes, thank you, and I do ( see the previous post). But I'm strapped for time lately - perhaps later this week I'll dive back in. The game has gone through some changes recently, So I'll have to reexamine the POIs and there again, just look at RWG in it's vanilla form both as it generates worlds and handles any new POIs, but also how it handles the diversity of POIs. The problem I ran into with larger maps was that the original intent of the mod was to push relevant geysers in towards the starting biome, and this works 90% of the time when working with maps at the 256x384 tile sized. The much larger maps (448x448, 512x512) started presenting unusual effects regarding the manner in which relativistically placed biomes were being spawned in. I wasn't happy with the consistency such that I felt like players could just jump in blind without seed previewing and the mod would work as intended. There was just to much inconsistency regarding intent vs results and POIs were behaving in non intuitive ( to the RWG coding ) manners. In other words, there were still some things I didn't quite understand about the primary files regarding biome placement. That's ultimately the goal (understanding that), so I'll have some hammering to do on my own worldgen code to ge that to work. I'd like to maybe be a bit more original in the world map names as well, because '221' might not even be relevant anymore considering that diversity of geysers now in the game. I'll have to look at this with a fresh install and compare it to my existing code. I can't wait to get back on this ( but I have to ). I've got some good ideas regarding larger maps, but I want to make sure I understand the nature of Kei's use of the noise libraries (low priority), biome placement ( high priority ), as well as address some issues I was having with code duplicity (somewhat already addressed using shared biome definitions ) - but I took extensive notes while I was working, so it shouldn't be difficult to update.

Just a quick note on this mod - is incompatible with the current build ( both ranching builds actually ) however I don't know what they changed behind the scenes, if anything - I'll be looking at revamping this mod for the current ranching update soonish - I've been away from ONI again these past couple of upgrade cycles. However that said; I did verify the integrity of my current installation and only ONE file failed the verification, so it stands to reason that my mod should still work as originally intended - this simply means the creature inclusions and additional POIs would really be the only thing I need to look at as far as making adjustments to the mod.

Yea, this is still an issue, but I don't think trying to bump the topic will do any good - don't think the bug forum works like that.

Making them different subzone types should cause abyssalite to draw between them. It's usually at the bottom of the zonefiles.

Yes, maybe a better explanation and examples?

Connecting power transformers in this obscure manner may highlight some sort of rounding error. The power used by the last transformer connected into the circuit started using power incrementally slow, then later maxed out at 5Kw. This creep up to 5Kw occured when there were potential loads on the circuit. After severing the lines to the loads, and reconnecting just the transformers as they are, the power consumption jumped to 5kw on one transformer immediately. I don't know what the intended behaviour of such a circuit is supposed to be - save to act as a sort of two-way bypass or zener diode. The bug here is that it's not actually using power from the batteries, but reporting a high power consumption on the line. - there's some intense power looping going on between the transformers causing line damage everywhere. Please note this was just an experiment.

It also transfers the slimlung to the clay it spits out. Technically, some germs are killed in the disproportionate o2 conversion - but they're doomed afterwards anyway.

Or they could hand it off to another passing dupe - sharing is caring.

I like a pattern where low end ingredients can and should span multiple teirs of food. Our current system and many prior iterations have always paired difficult to grow foods with high end recipes. I think they should all bare the burden of resource use and environmental requisites but not be so resource demanding ( unless we choose to use farmers ). I also think each edible ( save for nutrient bars and muck root and anything like mush bars ) should be used in at least three recipes. This would add more recipes but also allow increasing the numbers of food items in each expectation category. While easing the resource burden on growing the food would make vatiety a necessary but advantageous element to culinary outcomes. - What we have here with mushrooms is a one of two things: it either caters to players that involve themselves with playstyle which involve the slime biome, or the mushrooms are just ignored entirely - as dealing with slime just for the sake of low quality food is not enough of a reward without being incorporated in a higher quality food recipe.

Currently the features.yaml file is a strange instance of circular dependency when biome features otherwise specify their makeup internally in their current state. I have taken note that this method is somewhat future proof for features which have yet to be implemented and also provides a failsafe when unknown cells may remain present during world generation. Or whatever the case may be for using it. After modding world gen I may have found a more direct method of controlling features themselves, as well as a tie-in with the central features, including controlling feature-internal mob spawning - the idea is inheritance and granularity on sub-biome features rather than sub-world global features ( in combination would be possible the same way that duplicate feature entries are already used ). Here is an original, but simplified version of existing subworld YAML code at the heart of the suggestion for others reading along: names: [name] zone: # ... centralFeature: type: [path]/[filename] # no yaml extension needed #(ex: type: features/jungle/SmallRoom ) features: type: [path]/[filename] # no yaml extension needed #(ex: type: features/jungle/SmallRoom ) biomes: - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)] #(ex: biomes/Jungle/Toxic) weight: [number] # (- strength relative to other biome entries) tags: - [mob_id] - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)] weight: [number] # (- strength relative to other biome entries) tags: - [mob_id] # creatures or spawnable objects from mobs.yaml #... Here is an example using inheritance - simply a matter of moving where a feature is called from. There are comments in the code itself explaining the rationale for the idea. But the general idea is that a features.yaml lookup would not be needed if the feature inherits the biome terrain data it's already being called from. Please note that this is not currently the case nor how it works. names: [name] zone: # ... biomes: - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)] #(ex: biomes/Jungle/Toxic) weight: [number] # (- strength relative to other biome entries) features: type: [path]/[filename] # impled tags: - frequency: [number] - [other tags] type: [path]/[filename] # since most, if not all, current features specify their internal structure and make up, # refenceing them here would rememdy any need for referencing features.yaml as a defualt - # the feature inherits the sub biome from which it was called into existance. # implied tags: - frequency: [number] # [ 0, null, or not set ] would imply random distribution. # [ 1 would imply a single instance, and replace the centralFeature instance ] # [ greater than 1 would enumerate the features of this particular type per sub biome instance ] # this would also allow more granularity on the frequency of feature-internal spawning while... - [other tags] tags: # ...global spawns for the sub biome are controlled here. - [mob_id] # this would also allow more than one central feature per subworld. Or multiple single instances of features. # therefore there could be both primary and generic features for each subworld - this allows distinct placement within sub biomes. # ... - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)] weight: [number] # (- strength relative to other biome entries) features: type: [path]/[filename] # ex: type: [path]/[filename] # ex: - frequency: 1 type: [path]/[filename] # ex: - frequency: 3 - SpawnOnce # This feature only appear three times in the world, and only in this sub biome of this subworld. tags: - [mob_id] # creatures or spawnable objects from mobs.yaml #... I added "tags:" to features such that the central feature could be wrapped into the same type of feature instantiation and thus not be at issue - this would allow fine tuned spawning of features and thus internal spawns would be easier to predict. [other tags] on features could simply be activated inside the features files themselves, or switches could be thrown such that they act like a point of interest. For example -SpawnOnce, where a single instance of the feature exists in the whole of the world generated - a rare feature which isn't a template/point of interest and thus retains elements of randomness.

Yes, If you're looking at my mods, then to do that you would just invert or swap the _main and _atdistance biomes in the world definition file. But like I mentioned, this placement mechanism isn't perfect to begin with. And sorry for the delayed response - I must have been replying when you posted earlier.

I think it's entirely possible to package it like that, and the method sounds good. There are only two sore spots when it comes to world gen. That is: feature definition files have to be be in some subdirectory of or in the features folder - and then the features have to referenced or given context in the features.yaml file. Any other method of modding biome features breaks worldgen. I tried moving my modified features into the main folder structure and this does not work - that folder is apparently a hard coded location ( there are others as well, but they mostly worked with files, such as layers.yaml ) so modding those may be another issue entirely. Another thing I learned was that I could run my worldgen from the Mods folder! So the ditectory I put in the worlds folder would have been put in the Mods folder. But still had to have the world map file(s) in the worlds directory... So with those two location options, I settled on having the bulk of all the definitions in a subfolder under 'worlds'... and dealt with features the same way. Though, in hindsight I could have just put it all in folder under features ... but I digress. If I had not needed to, or had not made any changes to any of the biome features, then all of the issues regarding biome features wouldn't have cause for changes to features.yaml, nor a need for a subfolder in the features folder -- then world map files would have been placed in the worlds directory. And all the rest of it could be placed in a subdirectory there, or in the Mods folder itself. So anything involving modifying the yaml files directly in the worldgen folder ( not it's subdirectories ), could be other sore spots for having mods that get along well with one another.. I haven't looked at those in detail yet though. Edit: I think anything that would automate the tedium of repathing links inside those definition files would be useful.