This week while testing Vehicle Wagon compatibility with Space Exploration, I found that GCKI misbehaves when vehicles are taken to space surfaces. In space, SE sets car entities to inactive (zero gravity means they are strapped down). If you click on the car with a Car Key, it sets the vehicle from inactive back to active, but then prevents you from entering the vehicle and driving, saying it is "locked".

I think there is due to using toggles on two separate variables (entity.active and global.locked) and SE makes them get out of sync.

First suggestion is to set entity.acrive equal to the state of global.locked rather than toggling it separately. Second, use the SE remote interface to determine if the vehicle was locked by SE because of zero gravity, and don't change entity.active in that case. Earendel added a new function to make this easier. The code I use is

```
-- Check if we are IN SPAAAACE!

local in_space = false

if remote.interfaces["space-exploration"] then

  local surface_type = remote.call("space-exploration", "get_surface_type", {surface_index = vehicle.surface.index})

  -- These are the "solid" surface types

  if not (surface_type == "planet" or surface_type == "moon" or surface_type == "vault") then

    in_space = true

  end

end```

One more thing you have to do to be compatible is handle the on_entity_cloned event and copy the data you have stored for the old unit to an entry for the new one. SE always deletes the source of the clone, and in the next release will finally raise script_raised_destroy correctly.

Hi! Did you test with GCKI version 1.1.1 (released yesterday)? This sounds conspicuously like this Factorio bug: Vehicles that had been set to inactive in Factorio <1.1 could not be activated in Factorio 1.1. So, unlocking a vehicle would set minable = true and operable = true while keeping active = false. This has been fixed in Factorio 1.1.6, and GCKI 1.1.1 has a migration script that should properly restore the locked status of all vehicles.

Also, I've changed the inner workings of GCKI: Previously, I used to check for vehicle.active AND vehicle.minable AND vehicle.operable to find out if a vehicle has been locked, now I check for the presence of global.GCKI_vehicles.locker (and also keep a list of locked vehicles per player: global.locker[player][vehicle.unit_number] = vehicle.unit_number).

I'm currently working on a bug fix for Bio Industries. When that's done, I'll take a look at SE. Anyway, thanks for the report and the code snippet! I never used SE myself yet, so I wasn't aware of any problems. :-)

One more thing you have to do to be compatible is handle the on_entity_cloned event and copy the data you have stored for the old unit to an entry for the new one. SE always deletes the source of the clone, and in the next release will finally raise script_raised_destroy correctly.

Good to know, that's definitely something I'll need to add!

I haven't tried it in the latest version, but my test save was started in 1.1. I'll give it another go today.

I think there is due to using toggles on two separate variables (entity.active and global.locked) and SE makes them get out of sync.

Got around to work on GCKI again. Actually, this is just a variation of the patch we used for Uncle Shroud's Unminable Vehicles, right? So, looking for that code and inserting a slightly adjusted copy of it (different test conditions, and changing vehicle.active instead of vehicle.minable) seems to do the trick. Just made these changes blindly for now, I'll try them out when I get back home to my Factorio computer. :-)

One more thing you have to do to be compatible is handle the on_entity_cloned event and copy the data you have stored for the old unit to an entry for the new one. SE always deletes the source of the clone, and in the next release will finally raise script_raised_destroy correctly.

Is it still necessary to listen to on_entity_cloned? Do you know of anything else I'd need to watch out for regarding SE? I've spent too much time on BI lately, and didn't touch my other mods in months, so if you've got any news it may save me some time digging through the code of yet another complex mod. :-)

I haven't looked at Factorio in a while, but I think that is still correct. I know that the "clone area" function used by SE to create spaceship surfaces triggers on_entity_cloned and nothing else. One thing to note is that after cloning, SE will delete either the original or the clone, depending on where the Spaceship Wall bounday is.

I've just added the "lost in space" check, and there's already a stub for the on_entity_cloned event. Do you have a saved game with SE that I could use for testing, by any chance? SE is so intimidatingly huge, I'm not sure how to set up a test for it yet …

Not sure if this save still works, but this is what I was using before. https://drive.google.com/file/d/18urEaVTt-yzMxR9WJzuWwiBPa8-KP-nU/view?usp=sharing

Not sure if this save still works

Thank you, it did work! Eventually, I've even figured out how to launch the spaceship. But I'm still working on the cloning-event routine …

-- These are the "solid" surface types
if not (surface_type == "planet" or surface_type == "moon" or surface_type == "vault") then
  in_space = true
end

Earendel has added to that:

If it returns planet, moon, vault or nil then it is not a space area and vehicles can work, but otherwise vehicles should not work (unless they are spider vehicles).

Not sure if spider vehicles are relevant for your mod, but you should definitely add a check for nil! :-)

He also has plans for future SE versions:

There is an interface for get_zone_is_space, but I've just realised that it it won't work for spaceships because they are not true "zones", so I will add a new function that checks if a surface is space later.

Not sure if I understood that correctly. It could be just "I will add a new function … later", but I really hope for "new function that checks if a surface will become space later", so I could use that to skip the on_player_driving_changed_state …

Should work in version 1.1.2!