• Announcements

    • JoeW

      [UPDATED] Physical Megapack Disc Issues   04/16/2018

      Update 5/11/2018 We do not have any more information at this time. The last we spoke to 505 indicated that the discs should be ready very soon. We will likely have more information next week; hopefully with full explanation of when and how to get new discs.    Updated: 4/27/2018

      On April 17th, the Don't Starve Megapack was released. Almost immediately, it was discovered that the wrong content was printed on the PS4 retail version of Don’t Starve Mega Pack (the Xbox One version is not affected). The disc contained Don't Starve Together, but was without Don't Starve, Reign of Giants and Shipwrecked. As soon as we confirmed the problem we contacted our retail publisher to find out how this happened and what could be done. It's taken some time to get this far, but this is all the information we have at this time. The current status of the issue is as follows: New copies are currently in print and will be on shelves ASAP, hopefully within a few weeks.  When the new discs arrive in stores, players who already purchased misprinted discs will be able to exchange the disc for a new one in store. Details will follow as we figure out the exact timing, the procedures with specific retailers and what the exchange will entail.  Players who already purchased the faulty disc previous to 4/26/2018 can now contact Klei support HERE for a Playstation Store voucher code that includes Don't Starve Together, Don't Starve, Shipwrecked and the Reign of Giants DLC that you can play now. Please specify your country as certain vouchers only work in certain regions.  New purchasers of the Megapack in store as of 4/26/2018 should be given a voucher at the time of purchase on your receipt. If you do not get a code, contact us ALL purchasers will have a path to get a new disc when they are ready. We do not have details at this time, but we are comitted to ensuring that all players get what they purchased.  We are hearing from some players that some retailers are telling players that they will not be exchanging discs. We believe this to be incorrect and that particular person or location is just misinformed. 505 has ensured us that they are doing their best to make sure these discs are being replaced for all players. We will not allow anybody to fall through the cracks here. We will buy and ship the discs ourselves if we have too.   This was our first major retail release and we're extremely disappointed that our players have been let down with their purchase of the Don't Starve Megapack. We're doing our best to make sure this issue gets resolved as quickly as possible. Thanks everybody for your support and patience. We'll keep you updated.    UPDATE: (4/26/2018) We are now ready to send out vouchers to players who purchased the physical version of the Don't Starve Megapack - These codes will allow players to download and play Don't Starve and DLC as well as Don't Starve Together To get a voucher players can contact as at our support site: http://support.kleientertainment.com/customer/portal/emails/new  For the subject, choose "PS4 Megapack" and fill in the form and we'll get you fixed up as soon as possible.  We will require a picture of your receipt, your Klei account ID and the region you are located in (so we can give you the proper voucher).  UPDATE: (4/24/2018) Earlier this week, we discovered that the wrong content was printed on the PS4 retail version of Don’t Starve Mega Pack (the Xbox One version is not affected). It’s a really unfortunate situation and we’ve been working hard with 505 to resolve this as soon as possible. Below is the latest information: New copies are currently in print and will be on shelves ASAP, hopefully within a few weeks. When the new discs arrive in stores, players who already purchased misprinted discs will be able to exchange the disc for a new one in store. Details will follow as we figure out the exact timing, the procedures with specific retailers and what the exchange will entail.  Players who already purchased the faulty disc will also be able to contact Klei support for a voucher code that includes Don't Starve, Shipwrecked and the Reign of Giants DLC until the new disc is ready. Please specify your country as certain vouchers only work in certain regions.  We will have more details when they become available including details on contacting us and what information we might need.  Once again, thanks to everybody for their patience while we work this out. For questions or concerns, the forum discussion can be found below:   

The Plum Gate

  • Content count

  • Joined

  • Last visited

Community Reputation

282 Excellent

1 Follower

About The Plum Gate

  • Rank
    Senior Member
  1. 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.
  2. 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.
  3. 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..
  4. 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.
  5. 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.
  6. 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.
  7. Mod: Big Freeze

    Making them different subzone types should cause abyssalite to draw between them. It's usually at the bottom of the zonefiles.
  8. [MOD][0.4] ONI-Modloader

    Yes, maybe a better explanation and examples?
  9. 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.
  10. [Game Update] - 256131

    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.
  11. [Game Update] - 256131

    Or they could hand it off to another passing dupe - sharing is caring.
  12. 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.
  13. 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.
  14. 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.
  15. 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.