I've noticed a bug with Nullius body switching and Gizmos Car Keys. If you have an android body, get into a car or spidertron, then switch to a different body and get into the same vehicle, then exit the vehicle, then try to switch back to the old body, that old body is gone. This is a pretty severe and dangerous conflict with Nullius. Losing a body and everything it's carrying is not good.

There's logic in the GCKI scripts where it distinguishes between players and dummy characters, and it seemingly chooses to just delete the dummy character. The default behavior without GCKI is that the unoccupied android body remains in the passenger seat and everything works out fine. I'd prefer if GCKI left a character with no player in the passenger seat completely alone.

Thanks for the report!

There's logic in the GCKI scripts where it distinguishes between players and dummy characters, and it seemingly chooses to just delete the dummy character. The default behavior without GCKI is that the unoccupied android body remains in the passenger seat and everything works out fine. I'd prefer if GCKI left a character with no player in the passenger seat completely alone.

The logic is necessary in order to remove dummies that have been placed in the vehicle by mods like Autodrive and AAI Programmable Vehicles. If I don't remove the dummies and the vehicle is killed, the dummies would be left behind on the surface next to the vehicle remnants.

I think what I could do is destroying only dummies that have neither character.player nor character.associated_player. Do you think this would work? Otherwise, what do you think of raising an event (or calling a remote function implemented in GCKI) when you switch characters, so that I can ignore them when removing dummies?

By the way, are you aware of any problems related to switching characters when miniMAXIme is active in character selector mode (i.e., if one or more character mods are used as well; cf. the optional dependencies of miniMAXIme for such mods)?

It looks like the associated_player field is not set automatically, and the body switching code doesn't currently set it. However, I could experiment with setting this field when it is no longer actively controlled by a player, if that would make it easier. I don't yet know if there will be any unwanted side effects, but it seems like a reasonable usage of that field.

Worst case, if you had to boot the character out of the passenger seat back into the game world, that's not a big deal. It's not as good as leaving them a passenger, but unoccupied android bodies can exist on their own. It's not specific to vehicles. Do the Autodrive dummies actually use the "character" character entity, or create their own new dummy character type for that purpose? If associated_player doesn't work out, it might be possible to just distinguish which character prototypes are or are not dummies.

I haven't tried it, but miniMAXIme isn't on the official supported mod list, so it's user beware. Unlike GCKI which is part of the official Nullius mod pack.

Setting associated_player seems to work OK. It has no discernable effects that I've noticed. I'll probably publish an update with that and some other changes within the next several days. This doesn't fix the conflict, but it may give you more information to work with to identify non-dummy playerless characters.

I've released an update that sets the associated_player field on unoccupied bodies.

Sorry, I've been quite busy in RL lately, so I didn't have much time to spend on modding. I think only a small change is required on my end. In scripts/vehicle_functions.lua, function common_vehicle.get_occupant_entity_data, I've added this block:

    -- character associated with a player
    elseif occupant.associated_player then
      GCKI.writeDebug("occupant is a character connected to player.")
      ret = {entity = occupant.player, index = occupant.associated_player.index, is_player = true}

before line 1714. Can you confirm that this solves the problem?

Line 1714 doesn't correspond to that function in my copy. I assume the right spot is the last case before the dummy character case. And I don't think occupant.player is the right thing to set entity to, since that will be nil. I changed it to entity = occupant. With those tweaks I tested it and that seems to address the bug as far as I can tell.

Line 1714 doesn't correspond to that function in my copy. I assume the right spot is the last case before the dummy character case.

Sorry, made a diff of my unpacked 1.1.9 folder against my WIP version. But you're right, the new block should come before the final else.

And I don't think occupant.player is the right thing to set entity to, since that will be nil. I changed it to entity = occupant. With those tweaks I tested it and that seems to address the bug as far as I can tell.

Right again, occupant.player wouldn't work! However, you should use

entity = occupant.associated_player

(I know that "entity" is a misnomer in this case because a LuaPlayer is not the same thing as a LuaEntity. I guess it must have made more sense in the past …)

OK, it still seems to work that way.

Should be fixed in 1.1.10. Thanks again for reporting and testing! :-)