[MOD 0.18] Robot Army. v0.4.4

[kyranzor]

Okay, great do you knbow when this gets released?

Do you know why i cant place the robot chest anymore? I click and it sounds like it has worked, but then it just lays on ground like if i had thrown it away.

You already have one placed down somewhere. Go find it and remove it first!

[Nexela]

Love the concept, have not installed the mod yet but leaning towards it. I do have a couple of ideas though.

Dynamic Squad composition/size - A constant combinator type entity placed near your deployers. Inside it you would set virtual signals for squad-number size soldier, makeup. IE set squad-number to 1, Set rocket-droids to 5, smg-droids to 10, patrol-distance to 500(tiles) in the combinator. and squads will form based on those signals. After the squad has been formed additional spawned droids would join the existing squad and move to meet up with them. If the existing squad is all dead they would wait until the squad size is = before moving


This might allow you to remove the rally point and guard station. If you want your droids to rally/defend you would set patrol-distance in the combinator to a smaller number.


Just some thoughts I had let me know what you think.

[kyranzor]

Dynamic Squad composition/size

Using the virtual signals like that is a good idea, and i'm going to be investigating this way of doing things for a global 'squad size' setting combinator for each force, at least to start with.

I have an idea to experiment with non-recipe based droid loading and spawning from the assembler/guard stations too - basically you don't set a recipe (and therefore, don't restrict what gets inserted) and my spawning script just looks at the input inventory rather than output inventory, and I can remove the random "deployed" version of items. This means people can just insert any droid they want and it will get spawned, which will help multiple droid type squad creation.

I think needing a combinator with specific settings next to each droid assembler, thus shifting the logic from a per-squad basis to a more assembler-oriented way, is not the "easy and fun and intuitive" way I want my mod to be... I might have a way to override defaults or certain behaviours using something like you've said for those who want supreme customization, but it might just adjust how the droid assembler spawns what it's got in its inventory to honour the ratios and maybe force the squad into a different state so it can be triggered to hunt with a condition different to just squadsize > x. In this case the condition would be "have all my ratios been satisfied according to the nearby settings-module, and is the squad size large enough?".

[Nexela]

I think needing a combinator with specific settings next to each droid assembler, etc etc etc

Yeah the combinator should be optional, if it is not present it will form squads/actions based on default settings. when a unit is deployed it looks for the "control module" in its squad distance circle thing. After it finds one the squad/unit will poll the "control module" at set intervals looking for changes to its squad size/patrol distance/etc. If the control module is also in "range" of the spawner it would control the spawning of types of droids and max amounts too!

Changing the output of the assembler to be script based has the added bonus that you can have a "max units active from this spawner" virtual signal you can set!

New Signal List Ideas:

Each Control module has a unique squad number (my orignal idea was a virtual signal but this seems better through scripting). As an added bonus maybe link squad names to backer names. and further expand on in to be renabamble
Droid Type(s) - How many of this type should be the minimum before a squad hunts.
Path distance - How far should each squad go, Squads in field can poll this signal to see if they need to fall back or go further.

Would also probably need a second combinator type which would link to the control module and these signals would be set through scripts:. This would be the one you hook up to your inserter for deploying droids.
I believe you have something like this already that counts all droids so the only change would be if near (or conected) to a "control module" only outputs the amount in the squad.
Active droid type = # The amout of these droids in the current squad


Sorry for my wild Ideas!

[kyranzor]

Nexela, great news! 0.13.10 has "LuaEntity::circuit_connected_entities" added which means i can very easily get reference to a squad-settings-combinator (and then check the constants set by the player) near a droid assembler that just has a green/red wire connecting them together.


Also, the crash related to custom units is in 0.13.10 as mentioned, and we also got an amazing bonus addition:

"Biters and other units won't become aggressive as a result of friendly-fire."

Woot!

[Arkavile]

When placing a droid rally point without any droids in the game crashes to the start screen with this error. Running factorio 0.13.10 and RobotArmy version 0.2.0

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

[kyranzor]

When placing a droid rally point without any droids in the game crashes to the start screen with this error. Running factorio 0.13.10 and RobotArmy version 0.2.0

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

Thank you, I will fix this for the next patch. The code for checking squads and sending them to the rally point isnt first checking that the list of squads itself exists.

Until the next patch, don't place a rally point without having first placed at least one droid (which creates the table). Sorry for the inconvenience!

[Nexela]

Nexela, great news! 0.13.10 has "LuaEntity::circuit_connected_entities" added which means i can very easily get reference to a squad-settings-combinator (and then check the constants set by the player) near a droid assembler that just has a green/red wire connecting them together.

Awesome!!!!!!

[Arkavile]

I'm loving the mod! Sorry I keep coming back with bug reports but I think this is related to RobotArmy as I was mainly producing/using them at the time. If this is not related to RobotArmy I appologize for posting this here as I'm using 6 mods (7 including the texture pack). Thanks!

http://pastebin.com/U64DGmUz

EDIT: Just updated my version of Factorio to 0.13.9 and I haven't received the error again yet.

[Qon]

http://pastebin.com/U64DGmUz

Crashlogs from factorio are due to bugs in factorio itself and should be posted in the bugs section of the forum so that the factorio devs can fix it. Please post your log there!

If it's a factorio style pop up message that mentions one of your mods then that is a bug in the mod code instead of factorio.

[Arkavile]

Thank you, will do.

[kyranzor]

Update to 0.13.10 (9 is outdated ) and also be aware that misanthrope is causing some crashes right now, in case you are using it.

[TruePikachu]

http://pastebin.com/U64DGmUz

Crashlogs from factorio are due to bugs in factorio itself and should be posted in the bugs section of the forum so that the factorio devs can fix it. Please post your log there!

If it's a factorio style pop up message that mentions one of your mods then that is a bug in the mod code instead of factorio.

Hi, I'm here from the bug reporting forum. There are a number of cases where mods have bugs which cause Factorio to crashdump; 28616 might be a recent example, 29126 is an example which had nothing to do with the mod's Lua, and 23568, the first bug here I've used WinDbg on, crashed the game after a Lua error message was issued; the crash itself being completly unrelated to Lua. I could probably find more examples, but 'mod' is too short to use the forum search function on.

Generally, these crashes happen when a mod does something unintended by the developers (the first link was trying to use the unsupported Loader entity, and the third used a Lua function only to be used in single player while in a multiplayer environment).

It looks like a unit (one which is the member of a group) tried to enter a chunk which was not generated yet. Either the mod is, in fact, responsible, or some biters went into the ungenerated area to create a spawn.

Code: Select all

d:\th\minkernel\crts\ucrt\src\appcrt\startup\abort.cpp (71): abort
c:\cygwin64\tmp\factorio-vdk5hi\src\surface\chunk.cpp (564): Chunk::Chunk
c:\cygwin64\tmp\factorio-vdk5hi\src\surface\surface.cpp (846): Surface::collideWithTile
c:\cygwin64\tmp\factorio-vdk5hi\src\entity\entity.cpp (388): Entity::changePosition
c:\cygwin64\tmp\factorio-vdk5hi\src\entity\unit.cpp (132): Unit::changePosition
c:\cygwin64\tmp\factorio-vdk5hi\src\entity\unit.cpp (118): Unit::moveSmooth
c:\cygwin64\tmp\factorio-vdk5hi\src\ai\gotobehavior.cpp (686): GotoBehavior::execute
c:\cygwin64\tmp\factorio-vdk5hi\src\ai\groupbehavior.cpp (151): GroupBehavior::execute

Does the mod provide any units which can bypass water? If so, it is very likely to be responsible; ground units normally can't enter the ungenerated area because it is treated as water.

If you have a save which reliably causes the crash, it would be best to provide it.

[kyranzor]

hi TruePikachu, thanks for clearing that up. Yes indeed some aspects of mods can cause game-crashes and not just lua errors. In fact at least two have been found and fixed that were brought up by/revealed by my Robot Army mod (conveyor belt bug with units placed by hand, and more recently in 0.13.10 one related to biter movement math trying to use an invalid chunk).

There are clear cases when mods are involved, when they are removed and crashing stops, but interaction between mods, special corner cases/rare scenarios, and actual (very rare these days) crashes from the base game itself are still issues which are hard to debug. As always, people should report proper game crashes directly to the devs with saves and logs and mod lists/mod package if possible..

[Qon]

There are a number of cases where mods have bugs which cause Factorio to crashdump

Still a Factorio bug if it crashdumps, it's not a mod error just because a mod triggers the crash in Factorio. Modding is a supported feature and mods should never be able to crash the game. In some corner cases extremely exaggerated features that are not intended to be turned to 11 might cause problems because they haven't been able to test those cases, but in general it's valid.

• Error in the mod info JSON are reported before the factorio GUI dialouge box graphics are loaded I believe and there's not much to do when a mod is incorrect. The game doesn't ask you to send a bug report, it is a controlled shutdown that still reports the bug as a mod problem. I didn't see any crashlog in that thread (just doing quick checks). It's the same as a normal mod error message but with OS native dialogue boxes instead. So just a case of differen't graphics but the message is indicating a mod bug and it's not a crash and should be reported to mod author as I said.
• The loader is not supported and is an undocumented non-feature. It's not really a mod problem or a Factorio problem, more a user error. Well ok it is a Factorio bug, but the solution is removing the loader which some people might dislike more than having an unstable game.
• The third was fixed according to dev response so I'm not sure why you mentioned it.

[TruePikachu]

and more recently in 0.13.10 one related to biter movement math trying to use an invalid chunk

Hm, so your units are using the biter nav code, and causing the game to crash by using invalid/unloaded/ungenerated chunks? That would probably be a Factorio bug, since it would make sense to use the same base code for new entities, and the code itself is used by the game (even though the circumstance almost certainly isn't, possibly barring base expansion).

If you wish, you can mention whatever you feel is relevant in the particular thread. I'm not mentioning this particular guess there, since it depends on assumptions which you would need to validate first, and your word on it (being the author of a mod which reveals a core game issue) carries a bit more weight than mine (being an investigative debugger).

I am not monitoring this thread any further. Any information relating to the bug linked above should be posted in that thread. Any complaints should be directed to /dev/null.

[DOSorDIE]

Robots make a party and dont want to fight
After i collect all and give it back to chest it worked.
I had this now a few times.
But sometime it worked without problems.

Robots_Grouping.png (1.12 MiB) Viewed 6197 times

[Nexela]

Robots make a party and dont want to fight
After i collect all and give it back to chest it worked.
I had this now a few times.
But sometime it worked without problems.

I saw this same thing happen on Arumba's playthrough. It looks like they are getting stuck on each other.

[kyranzor]

Next version has increased radius and resolution for finding a valid spawn location. It will not happen anymore. Also the droids and their collision boxes have been reduced in size by 20% which will help too.

[Nexela]

When I do the next update for autofill should I add in guard stations to the autofill list?