A tip: build a "base nanny" early, and add your buildings to the library.

[Blueberry Muffins!]

As soon as I can build a destructor, I put it on a worker bot and set that worker bot's visual register to red so I can always see it. Then when I can build radars I put one in the destructobot, set it to scan for dropped items, wire that to the goto register, and set the bot to store in a trash-bin/sorting storage building. Also: a capacitor does *really* well in that bot.

Ta-daa! Upgrading buildings is easy.

[[Lord] Vader]

Originally posted by Blueberry Muffins!:

Ta-daa! Upgrading buildings is easy.

Well, at least easier. Good tip, but I feel like a lot of the 'depth' of this game is coding basic QOL features in a system it doesn't teach nor provide examples of. I'm torn between liking this extra bit of 'challenge' or deciding it's just too much busywork.

[Blueberry Muffins!]

Couldn't you make the same argument about Factorio's combinators?

I'd say the builder part Desynced is a design-puzzle game like Factorio, but part of what you're constructing is your own equipment. Sure, there's people who don't like Factorio's combinators and avoid them, but . . . there's people who love them too. Games don't have to be to everyone's taste to be widely and well loved.

[Omnipresent Oatmeal]

Originally posted by Blueberry Muffins!:

Couldn't you make the same argument about Factorio's combinators?

Combinators aren't required in Factorio, though. You can use the logic system to make your life easier in some places, but you're never outright required to use them. I've only ever used the logic system once to ensure that my entire oil supply doesn't get slurped up by my lubricant production, but I've done that same thing multiple times without even touching anything from the logic system.
They're a convenient feature to have, but you're not required to use them at any point in a Factorio playthrough unless you have some very specific needs.

Upgrading/deleting/replacing buildings here, though, is painful and doing it in bulk seems to more or less require well-programmed bots just so you can have a feature that's standard in any other factory builder.
Unlike combinators, this is basically a hard requirement unless you want to do a bunch of manual junk in a game about automation.

Unfortunately, things don't even work reliably.
I couldn't even get a basic vacuum cleaner bot to work, since apparently the "pick up" function wasn't mean to pick up the nearest dropped item that the attached radar located using the "dropped item" filter even when the bot is standing literally on top of said item. I somehow convinced it to work for a time, and then five minutes later the same bot was simply chilling on top of some random junk, with the behavior controller running, without picking it up into its empty inventory.

If it's going to be this important and basically everything considered standard in every other factory game is going to be locked behind bot behaviors, then the system needs far better in-game documentation and an infinitely better way to debug.

[Blueberry Muffins!]

Deeply-tweakable settings on complex mechanics à la X4 or AI War or CK2 plus Zachtronics-level automation puzzles is automatically a bad game, got it, no game should or henceforth will ever be built for players who do happen to want that.

[Omnipresent Oatmeal]

Originally posted by Blueberry Muffins!:

Deeply-tweakable settings on complex mechanics à la X4 or AI War or CK2 plus Zachtronics-level automation puzzles is automatically a bad game, got it, no game should or henceforth will ever be built for players who do happen to want that.

See, that's the problem.
Deeply tweakable.
Tweaking mechanics and settings is not the same as having to implement things yourself.

Want to delete a building and put its contents into an inventory in Factorio? You literally just right click it.
Want to delete a building and put its contents into an inventory here? Gotta program a bot specifically to delete a designated building, vacuum the junk on the floor, and place it in a designated storage block. Good luck debugging it, though, because the actual values of variables are hidden during runtime with no proper way to see them.

I've played (and almost finished) basically every Zachtronics game other than Mobius War and Shenzhen I/O. You don't tweak a single thing because the game gives you a toolbox with good documentation and debug systems. You don't have to implement baseline features, like removing an item from the board, yourself.
The toolbox is present here but the documentation and debug is, honestly, complete ♥♥♥♥♥♥♥ ♥♥♥♥.

Theoretically, having a game built around using a worse version of Scratch would be fine if the system for debugging was at all decent.

[Grug]

I would definitely prefer if more basic things could be done with registers and links and reserve the behavior scripting for more complex stuff.

[Blueberry Muffins!]

I agree the docs on many things in this game are lacking. In a finished game I'd even join the "inexcusable" chorus for its current state. That said, the node-graph language is not that hard to figure out, the little oneliners on all the mouseovers, insns, slots, flow exits, they're plenty once you get with the program.

Want to delete a building and put its contents into an inventory here? Gotta program a bot specifically to delete a designated building, vacuum the junk on the floor, and place it in a designated storage block.

wait, what? Way to make something bone simple sound complicated, dude. A base nanny is a beginner exercise, about one cut above Hello, World. Yes, just as with combinators, that first step into thinking with node insns is a doozy, but it's a blast when you get in to it. I kinda wonder whether anybody's going to make a video player in Desynced like DaveMcW did in Factorio.

Loop signal, select nearest, move to. That's *it*. The horror!

https://steamcommunity.com/sharedfiles/filedetails/?id=3022921360

For the debugging, the equivalent of print statements is copy the variable to a parameter register you made just for debugging convenience and read the mouseover.

[Omnipresent Oatmeal]

Originally posted by Blueberry Muffins!:

Loop signal, select nearest, move to. That's *it*. The horror!.

Damn shame it doesn't work.
Watched a bot with those exact commands, plus a "pick up target junk that it's moving to" casually stand there targeting a piece of junk for about 5 minutes without doing anything, and most definitely not moving, before I gave up and sent the piece of crap back to running logistics.

[Blueberry Muffins!]

Works perfectly for me.

Radar component filtering for dropped items, result linked to goto register is the vacuum. No node insn required, that's default radar/goto behavior for everything that moves.

Store register linked to the dropoff point is as usual. No node insn required, it's the default store behavior for everything that moves.

The behavior's parameter register linked to the destructor target register, mark buildings for destruction by setting their signal to "Enemy".

Did you remember to turn it on?

[Omnipresent Oatmeal]

Originally posted by Blueberry Muffins!:

Works perfectly for me.

Radar component filtering for dropped items, result linked to goto register is the vacuum. No node insn required, that's default radar/goto behavior for everything that moves.

Store register linked to the dropoff point is as usual. No node insn required, it's the default store behavior for everything that moves.

The behavior's parameter register linked to the destructor target register, mark buildings for destruction by setting their signal to "Enemy".

Did you remember to turn it on?

I'm guessing, then, that Move Unit can't be used to move the unit to any designated target and instead only to another unit, which I'm assuming is defined to be other bots.

I did the same thing, except instead of assigning the radar output to Go To register, I used the Move Unit function under the assumption that it would, y'know, move the unit.

I don't have the exact behavior file anymore, since I tried a few variations as a direct result of nothing working, but everything I tried depended on the Move Unit function. Glad to see that moving a unit to a specified location is not the intended purpose of the Move Unit function, or at least that I cannot pass a radar's output as its input.
Back to the drawing board, then.

[Blueberry Muffins!]

Glad to see that moving a unit to a specified location is not the intended purpose of the Move Unit function

So, when the mouseover said "Moves to another unit or within range of another unit" , you thought it meant "Moves anywhere or within range of anywhere"?

Watched a bot with those exact commands

I did the same thing, except instead

So, not those exact commands.

And rather than check your understanding or whether the changes you made were what broke it, you never bothered reading even a single sentence of the doc you claim is so awful and come back here claiming you didn't make any changes?

[akos44]

I put my destructorbot on a unit group (Ctrl + number). So I can find it quickly.

[Omnipresent Oatmeal]

Originally posted by Blueberry Muffins!:

So, when the mouseover said "Moves to another unit or within range of another unit" , you thought it meant "Moves anywhere or within range of anywhere"?

Perhaps you missed part of my post where I, at the time, assumed "unit" was a designated target object and not literally just other bots, like a generic "object" type.

Maybe I'm spoiled from working in a language with good documentation and where official functions are named based on what they do, but perhaps it should be called "moveToUnit" instead of "moveUnit". Or, perhaps, datatypes should be clearer, especially on the specific differences between things that appear to have overlap, like "unit" and "bot", and possibly also why "random crap on the ground" isn't in that seemingly catch-all category?

Given the lack of a proper debug system, it wasn't like I had an easy way to telling what was wrong. Probably also because I'm spoiled by having only ever worked with things that throw errors when I pass the wrong type to a function (location instead of unit).

Regardless, now I know where my attempts went wrong. Still, game needs a better debug system. Writing the code in my own IDE and testing it from there would be more intuitive than this Scratch wanna-be.

[Quait]

Watched a bot with those exact commands, plus a "pick up target junk that it's moving to" casually stand there targeting a piece of junk for about 5 minutes without doing anything, and most definitely not moving, before I gave up and sent the piece of crap back to running logistics.

Probably there was Gas in that stack on the ground. bots without a gas canister cant pick that up and it will get stuck because the scanner will always detect that and won't skip it.