You're welcome.

yes. Error was in the (Adaptive TPS) mode. I disabled it and now there are no more bugs. Thank you.

Are either of you using a save file compression/optimization or other garbage collection type mod?

Workaround: using minify everything and simple portals.

Menu -> General -> Development mode (shows debug icons at the top center)

Click the right most mask debug icon

Minify the exit box. (this should be instant, if not, it might be a mod or setting, i forget)

Unpause, and see it the pocket survives. if so...

delete the exit box (debug icon 3, type "des" and select "t: Destroy", left click the box, then right click to stop deleting)

place a simple portal outside and inside

use the "GetLinkCode" and "Link From KeyCode" buttons to pair the portals. (might have to enable them if you don't see them)

do not destroy the outer dimension box, but feel free to minify and move it inside the pocket.

It does not delete until i unpause.

Save System Corruption - Game throws NullReferenceException when saving/loading games containing Pocket Dimension structures,
When I reload, the measurement disappears. If I don't save, everything works fine.
Exception while saving KB_PocketDimensionBox37161: System.NullReferenceException: Object reference not set to an instance of an object
at Verse.GenCollection.RemoveWhere[T] (System.Collections.Generic.IList`1[T] list, System.Func`2[T,TResult] predicate)
at RimWorld.CompTransporter.PostExposeData ()
at KB_PocketDimension.Building_PocketDimensionBox.ExposeData ()

Im having the same issue has Cables323. I build the pocket dimension just fine, then i go to load the save, the pocket dimension gets deleted. My pocket dimension is on my gravship just fyi. But I ALWAYS had it on my gravship without any issues. idk why its doing it now

i think itys a bugs with cave collapses idk y its doing it

i'm having the same issue flying around if fine its after i went to bed and tried reloading the next morning nothing shows in dev log ether

Gravship will NOT cause this problem--it is safe to fly around on a gravship with a box--but I have not tested any other vehicle.

If you load and immediately pause, does it still collapse while paused? If not, maybe check all your pockets. Look for jobs that touch the dimension wall (I tried to eliminate the issue where replacing the dimension wall with something causes this, maybe I missed something). Also, check for the box outside the pocket as well. Did it get stolen? Is it loaded onto something that will take it out of the map? A caravan, a vehicle, a shuttle, etc?

Suddenly, and for seemingly no reason, the pocket dimension collapses 2 seconds after load. all auto saves are affected so it seams to be a false positive. any way to disable or find out what is triggering this? All it ways is "The entrance to the dimensional containment box has been lost along with its contents" nothing logged.

does anyone know if this works with DeepRim mod?

Let's goooooo

I can't say for sure--I haven't tested it--but my assumption is no. Something that transfers a colony/ship/possessions probably will transfer your pocket *entrance* but the problem is that the associated pocket is actually a unique map that was generated under the hood and is only superficially tied in code to your entrance and exit...meaning, unless the code doing the NewGame+ function knows how this works, it will probably not preserve the pocket itself, it will probably either give you a broken box or an uninitialized box with no pocket.

I know this is a long shot, but does anyone know if this mod is compatible with New Game+ mods like Save Our Ship 2 which allow you to generate new worlds while loading structures and pawn relationships from previous saves? Like, starting a new game would refresh all dimension maps if they even generate, right?

This mod had a vent on the entrance and exit of the pocket dimension. Try shutting the vent to stop temperature sync between inside and out and see if that makes any difference.

I'd like to report an issue. I'm using the MakaiTech mod. I generated a pocket map on the main map and installed a Sun Cradle in this pocket map, which keeps the temperature constant at 21°C. However, when the gravity ship on my main map flies to a new main map, the temperature of the main map drops to -273°C, and the temperature outside the map becomes -838°C.
Upon checking the save file code, I found this segment:
<def>Makai_SunCradleClimateControl</def>
<startTick>375370</startTick>
<duration>-1</duration>
<permanent>True</permanent>
<quest>null</quest>
<tempOffset>-1124.84082</tempOffset>
</li>
After I modified it to <tempOffset>0</tempOffset>, the temperature of the current map in my save file returned to normal.

Additionally, another mod named ShelterShuttle— which is also a mod that generates pocket dimensions— does not have this issue.

Interesting thank you!

oh jesus this mod is freaking insane!!!!

Sounds good. Thank you.

Seems to be fixed now. Loaded up my 370+ mod save with Dimensions RePocketed installed, did 10 RefugePodCrash events (6 were independents), and none caused errors. I'll do more extensive tests later tonight and report back if there's any further issues

@Gideon Initial tests with the new patch is working. I'm going to load up my save and test with the other 370+ mods and let you know.

As for your question, I did a test before patching and yes, it was only the Independent pawns that had the error, but again not all of them. Out of 10 pods, 6 were independent, and of those, 5 had errors and 1 didn't.

That null check fixed it for me. Patch is uploaded if you want to try it.

I'm testing this out on my side by changing

if(target.Faction.IsPlayer) return options

to instead be

if(target.Faction is not null)
if(target.Faction.IsPlayer) return options

@Kelven, I think I've noticed a pattern...can you confirm if this holds for you....trigger RefugeePodDrop x10 in debug mode....check each blue refugee (this will never be the case for red ones) to see if it belongs to "Independent space refugee" as the faction.

Does the error only occur on pawns that are independent? I have only been able to get the error to trigger on independent pawns so far...which leads me to suspect that the null might be if(target.Faction.IsPlayer)...IsPlayer can't be called if Faction is null, so this would trigger a null reference exception if independent refugees just have a faction set to null. I don't know for sure this is how independent refugees work, but it's the only difference I can find between "good pawns" and broken pawns.

@Gideon Ok, I did a dev test with the DLCs, Harmony (required), HugsLib (for the logging), and Dimensons RePocketed, and am still getting the error.

Error: https://pastebin.com/favAJzaZ
HugsLib Log: https://gist.github.com/HugsLibRecordKeeper/6d6d9e41e46f052ab1d3ea807ef22a05

Incase HugsLib was the culprit, I did another test with ONLY DLCs, Harmony (required), and Dimensons RePocketed, and am still getting the error.

Error: https://pastebin.com/4pZfrgWc
HugsLib: Can't provide since I removed it for this test lol

So ya, I'm getting the error with JUST the DLCs and this mod (and Harmony, which this mod lists as a requirement)

@Gideon I posted the error log without Achtung in my previous comment. So my very first comment has the error with Achtung and Dimensons RePocketed, and my most recent comment has the error with just Dimensons RePocketed.

I'll do the dev test right now, gimmie a few minutes and I'll post results

@Kelven, any chance you can do a dev quick test map with only Dimensions RePocketed and see if the event still has the issue? This will at least prove whether it's a mod conflict.

Also, if you reproduce without Achtung, do you still get an error logged and is it different?

@Jadabandon try this mod: https://steamcommunity.com/sharedfiles/filedetails/?id=3547933601

(Post 2/2)

So far have only found the RefugePodCrash causing the error. Out of 20 spawned RefugePodCrash events, 11 of the pawns caused the error when right-clicking them, 9 had no error. The error happened on random races, both from modded races and vanilla humans/xenotypes, so I don't see any pattern there.

I also tested:
- Spawning multiple caravans, no pawns had issues
- Spawning multiple ground raids, no pawns had issues
- Spawning multiple dropped raids, no pawns had issues

So it looks like it's specifically the RefugePodCrash event that is having an issue, but again only around 50% of the time.

More testing: Decided to test with only Achtung, and then with only Dimensons RePocketed:
- RefugePodCrash x 20 with Dimensons RePocketed removed, no errors
- RefugePodCrash x 20 with Achtung removed, 11 pawns ok, 9 pawns cause errors

So it happens both with and without Achtung installed.

Error with Achtung removed: https://pastebin.com/yVwvCesn

(Post 1/2)

@Gideon So got some bad news. Error is happening again. Also, it's not 100% of the time it happens, apparently.

I did a lot more testing, and narrowed down the error to a single event.

Issue: When having a pawn selected, right-clicking a pawn from a crash-landed pod (RefugePodCrash event in dev console) causes the error roughly 50% of the time. Reloading does not fix the issue.

The previous time I had the error, my first event on my solo pawn colony after installing Dimensons RePocketed was a transport pod crash that had a survivor. Right-clicking the pawn would cause the issue. Since that was the only other pawn on the map, I didn't think to do any further testing.

After the fix, I loaded the game and tested it on one of my own pawns and right-click was working, so I just assumed it was fixed. My bad for not testing it in an scenario that was exactly the same.

Quick question that has been lingering on my mind ever since I first saw this, along with other mods like the vehicle interiors mod, would it be possible to have a 'fake door' that you can place in your settlement that leads to a similar pocket dimension that you can build in? Kind of like the RV with the interior mod, but its just a stationary door?

So the problem is definitely mods that don't like nulls.

you're welcome

@Gideon Initial test has no issues. I'm able to select a pawn, and right-click other pawns with no problems.

So far, looks like the patch fixed my issue, thanks!

@Kelven, patch is released if you want to see if the change from null to empty list solves your null reference exceptions.

@Gideon Modlist: https://pastebin.com/Br9YxSBn

If you both want to upload your mod lists to pastebin, I can run them through a comparison and see what you have in common that might be relevant.

To put some information from myself out here:
I dont have the mod "Achtung", so i dont think it can be it or a combination with it.

I'm going to be releasing a patch for this mod soon...I will include a change to return an empty List object instead of null...that will prove whether it solves the problem or not.

@Gideon to answer your question, it happens only when I have one of my pawns selected, and right-click another living pawn. If the pawn I right-click is dead, it does not occur.

Thank you for checking this for me btw. Apparently Achtung has a Github, so I might see about making an account and posting the issue there and see if they can fix it

I think I found the cause.

RimWorld gracefully handles a null. Achtung! doesnt check for a null before it tries to reference properties. Essentially this is happening because if there are no relevant context menu entries, I don't waste RAM and CPU returning an empty List object, I just return null.

A simple check by Achtung! whether a variable is null or not would resolve.

Quick question....does the problem occur when you right-click on a pawn or when you right-click something other than a pawn while you have a pawn selected?

Most likely, given what Acthung! does, it's "taking over" handling of colonist behaviors...that's kinda what it does...so for Achtung! to assert that it's never Acthung! doing something is difficult to back up given that they essentially override references to RimWorld core code.

The thing that concerns me with this output...while it may be true that Achtung! doesn't modify context menu items themselves, the stack trace from your output indicates it very much did modify my method's behavior indirectly...my method has a signature that looks like this:

public override IEnumerable<FloatMenuOption> GetOptionsFor(Pawn target, FloatMenuContext context)

I take 2 inputs--Pawn and FloatMenuContext. Neither of these references AchtungMod.Colonist, which means somewhere within ActhungMod is a Harmony patch that's forcing my mod to dereference Pawn and instead get handled by ActhungMod.Colonist.

@Gideon yeah, I agree that saying "oh it's never my mod" is kind of an arrogant statement. Achtung even has comments disabled so I can't even reach out to the author there. However I've been using Achtung since 2017 so it's kind of hard for me to just drop it at this point.

Unfortunately I have 0 knowledge with modding so the best I can do is provide logs and hope someone can let me know where the issue is.

However since I've had 0 issues with Achtung until I installed Dimensions Repocketed (I've even used the original Pocket Dimensions mod for years, along with Achtung, with 0 issues), I'm assuming it's either an incompatibility between Dimensons Repocketed and Achtung, OR it's an incompatibility with Dimensons Repocketed and another mod I have, and Achtung is just reporting it.

Without knowing what other mod might have issues with Dimensions Repocketed, and Achtung not allowing comments, my only option is to post my issue here and hope someone can figure it out :(

Good morning. This mod does have a menu item generator (FloatMenuOptionProvider_CarryToPocket). I don't have Achtung! installed, and the context menu works fine for me without errors. I'm always wary of any modder claiming errors that reference their mod are "never my mod"--this kind of response tells me the modder doesn't want to put any effort into actually reviewing the content and isn't open to the idea that they, like everyone else in the community, are imperfect and can have bugs, too. This mod has had zero testing with Achtung!, so I can't give a compatibility statement with that mod.

I got the same exact error as Kelven with this mod active. Just had to troubleshoot for 2 days now to find out it is this mod.

Getting a constant red error when having a colonist selected, and right-clicking any other alive pawn (friendly or enemy). Removed this mod and error goes away. Since I'm the first one to report this I'm going to assume it's a mod incompatibility somewhere.

Error: https://pastebin.com/ft1DVhBQ
HugsLib: https://gist.github.com/HugsLibRecordKeeper/0e7db608418dfab0b679eaf8666bdaea

The error references AchtungMod, so I went to that mod page first and it's description says "Whenever a mod errors during this process it looks like it’s Achtung causing this problem. Which is not the case. Achtung does nothing to the content of the menu items. Instead it is designed to display a warning so you get at least something instead of the whole menu being not displayed because some mod threw an error. This is a feature that can help you analyse the problem with one of your other mods. It is never an Achtung bug."

So ya, error goes away when removing Dimensions RePocketed