Missing flexbility in bot code, make em smarter

[/!\Kapudd im Kopp]

Right now the programming aspect rubs me the wrong way because every bot can only do one thing and it needs to hand learned for everyting and the instruction set is too limited. I want a way for bots to identify the missing ingredients on their own and be able to find them from a world regon even in storage

* find nearest <blueprint>, dont lock, select&lock <ingredient>
* find nearest <ingredient>, include storage
* do until <ingredient.current>=<ingredient.required> : move to [target]; pick up <ingredient>; move to <blueprint>; add to <blueprint>

this lets multiple bots work in concert, increasing efficiency by several orders of magnitude.

[DarthNemesis]

Bots locking individual inputs instead of the entire structure would certainly be nice.

[Sanatey]

I kinda disagree. I honestly prefer to use more bots than using a more complex script.
I'm a programmer, and I find the choise to severely limit the bots "language" is a good design choise on their part. They need to be VERY carefull of what they add. As not to make the entry barrier to big

[/!\Kapudd im Kopp]

Originally posted by Sanatey:

I kinda disagree. I honestly prefer to use more bots than using a more complex script.
I'm a programmer, and I find the choise to severely limit the bots "language" is a good design choise on their part. They need to be VERY carefull of what they add. As not to make the entry barrier to big

maybe theyll add it later for the far future chapters, but i'd really like to generate my pickups dynamicaly. not having expressions is stupid enough and i freaking hate hirachy programming like that.

[Zigmeir]

I really like (move to [target]) from this list. Some kond of gathering point sign we be extremly useful for my building team and all sort Of loading/unloading teams.
Currently you can use move to command, but fixing traget point for several dozens bots is pain in the back, stomach and hands

[Leost]

Originally posted by Zigmeir:

I really like (move to [target]) from this list. Some kond of gathering point sign we be extremly useful for my building team and all sort Of loading/unloading teams.
Currently you can use move to command, but fixing traget point for several dozens bots is pain in the back, stomach and hands

Do you know about signs and billboards?

[Zigmeir]

As far As I undestand, Signs can be used for setting and moving regions. But can bots go to specific sign?

[Leost]

Originally posted by Zigmeir:

As far As I undestand, Signs can be used for setting and moving regions. But can bots go to specific sign?

Bots can go to signs, but that is a bit awkward and generally not very useful. (Essentially for that you would need to teach the bot to pickup the sign, you can remove the actual pick up command leaving it with a search for sign and goto sign command. That's fine if you know the area the sign will be in (which couuld be within the area the sign itself defines) but isn't great for multiple bots since the find command will lock the sign.)

Signs are mostly used to define an area where bots will work within. For instance if you wanted to cleanup all the acorns on the map you could make a bot to do that and then reprogram the bot when it's done with an area, only changing the search area for the acorns, or you could have it search in an area defined by a sign. The sign can defines an area and the area can either be just some specific area you define, or you can link the area to the sign. Linking the area means that the area moves when the sign moves. You could even have one bot walk around with a sign while other bots follow it around doing something in the area defined by the sign (which would be moving relative to the sign moving).

The scripting is missing some things that would make this really useful though. For instance telling bots to move X squares in a direction would let you have the sign mover go over the map in some pattern which would be much better than having to walk the entire map or something. Also if you could find things without locking them you could really do some nice stuff. For instance if you could find acorns in the sign search area without locking those acorns you could have your sign carrier move, stay still until it no longer finds acorns, then move again. But as it is you can't do that because any acorn it finds would be locked from other bots so they would always leave one on the ground and unless you got lucky and that last nut happened to get locked by a cleanup bot before the sign bot you'd have a stuck sign bot waiting forever for that last nut to get picked up.



Going back to the OP though, you could sort of do what you want by putting a work bench down next to a storage bin and then having a bot take the item from the storage and put it on the output square of the work bench, but only when that square is empty. You need the work bench because the bot can pause until the bench is empty before doing that again (you can't do it with a random spot on the ground somewhere because of the locking issue like in the above paragraph). You could infact have a single bot monitor multipe such spots but all your really doing is moving the logic of using a specific storage depot from one bot to another, so I don't think this really helps you. It does let one bot do what you want, but only by having another bot still working in the current manner.

I'd love for the search command to have two options on it. The first would be to not lock what it finds and the second for it to include looking inside boxes to find what it is looking for. That's what you want and the not locking would let all sorts of fun stuff be possible.

[nightinggale]

You can make them smarter and don't lock in the sense that you can add loops, which runs a single time and skips the loop on error. Failure to locate item on the ground is an error, hence it can't be locked in the loop.

I used it for stuff like digging. Repeat once dig up tree stump. Repeat once cover hole. Both inside a repeat until hands empty (lost shovel). The bot will then walk up to a tree stump, remove it and then cover the nearest hole, which just happens to be right next to it. However by making both digging tasks skipable, it can handle having an uneven number of each task. Same with mushrooms. If a bot runs out of mushrooms to harvest, it can dig a hole, try to harvest and if none, then dig a hole etc.

Most of the time it's better to have multiple bots though. Having one bot, which does everything requires a whole lot of memory and it's very slow. Having one bot to turn logs into planks and one to move planks to storage seems to be significantly faster, possibly more than twice as fast. It also allows the "pickup from ground" bot to have upgraded sensors while the other one updates speed, power, backpack, whatever is well suited for what it does.

[Zigmeir]

Originally posted by Leost:

Originally posted by Zigmeir:

As far As I undestand, Signs can be used for setting and moving regions. But can bots go to specific sign?

I just want adjustable moveto command. Move to point specified by [sign].

[Leost]

Originally posted by nightinggale:

You can make them smarter and don't lock in the sense that you can add loops, which runs a single time and skips the loop on error. Failure to locate item on the ground is an error, hence it can't be locked in the loop.

I'm talking about objects getting locked, not bots in a logic issue.

[/!\Kapudd im Kopp]

Originally posted by nightinggale:

Most of the time it's better to have multiple bots though. Having one bot, which does everything requires a whole lot of memory and it's very slow. Having one bot to turn logs into planks and one to move planks to storage seems to be significantly faster, possibly more than twice as fast. It also allows the "pickup from ground" bot to have upgraded sensors while the other one updates speed, power, backpack, whatever is well suited for what it does.

I disagree somewhat. The logic is stupid as its hardcoded, but you can move a bot to the drop off and let it scan for objects to pick up, completely forgoing move-to-object reducing the pickup delay.

[DarthNemesis]

Originally posted by Kapudd im Kopp:

The logic is stupid as its hardcoded, but you can move a bot to the drop off and let it scan for objects to pick up, completely forgoing move-to-object reducing the pickup delay.

Yeah, for my bench saws I've been programming the storage bots to move back to the output tile before they do the next Find, but it's fragile when you set exact coordinates. I'd like to see a drop-down menu on the Move To command for structures where you can select either the input tile or the output tile.

[Zigmeir]

Originally posted by DarthNemesis:

Originally posted by Kapudd im Kopp:

The logic is stupid as its hardcoded, but you can move a bot to the drop off and let it scan for objects to pick up, completely forgoing move-to-object reducing the pickup delay.

Yeah, for my bench saws I've been programming the storage bots to move back to the output tile before they do the next Find, but it's fragile when you set exact coordinates. I'd like to see a drop-down menu on the Move To command for structures where you can select either the input tile or the output tile.

Really like this idea