Companion Drones 2.0 [WIP]

by kubiixx

Adds friends - now to Factorio 2.0 WORK IN PROGRESS - crashes may occur - use with caution !

Content
10 months ago
2.0
6.23K

g Needs a range cap

10 months ago

Range limitation? I built five of these and they started flying ~25 chucks away to deconstruct some trees/rocks where I had placed a plane for a wall. Can the range be limited to something like ~50 tiles?

10 months ago
(updated 10 months ago)

This has "always" been the behavior in this mod and its 1.1 variant. Governed by scripts/companion.lua local max_distance=250

The purpose is for you to place really large blueprints and it (having ample inventory) finishing the job without terminating. In practice you'll really only observe them "straying" rarely, and they find their way back. Another advantage is if you die very far from spawn, your companions will find their way back to you.

10 months ago
(updated 10 months ago)

rarely

I see it is not so RARELY if you trying to play with the map.

  • Open map with charterd enemies in fog of war
  • center on these enemies far away of player position.
  • move cursor over them and try zoom in/out multiple times.
    and companions will try to fly to kill them, even this distance.

The map view didn't have that effect before (Factorio v1.1.)

10 months ago

Ah, understandable, with remote view a new set of challenges related to position arise. You may have to toy around between player.position and player.physical_position attribute. It is referenced a few times, in that lua. If I get a chance later, I will see if I can find a solution. Thanks for ellaborating.

10 months ago
(updated 10 months ago)

Also, I see on map view - if some companions fly away to kill biters - they do NOT aggro on them.

10 months ago

Biters won't aggro at all on Companions. They'll aggro on the player, but if you're not close enough or one of your turrets isn't, then they'll just amble about while they die.

10 months ago

I disagree, previously both biters and worms have aggroed on companions flying towards them. Now worms NEVER aggro on, and biters and spitters do sometimes, but I still haven't figured out why it doesn't work sometimes.

10 months ago
(updated 10 months ago)

Apologies for the delay I was busy today. The solution is for mod author to add to line 121 of companion.lua to solve the issue of going in and out of remote view having the drones try to fly back even though the player never actually moved.

if not player.controller_type == player.physical_controller_type then return end

10 months ago

I suggest to replace all "player.position" token with "player.physical_position" token in companion.lua
It should fix all jumps and long range flying.

If you saved the game and loaded with this fix, it can crash:
- Just try reload it
- or rollback changes, re-save the game, re-patch, and re-load in patched version. (it can crash if some job sequence is in the progress, and you patched it in the middle)

P.S. This still doesn't fix drone teleportation to a new remote viewed surface when viewing it through the map view.

10 months ago

ok, also replace all "player.surface" with "player.physical_surface" - and it should fix drones teleportation for the map view.

10 months ago
(updated 10 months ago)

saaadel, the jumps described are the result of the controller not being compared prior to position in this function (and any usage of position is affected with the introduction of remote_view). changing position and physical_position wont make a difference in that vein ( i tested it ).

local adjust_follow_behavior = function(player)
local player_data = script_data.player_data[player.index]
if not player_data then return end
local count = 0
local guys = {}

if not player.controller_type == player.physical_controller_type then return end -- add here
local surface = player.surface

as for teleporting to different surfaces there is a different function for that though I have not tested it in game.
function Companion:return_to_player()

if not self.player.valid then return end

if self.player.surface ~= self.entity.surface then
return -- the old script views this as odd and terminates.
end

however a few lines down it teleports if distance is too great, so why not do the same? the script also assumes companions will be constrained to surfaces. this may be intentional but will cause problems now since adjust_follow_behavior is run per tick.

if self.player.surface ~= self.entity.surface then
self.entity.surface = self.player.surface
self:teleport(self.player.position, self.entity.surface)

I see no reason this could not also be done in the adjust_follow_behavior function....
If you want I'm on the factorio discord and can help you or the mod author make these "necessary" modifications.

10 months ago
(updated 10 months ago)

Honestly, I didn't just write this - I ran it and tested it in a local game. In my case, it worked fine.

The important thing is that we are changing a token, not a variable - I mean, some tokens in the text have a "self" prefix or something like that - in ALL cases we have to do this substitution like in a normal text editor with search and replace.

I'm also not sure if you may have the influence of other edits - I based the clean code of the latest version of the mod.

both "player.physical_surface" and "player.physical_position" should be replaced with

10 months ago
(updated 10 months ago)

[fix removed - not actual]

10 months ago

Apologies for the delay I was busy today. The solution is for mod author to add to line 121 of companion.lua to solve the issue of going in and out of remote view having the drones try to fly back even though the player never actually moved.

if not player.controller_type == player.physical_controller_type then return end

In 2.0.6 i have added this line

if not target.controller_type or target.controller_type ~= defines.controllers.character then return end

I work for me

New response