@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?