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://gtm.steamproxy.vip/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

Thanks Gideon! I love this mod, I really appreciate you stepping up to maintain it.

One of my favorite mods.

Definitely Not A Bot, the event response that syncs power disruption outside the box to the pocket inside the box is one of the pieces I had to refactor for 1.6. Its entirely possible its a bug on my end. I'll check it out.

I was hoping this mod would be updated for 1.6. Thanks for doing that.

Write "1.6" on the preview.

Might have something to do with the solar shield mod: https://gtm.steamproxy.vip/sharedfiles/filedetails/?id=728315620 .

I tried removing the solar share shield mod and reloading and the issue still occurred, so maybe not.

Hey, I ran into this error when a solar flare hit: https://gist.github.com/HugsLibRecordKeeper/08e921c32115216d6f23bba7e4e3f788

(error is near the bottom).

There are a lot of other mods loaded so it may be a conflict somewhere, but I figured I'd share anyway

Just make sure you dont *replace* the pocket wall. Replacing it will destroy the pocket.

@ElizTriad, I recommend building a wall touching the pocket wall. This inner wall will be stuffable and printable.

I can look at options for what you're requesting but not sure what would be involved off the top of my head as I've never made something invincible before.

Could you add the ability to make walls invulnerable as in the mod?
https://gtm.steamproxy.vip/sharedfiles/filedetails/?id=3547933601
It would also be great to be able to paint the walls.

OK, patch is out. It should be safe both to rotate the ship and to fly the ship without having to pick up the box first.

I can confirm it is presently NOT safe to take off with it still installed on a gravship. I'm working on a patch now.

Don't make any assumptions with this. It's not identical to the original. Significant changes have been made to modernize it to the way 1.6 code works, so it's definitely worth re-testing. One of the areas that was revamped was the logic that determines when the box is lost/abandoned/stolen, so hopefully things work better now. I'm not sure if it will be needed, but one of the things I'm also considering is modifying the logic to check if the box is on a gravship. If it gets destroyed during flight, this may be a thing I have to look into.

Oh to elaborate, I was using Vehicle interiors and Pocket Dimensions a lot and found that trying to launch a ship that had an interior with a Pocket dimension installed (or send a vehicle on a caravan trip) would destroy the pocket dimension unless I first made sure to uninstall the entry point. SOS2 was an additional level of complexity to add to that. (take off and landing were fine but the game still considered the location of the Pocket Dimension to be wherever the entry point was last installed.)

Also thanks for updating this, this mod is on my short list for "literally can't play the game without it."

I definitely recommend not rotating the ship with it placed until one of us has tested and verified it does not get destroyed.

Aciel.Samael may be correct. I've done basic unit testing for the code and verified it does not cause any errors during operation, but I have not yet tested it on a gravship. I'll be doing that soon.

@Captain Rex It is likely that you will want to uninstall the entry point before taking off similar to how you had to do that if using Vehicle Interiors.

works for gravships?