kyranf / robotarmyfactorio Goto Github PK

First of all, thanks for making an awesome mod, I like it a lot!

There's a few issues I'm running into with squads deciding how and where to attack, though.

When a squad of 30 goes out to attack something, usually half the squad gets stuck behind some trees for a short while, causing half the squad to engage then die, slowly reinforced by the other half which then suffers the same fate. It would be better if the squad waited for every member to be there (just defend themselves against attackers from the nearby base), and engage all together. This problem gets worse if there are worms in the base, since a small worm kills a battle droid in 2-3 hits. To make it even better, perhaps a squad should hold a "formation" of sorts with the battle droids and/or flamebots up front, and the rocket droids in the back, allowing rockets droids to take out the worms before the droids even get in range of them.

The "squad size hunt" setting works well when deciding when to leave from the spawning point, but once a squad has left it seems to count the distance from itself rather than the spawning point. So, it will just keep going out further and further instead of in a nice circle around the spawning point.

Possibly related, I've never seen a squad return after it suffers some casualties. For example, I have set 'squad size hunt' to 30 and 'return size' to 20. If a squad of 30 goes out, kills some bases and suffers some losses, let's say 15 bots are left, they will happily continue attacking until all droids are dead instead of returning to the spawn point.

Using version 0.2.2

Playing Factorio 0.13.5 on steam with a few mods installed and I get this error.
"Notice
Error while running the event handler:
robotarmy/robolib/Squad.lua:105:
LuaUnitGroup doesn't contain key surface."

I am new to modding so I dont know exactly what this means or how to fix it.

All mods i have are
Advanced Logistis, Auto Deconstruct, Auto Trash, Color Coding, EvoGUI, Factorio Reach,
Factorissimo, FARL, Larger Inventory, MoreLight, Rail Tanker, Robot Army, Resource Spawner Overhaul,
Upgrade Builder and Planner, Warehousing Mod, YARM.

needs an icon, currently uses construction robot icon.

need a new robot army combinator to set squad hunting size number

currently uses the logistics robot icon, needs it's own. perhaps a little metallic cube that folds out to be a robot?

add new virtual signals for each droid type count in addition to the total number of droids alive. This will help people create armies with certain ratios.

Will be a new icon per signal, and some pretty simple additional code to the counting function.

When a squad becomes under-sized and not large enough to be sent on a subsequent hunting mission, or a droid gets kicked out of his squad because he lags behind too much (factorio bug?) force them to leave whatever unitgroup they are in and move to nearest droid assembler's usual spawning position and then trigger a "join nearest or create new" style of response.

need explosion on death, similar to combat robot or a grenade explosion. In fact, why not trigger a grenade-like explosion on death? That would be flipping amazing to watch.

There are at least 2-3 places where the wander command radius is a magic number instead of the default squad radius config parameter. Fix that so they are all changed by the same parameter. This fixes most of the problems related to droids not joining squads, rather creating their own when spawning slowly by way of droid assembler.

currently the droid item is in the "unsorted" category and is ugly. for now it should be thrown into the military tab.

any mod with an on_load() function that changes the global table now causes an error, failing to load games.

fix for now is to delete the entire on_load() function from control.lua until next bugfix patch (soon!)

Recently I started playing with this mod and I had an Idea that might be worth thinking about:

Change the build-process of the Bots to have multiple slots:

• Weapon-Slot
• Defense-Slot
• AI-Slot

Currently there are 4 bots in your mod:
Clockwork Riflebot : Pistol - Iron Armor - Basic-AI
Battle Droid : Submachine Gun - Heavy Armor - Basic-AI
Rocket Bot : Rocket Launcher - Heavy Armor - Basic-AI
Terminator : Laser Turret - Modular Armor - Basic-AI

Weapon Slot:

• needs to be a Hand-Weapon for the player, or a Turret-type (something that has a range and a shooting method)
• Maybe later on changes the sprites used for the weapon

Defense Slot:

• needs to be an Armor
• will change the used Sprite (either from the amount of hitpoints, or the armor-name itself)

AI-Slot :

• changes pathfinding
• changes shooting distances
• possibilities: default, scout, leader, healer, sniper, melee?

Again, I don't know enough of the factorio mod interna to really know how much (extra?) work this would create. The option this would allow you is to have other modders use your base and create their own turrets, guns and armor, or even AI modules, and have them simply work with the robot army.

Problems and imbalances I see:

• Ammunition : From magazines to fuel for the flamethrowers.. might be imbalanced

Thanks for your mod!

Getting an error when trying to load up game for the first time with mod.
Full error:
Error while running the on_init: robotarmy/stdlib/log/logger.lua:66: Scripts can only use file space inside of C (requested path was C:/Users%USERNAME%\AppData\Roaming\Factorio\script-output\logs/robotarmy/robot_army_logs.log)

for 0.2.3, improve rally point behaviour with a repeating rally pulse, and force-deleting the last rally point when placing a new one.

When click-and-drag spawning droids (basically, just spawning them quickly), there is a large lag spike, sometimes going from 60fps down to ~35 fps.

• optimise the spawning process and remove redundant processing/code

Can be forced unlock with:
/c game.player.force.recipes["droid-rifle-deploy"].enabled = true

The cause of this is unknown, the recipe settings, tech settings, and even the mod changed/load forcing of tech/recipes should deal with this!

See about changing the colours of map blips for droids

Hi.
I got this Error after updating to Robot Army 0.21
Factorio Version: 0.13.14

Error while running the on_configuration_changed: robotarmy/control.lua:143: attempt to index field 'droidGuardStations' (a nil value)

control.lua line 163 of the 0.1.3 release, the checkIfDroidAssembly case where the global.droidassemblers table is there but the player.name reference key is not, so if it is not there, make it first and THEN call table.insert. like this:

if(entity.name == "droid-assembling-machine") then 

        if not global.DroidAssemblers then
            --player.print("Creating global droid assembler list..")
            global.DroidAssemblers = {}
            global.DroidAssemblers[player.name] = {}
            --player.print("adding droid assembler to global list..")
            table.insert(global.DroidAssemblers[player.name], entity)
        else
            if not global.DroidAssemblers[player.name] then          -- NEW CODE
                             global.DroidAssemblers[player.name] = {}          -- NEW CODE
                        end        -- NEW CODE

            table.insert(global.DroidAssemblers[player.name], entity)
        end

Like already mentioned on the forum, there is a bug wth ungenerated chunks and the mod trying to access them. I´ve redone some of the code and now the bots head back towards the middle if they sense an ungenerated chunk and request chunkgeneration if they get to close to them (security code in case of a missing chunk on their way back)
here´s the code I added after the charting code

chunkposition = {x=math.floor(position.x/32+0.5), y=math.floor(position.y/32+0.5)}
xp=-4
while xp < 5 do
    yp=-4
    while yp < 5 do
        if not game.surfaces[1].is_chunk_generated(chunkposition) then
            if yp < 2 and yp > -2 and xp < 2 and xp > -2 then
                game.surfaces[1].request_to_generate_chunks(position, 128)
                game.players[1].print("Generated new Chunks at " .. position.x .. ", " .. position.y)
            end
            local goal = {x=0,y=0}
            if position.x > 0 then goal.x = position.x -150 else goal.x = position.x + 150 end
            if position.y > 0 then goal.y = position.y -150 else goal.y = position.y + 150 end
            squad.unitGroup.set_command({type=defines.command.go_to_location, destination=goal, distraction=defines.distraction.none})
            xp=5
            yp=5
        end
        yp=yp+1
    end
    xp=xp+1
end

Good luck with further development

I think a 0.8 or 0.75 scale of the sprite and a similarly reduced collision box might be useful to help pathfinding, forest-navigation, and fitting through holes in walls etc.

The droids are a tad too large currently anyway.

field medic, when in a squad, goes through the list of members and checks their health, if damaged then somehow heal them (a little bit, or completely, whatever)

http://puu.sh/rkfp8/8c11f9ec21.jpg

They are inside my base,just sitting around and no robot assembly machine anywhere close.

What I did: I builded 2 robot assembly machines at my outposts to push the biters back. The robots did this and then started to idle, I guess they do not find any biters anymore. Look at my map:
http://puu.sh/rkfH5/0385574822.png . All the dots on top and on the left are idle robots. I am fine with them staying there. But what I do not understand is why some of them (alot actually) go to the middle of my base for no reason.

A fix I can think of are 2 new buildings:

• An IDLE meet point. All robots that are idle will go to the nearest IDLE meet point
• An assembly machine that pick up nearby robots and put them into a chest.

With this 2 buildings I could collect robots that dont do anything anymore.
Also it will help reduce lag, right now I have lags every 3 seconds.

Any chance for a lua command to kill all robots around me?
I tried this:

/c for key, entity in pairs(game.player.surface.find_entities_filtered{
   area={{game.player.position.x-100, game.player.position.y-100},
    {game.player.position.x+100, game.player.position.y+100}},
    name="droid_rocket"}) do
entity.destroy()
end

But it didnt work

Need to adjust the animation sprite shift so that the muzzle flash roughly aligns with the gun in the character sprite. All idle and running animations should be adjusted to match whatever shift is used?

Because the rocks are 100% fire proof!

so I crashed
I think it is due to this mod - because looking through the forums I only found a post by you

0.001 2016-07-19 19:37:54; Factorio 0.13.6 (build 23136, win64, alpha) 0.001 Operating system: Windows 10 0.001 Program arguments: "C:\Program Files\Factorio\bin\x64\factorio.exe" 0.001 Read data path: C:/Program Files/Factorio/data 0.001 Write data path: C:/Users/JohanII/AppData/Roaming/Factorio 0.001 Binaries path: C:/Program Files/Factorio/bin 0.016 Graphics options: [FullScreen: false] [VSync: true] [UIScale: 100%] [MultiSampling: OFF] [Graphics quality: normal] [Video memory usage: all] [Light scale: 20%] [Screen: 255] [DXT: false] 0.018 Available display adapters: 1 0.019 [0]: \\.\DISPLAY1 - Intel(R) HD Graphics 4000 {0x05, [0,0], 1920x1080, 32bit, 60Hz} 0.019 Create display on adapter 0. Size 1280x720 at position [310, 162]. 0.064 Initialised Direct3D:[0] NVIDIA GeForce GTX 680M ; driver: nvd3dumx.dll 10.18.13.5362 0.066 Video memory size (dedicated video/dedicated system/shared system/available): 4027/0/8137/4092 MB 0.098 Desktop composition is active. 0.193 Loading mod core 0.0.0 (data.lua) 0.197 Loading mod base 0.13.6 (data.lua) 0.302 Loading mod blueprint-string 3.0.3 (data.lua) 0.370 Loading mod AutoTrash 0.1.5 (data.lua) 0.437 Loading mod EvoGUI 0.4.105 (data.lua) 0.502 Loading mod Expanded_Robot_Tech 0.4.1 (data.lua) 0.579 Loading mod Landfill 2.1.10 (data.lua) 0.644 Loading mod Larger Inventory 1.0.1 (data.lua) 0.711 Loading mod MoreLight 1.1.1 (data.lua) 0.790 Loading mod RailTanker 1.3.32 (data.lua) 0.790 Script data.lua:18: done 0.856 Loading mod robotarmy 0.2.0 (data.lua) 0.931 Loading mod TheFatController 0.4.18 (data.lua) 1.018 Loading mod YARM 0.7.102 (data.lua) 1.087 Loading mod long-reach 0.0.5 (data-final-fixes.lua) 1.156 Loading mod RailTanker 1.3.32 (data-final-fixes.lua) 1.229 Checksum for core: 714099156 1.229 Checksum for mod base: 1855085279 1.229 Checksum for mod blueprint-string: 2370144521 1.229 Checksum for mod autofill: 0 1.229 Checksum for mod AutoTrash: 1587932681 1.229 Checksum for mod clock: 0 1.229 Checksum for mod EvoGUI: 1040096666 1.229 Checksum for mod Expanded_Robot_Tech: 450750456 1.229 Checksum for mod Landfill: 3661776105 1.229 Checksum for mod Larger Inventory: 32563986 1.229 Checksum for mod long-reach: 315959611 1.229 Checksum for mod MoreLight: 3037131012 1.229 Checksum for mod RailTanker: 886730006 1.229 Checksum for mod robotarmy: 2391337320 1.229 Checksum for mod TheFatController: 2087045025 1.229 Checksum for mod YARM: 1471126532 1.825 Initial atlas bitmap size is 16384 1.829 Created atlas bitmap 16384x10348 2.215 Created atlas bitmap 4096x996 7.633 Sprites loaded 7.633 Convert atlas 4096x996 to: trilinear-filtering 7.856 Loading sounds... 9.527 Custom inputs active: 2 9.527 Info Updater.cpp:750: Downloading https://www.factorio.com/updater/get-available-versions?username=J0h4n&token=<private>&apiVersion=2 10.564 A newer version of Factorio exists, but it can no longer be obtained using automatic updates. Please download the latest version manually from http://www.factorio.com. 10.600 Factorio initialised 20.966 Loading map C:/Users\JohanII\AppData\Roaming\Factorio\saves\_autosave3.zip 20.992 Info Scenario.cpp:127: Map version 0.13.6-0 21.618 Checksum for script C:/Users/JohanII/AppData/Roaming/Factorio/temp/currently-playing/control.lua: 900459546 21.626 Checksum for script __blueprint-string__/control.lua: 1853645101 21.630 Checksum for script __autofill__/control.lua: 2546383396 21.633 Checksum for script __AutoTrash__/control.lua: 3595631901 21.634 Checksum for script __clock__/control.lua: 2990318672 21.637 Checksum for script __EvoGUI__/control.lua: 1485927187 21.638 Checksum for script __Landfill__/control.lua: 530583378 21.640 Checksum for script __RailTanker__/control.lua: 843196296 21.643 Checksum for script __robotarmy__/control.lua: 4219419030 21.649 Checksum for script __TheFatController__/control.lua: 2348030623 21.652 Checksum for script __YARM__/control.lua: 616803594 Factorio crashed. Generating symbolized stacktrace, please wait ... c:\cygwin64\tmp\factorio-ri3osb\libraries\stackwalker\stackwalker.cpp (906): StackWalker::ShowCallstack c:\cygwin64\tmp\factorio-ri3osb\src\util\logger.cpp (328): Logger::writeStacktrace c:\cygwin64\tmp\factorio-ri3osb\src\util\logger.cpp (382): Logger::logStacktrace c:\cygwin64\tmp\factorio-ri3osb\src\surface\chunk.cpp (564): Chunk::Chunk c:\cygwin64\tmp\factorio-ri3osb\src\surface\surface.cpp (846): Surface::collideWithTile c:\cygwin64\tmp\factorio-ri3osb\src\entity\entity.cpp (388): Entity::changePosition c:\cygwin64\tmp\factorio-ri3osb\src\entity\unit.cpp (132): Unit::changePosition c:\cygwin64\tmp\factorio-ri3osb\src\entity\unit.cpp (118): Unit::moveSmooth c:\cygwin64\tmp\factorio-ri3osb\src\ai\gotobehavior.cpp (686): GotoBehavior::execute c:\cygwin64\tmp\factorio-ri3osb\src\ai\followpathbehavior.cpp (160): FollowPathBehavior::execute c:\cygwin64\tmp\factorio-ri3osb\src\ai\groupbehavior.cpp (151): GroupBehavior::execute c:\cygwin64\tmp\factorio-ri3osb\src\ai\commandable.cpp (113): Commandable::runBehavior c:\cygwin64\tmp\factorio-ri3osb\src\entity\unit.cpp (242): Unit::update c:\cygwin64\tmp\factorio-ri3osb\src\surface\chunk.cpp (471): Chunk::update c:\cygwin64\tmp\factorio-ri3osb\src\surface\surface.cpp (905): Surface::update c:\cygwin64\tmp\factorio-ri3osb\src\map\map.cpp (1097): Map::update c:\cygwin64\tmp\factorio-ri3osb\src\game.cpp (141): Game::update c:\cygwin64\tmp\factorio-ri3osb\src\scenario\scenario.cpp (763): Scenario::update c:\cygwin64\tmp\factorio-ri3osb\src\mainloop.cpp (337): MainLoop::gameUpdateStep c:\cygwin64\tmp\factorio-ri3osb\src\mainloop.cpp (472): MainLoop::updateLoop c:\program files (x86)\microsoft visual studio 14.0\vc\include\functional (214): std::_Func_impl<std::_Binder<std::_Unforced,void (__cdecl&)(ThreadBarrier * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,bool * __ptr64,bool,enum MainLoop::HeavyMode),ThreadBarrier * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,bool * __ptr64,bool & __ptr64,enum MainLoop::HeavyMode & __ptr64>,std::allocator<int>,void>::_Do_call c:\cygwin64\tmp\factorio-ri3osb\src\util\thread.cpp (34): Thread::loop ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FF7DD6C5103) 00007FF7DD6C5103 (factorio): (filename not available): boost::thread::start_thread_noexcept d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp (115): thread_start<unsigned int (__cdecl*)(void * __ptr64)> ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FF94D108102) 00007FF94D108102 (KERNEL32): (filename not available): BaseThreadInitThunk ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FF950F4C5B4) 00007FF950F4C5B4 (ntdll): (filename not available): RtlUserThreadStart 38.024 Error Chunk.cpp:564: Trying to make chunk at unreasonable position [262141, 262143] Factorio crashed. Generating symbolized stacktrace, please wait ... c:\cygwin64\tmp\factorio-ri3osb\libraries\stackwalker\stackwalker.cpp (906): StackWalker::ShowCallstack c:\cygwin64\tmp\factorio-ri3osb\src\util\logger.cpp (328): Logger::writeStacktrace c:\cygwin64\tmp\factorio-ri3osb\src\util\logger.cpp (382): Logger::logStacktrace c:\cygwin64\tmp\factorio-ri3osb\src\util\crashhandler.cpp (84): CrashHandler::writeStackTrace c:\cygwin64\tmp\factorio-ri3osb\src\util\crashhandler.cpp (186): CrashHandler::SignalHandler d:\th\minkernel\crts\ucrt\src\appcrt\misc\signal.cpp (516): raise d:\th\minkernel\crts\ucrt\src\appcrt\startup\abort.cpp (71): abort c:\cygwin64\tmp\factorio-ri3osb\src\surface\chunk.cpp (564): Chunk::Chunk c:\cygwin64\tmp\factorio-ri3osb\src\surface\surface.cpp (846): Surface::collideWithTile c:\cygwin64\tmp\factorio-ri3osb\src\entity\entity.cpp (388): Entity::changePosition c:\cygwin64\tmp\factorio-ri3osb\src\entity\unit.cpp (132): Unit::changePosition c:\cygwin64\tmp\factorio-ri3osb\src\entity\unit.cpp (118): Unit::moveSmooth c:\cygwin64\tmp\factorio-ri3osb\src\ai\gotobehavior.cpp (686): GotoBehavior::execute c:\cygwin64\tmp\factorio-ri3osb\src\ai\followpathbehavior.cpp (160): FollowPathBehavior::execute c:\cygwin64\tmp\factorio-ri3osb\src\ai\groupbehavior.cpp (151): GroupBehavior::execute c:\cygwin64\tmp\factorio-ri3osb\src\ai\commandable.cpp (113): Commandable::runBehavior c:\cygwin64\tmp\factorio-ri3osb\src\entity\unit.cpp (242): Unit::update c:\cygwin64\tmp\factorio-ri3osb\src\surface\chunk.cpp (471): Chunk::update c:\cygwin64\tmp\factorio-ri3osb\src\surface\surface.cpp (905): Surface::update c:\cygwin64\tmp\factorio-ri3osb\src\map\map.cpp (1097): Map::update c:\cygwin64\tmp\factorio-ri3osb\src\game.cpp (141): Game::update c:\cygwin64\tmp\factorio-ri3osb\src\scenario\scenario.cpp (763): Scenario::update c:\cygwin64\tmp\factorio-ri3osb\src\mainloop.cpp (337): MainLoop::gameUpdateStep c:\cygwin64\tmp\factorio-ri3osb\src\mainloop.cpp (472): MainLoop::updateLoop c:\program files (x86)\microsoft visual studio 14.0\vc\include\functional (214): std::_Func_impl<std::_Binder<std::_Unforced,void (__cdecl&)(ThreadBarrier * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,bool * __ptr64,bool,enum MainLoop::HeavyMode),ThreadBarrier * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,boost::chrono::time_point<boost::chrono::steady_clock,boost::chrono::duration<__int64,boost::ratio<1,1000000000> > > * __ptr64,bool * __ptr64,bool & __ptr64,enum MainLoop::HeavyMode & __ptr64>,std::allocator<int>,void>::_Do_call c:\cygwin64\tmp\factorio-ri3osb\src\util\thread.cpp (34): Thread::loop ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FF7DD6C5103) 00007FF7DD6C5103 (factorio): (filename not available): boost::thread::start_thread_noexcept d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp (115): thread_start<unsigned int (__cdecl*)(void * __ptr64)> ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FF94D108102) 00007FF94D108102 (KERNEL32): (filename not available): BaseThreadInitThunk ERROR: SymGetLineFromAddr64, GetLastError: 487 (Address: 00007FF950F4C5B4) 00007FF950F4C5B4 (ntdll): (filename not available): RtlUserThreadStart 38.764 Error CrashHandler.cpp:85: Map tick at moment of crash: 1095317 38.764 Error Util.cpp:77: Unexpected error occurred. You can help us to solve the problem by posting the contents of the log file on the Factorio forums.

droids are spawning inside eachother, which snowballs and gets pretty hectic!

need to create and maintain a "task" list which is a portion of squads in a force.

every tick, do at least one squad's AI routines, rather than possibly hundreds of squads all at once on the nth tick. This will definitely fix the lag "spike" issues.

Currently when it's the squad AI tick update time to run, the functions (like send to battle/retreat AI, grabbing artifacts, reveal chunks, and soon guardAIupdate) all waste time by each individually going through the list of forces and then the list of squads every time.

refactor the functions so they operate only on a single squad entry and return true/false if they did in fact operate on the squad.

Then, in the squad AI update tick (and in the new tick-scheduler way of doing things) just iterate through the forces and through each force's squad table, and as required, do the AI functions on a per-squad basis doing whatever checks are needed prior to even entering the particular function. Like checking if the squad.command == commands.guard and if true, calling the guardAIUpdate function. Otherwise that function would never be called for that squad, which is more efficient.

Possible new AI behaviour to send squads out to follow the pollution furthest reaches chunks, moving from chunk to chunk, just finding the lowest polluted chunk >1% or whatever.

https://github.com/kyranf/robotarmyfactorio/blob/master/robolib/Squad.lua#L402

What happens if you are on a surface other than the default and want to pick up artifacts :)

If no enemy target is found within 5k tiles, the squad randomly disbands and the members of the squad just become idle wanderers with no squad. The only way to get rid of them is to pick them up, or let them die (if biters eventually come close enough).

They shouldn't affect game performance, but they can be annoying.

It's not super obvious as to what causes it, it could be giving the squad a nil target breaks the game logic enough to cause what we see, or there is a max range to the attack_move command that I don't know about.

need a new AI script that checks for squads adjacent/on train tracks and moves them away from it, while in "assembling" or "guard" mode (or others?)

When placed by a construction bot, the on_robot_built_entity event fires, NOT the on_built_entity event. Therefore, this situation is completely unhandled and bot-placed droid assemblers will not be added to the list of assemblers for generating droids on update tick.

To fix this, the entire code-base needs to be re-written to organize squads by force not by player name reference. This is because on_robot_built_entity gives no way to obtain which player the bot belonged to, only the force of the newly created entity is known (so force can still be used).

force makes more sense in the long run so i'm happy with this.

Caused by factorio's pathfinder. large squads cause more drain than small squads. Add a max squad size feature to avoid huge squads causing a massive FPS drain.

https://mods.factorio.com/mods/kyranzor/robotarmy/discussion/4007

text reads: Error while running the event handler: control.lua:357: bad argument #1 to 'pairs' (table expected, got nil)

Related to post https://forums.factorio.com/viewtopic.php?p=190771#p190771

condition where modular armours are not stackable, so stack inserters cannot put all the armour into the assembler making a terminator so it will never be able to continue putting in other resources.

This is a Factorio related issue, but we can alleviate this issue by making the Robot Army specific intermediate droid items in order to build the droids rather than using the vanilla items.

loot chest becomes invalid when removed and squads then try to put artifacts in it, causing an error.

https://github.com/kyranf/robotarmyfactorio/blob/master/robolib/Squad.lua#L397

needs to have "and global.lootChests[player.force.name].valid" added to the end.

Should disable the logger spam for when nobody has placed a droid assembler yet.

droids being assembled eventually start screwing up, and making their own squads or are removed from squads so they end up just wandering around.

to reproduce, let a single assembler slowly deploy droids as they are produced by an assembling machine 2. after a while, the system breaks down and the droids join their own squads instead of the one right next to them. Some droids have also been seen to disband their squad and become wanderers.

Possible debugging of this may involve closely monitored test cases (spamming to log files for now, some to console print) examining the process for a droid spawned from assembler regarding what squad to join, how/why it could fail, reasons why a new squad would be made, and what could be causing the squad-disband issue.

Finally, the solution for the wanderers could be a script only run occasionally (it will hurt performance a lot) that goes through the list of units owned by the force and finds all of the ones not in unitgroups (check their unitgroup parameter) and if they aren't in one, make them all go to the nearest droid assembler or radar (if no droid assemblers) and add themselves to a list of candidates to group up later. A much simpler solution is to just order them to their deaths, going to nearest enemy.

I have a save that was using the older version, after upgrading though anytime I try to add a force to the game line 53 throws attempt to index field 'droidGuardStations' (a nil value).

After placing a guard station it works fine.

line 130 looks like it is missing a guard station initialization.

At the very least, try and test what happens..

the player list in game.players is for all players who have ever connected. If we make a global.Squads table with their names as a key, and iterate over it to issue squads their orders.. if any order needs the player's current position, what will happen? Will position be nil (bad)? will position just be the last known position before they logged out (weird, but maybe okay)?

Can check if a player is connected using player.connected -> (return a bool)
Perhaps do not process player's squads unless they are connected.

4349.508 Error MainLoop.cpp:665: Exception at tick 5114866: Error while running the event handler: robotarmy/robolib/robotarmyhelpers.lua:292: attempt to index local 'squad' (a nil value)
4349.508 Error MultiplayerManager.cpp:129: MultiplayerManager failed: "Error while running the event handler: robotarmy/robolib/robotarmyhelpers.lua:292: attempt to index local 'squad' (a nil value)"

Need some basic parts for droid construction, starting with clockwork robot parts, and either using previous ones or introducing new shared parts for similar tech level droid production.

Like "tracks" can be shared by all droids, but terminators get "fast tracks" or something

"droid torso" can be equivalent to the armour piece in cost, and shared by all 3 droids maybe?

the guns can stay the same.. i might make a new item for the clockwork bot to act as the "rifle".

cause: flags = "hidden".

The dummy-droid end product is the one that should be hidden not the more useful intermediate/place-able Undeployed item.

Check all uses of getFirstValidSoldier and see how/why we could be passing it an empty squad reference/table.

Check for empty input in the function too. If it fails to return, then the results which try to one-liner get the surface may not work. properly (will cause another error)

Error while running the event handler: robotarmy/prototypes/Squad.lua:41: attempt to index local 'newsquad' (a nil value).

Not sure what causes this yet - it appears the result from shallowcopy is empty, which shouldn't happen - how can a declared global table used as a reference for copying blank squad templates be nil? Perhaps global had not loaded by the time the user had this issue. The issue was supposedly when a droid assembler placed the first droid down, before a player had ever done so.