[2.0.12] Spidertron equipment disappears when placed by bots (MR)

[Mouldy]

2.0.12 experimental
Repro:

1. Place equipment in a spidertron and store it in a logistics chest
2. Pipette the spidertron to place a ghost for bots to place
3. When placed, all equipment in the spidertron is gone

[Rseding91]

Thanks for the report however I can not reproduce this. When I do it, the ghost is built, and then construction robots come along and remove all of the equipment placing it into the logistics system for storage. Can you provide a save file where this happens?

[Mouldy]

Ah, I can confirm that the equipment was placed into storage. So it did not disappear, it was simply removed from the spidertron. I must not have noticed the bots pick it up.

Is this intended? It seems quite annoying to try to get around this behavior with blueprints, especially if the spidertrons are pre-equipped when in storage (As there's no way to tell which one will be pulled out by the bots, and if the equipment it needs is inside another spider)

[Rseding91]

It's "intended" in that a more complex solution was deemed not worth the code complexity and performance overhead. Normally you don't store spidertrons in logistics storage pre-configured. Normally once built, a spidertron just *stays* in the world as is. If you make blueprint copies of them, they will come pre-equipped with ghost requests for the equipment the original one had and that will be installed once built.

[Mouldy]

That's understandable. I was hoping to be able to remote deploy spidertrons without having to physically be present on the planet, but that is still technically possible with existing systems, just have to pipette->deconstruct->place blueprint and it should work, as everything would be in logistic storage at that point.

I suppose this report can be closed then.

[credomane]

It's "intended" in that a more complex solution was deemed not worth the code complexity and performance overhead. Normally you don't store spidertrons in logistics storage pre-configured. Normally once built, a spidertron just *stays* in the world as is. If you make blueprint copies of them, they will come pre-equipped with ghost requests for the equipment the original one had and that will be installed once built.

I know this is a really old thread but thought I'd post a year later update. My feelings on the matter haven't really changed since first running in to this quirk/problem and the other threads/comments I've seen of people also running afoul of it.

I don't mind that the pipette picks and/or places a blank/default spidertron ghost.
I don't mind that the bots pickup any spidertron from storage instead of the exact one to fulfill the ghost construction request. (that would be a huge code complexity commitment and performance hit to implement. I assume this is what you were referring too)
I do, however, greatly care that a perfectly configured spidertron is stripped because bots used it to revive a "default/blank" spidertron ghost.

Surely it isn't too complex to do a check when reviving a ghost. Could even limit it to only things that inherit the "VehiclePrototype" prototype (locomotives, cargo wagons, fluid wagons, car, tank, spidertron. plus any modded vehicle) if that would reduce any performance loss.

Code: Select all

//Right before reviving the ghost run this "check".
//Right before, as in, there are no more lua script/events that could prevent the revive and
//  the engine guarantees at this point the revival will succeed.
//  The only way it fails is an uncaught C++ exception and/or crash to desktop.

//The "config" in this case refers to any custom name, color, equipment grid and logistic requests.
if ghost.has_prototype("VehiclePrototype") and ghost.config == 'default' then
	ghost.config = revive_item.config
end

//Complete the ghost revival.
//Fire off whatever post-ghost-revive / bot-build lua events there are, as normal.

Expected end results with this added if check?

If a pre-configured spidertron is used to revive a pre-configured spidertron (like from a blueprint) it will "revive" as the blueprint spidertron and bots will and/remove equipment as needed to fix it up exactly like it behaves now.
The difference being that if a pre-configured spidertron is used to revive a "blank" spidertron ghost (aka from the pipette/ghost-picker) then it will "revive" as the pre-configured spidertron the bot is using for the revival.

Even after a year this "gotcha" still gets me every single time and causes confusion/headaches (just like when Gleba's spoilage finds, yet, another novel way to break the planet). I always play with the Equipment Gantry mod. So all of my tanks/spidertrons come off the line pre-configured with equipment. Even when not using that mod I still manually configure a spidertron, manually ship it to another planet and then get surprised later thinking everything got deleted when I eventually remote view the planet and hour or so later and spot the default spidertron knowing I've never shipped a blank one there. Eventually, I remember this thread while looking at autosaves hoping to find one before the equipment was deleted. Oh yeah, not deleted, everything's been returned to storage. Tell myself quit using the pipette for this you dummy and then proceed to use the pipette again the next time because it has nearly decade of muscle memory behind it now.


Sure blueprints are a workaround. Sure using shift while using the copy-paste tool is another workaround. However, until I get bit in the butt by this quirk and remember to use them for this one exact quirk, I always find myself expecting to get my configured spidertron not a generic spidertron. I pretty much never expect (outside of the first couple before I setup equipment gantry) or want to get blank spidertron when I give bots order to build one.