Rseding91 wrote: Tue Oct 29, 2024 9:50 pm
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.