Messages

My original idea was some kind of inline item-packing device, but I'm currently working on a 'Picker' that grabs from adjacent storage (like stockpiles or MD2's bins). This can be combined with Unloaders and stockpiles/bins to make inline storage. But I don't want to just be continually cycling the stuff though and wear out my belts, so I'm trying to make it dispense only when needed. I think as a first approximation though, I'm just going to make a sensor to put in the destination cell and just trigger Pickers on a very slow cycle. It'll over-dispense sometimes, but it's a lot less work!

Okay, what I want to do is find the list of all items that are on any belt component that's potentially downstream from me. Is the best way to just brute force walk down the entire belt, one segment at a time, and add up all the stuff I find?

I'm thinking about building an inline storage part (similar to MD2's storage bins, but directly on the belt) that automatically dispenses a stack of the stored item onto the belt when both the belt and a designated stockpile are empty of that item. What's the best way for me to try to query the items that are currently riding within the entire belt system, or at least within a given segment of belts?

The auto seller doesn't seem to want to sell my sculptures. I have a rule for "Any Art Made From Any Materials" (I also tried "Any Sculpture"), but the sculptures just pile up in my storage room. If I manually select them to sell, the Auto Sell button will unselects them, like it's trying to maintain their levels as they are. It's working great for everything else. Maybe because sculptures are minified in storage?

It should work, but I've been away from rimworld for a while. I'll check tonight to be sure though.

Im thinking it seems that once you leave a game and load it it has trouble remembering the ID's or something and when you rebuilt the duct it reset its ID tag or whatever so it knew what it was supposed to do. Im no expert on this stuff but thats my best guess. Seems like a minor annoyance considering that it is at least playable when it otherwise would not be at all.

The linking code is based on an earlier version of Signals, so I know a bit about it Networks don't actually exist across saving/loading, they are rebuilt each time as the components spawn in - when one component spawns, it immediately connects to any connectable adjacent component. The net IDs are mostly to make it easier for the player to sort out what's connected to what (though, they are used internally for some net merge/split operations). This is also why IDs seem to be all over the place, and skip large ranges at times. I've had the most trouble with the crossover duct, and I'm pretty sure it's a bug I've already fixed in Signals, but I don't recall exactly when/where it was now unfortunately (I think it was during A10) Note though that this means you can sometimes repair broken nets by exiting the game and reloading!

When I finish my current round of updates/improvements to Signals, I'm going to try to bring ReditHeat's networking backend up to date, hopefully in a way that allows easier sharing of changes between the two. (That is, assuming Latta doesn't beat me to that update!)

I haven't used the A11 build, but I had no end of trouble with things linking/not when they should/shouldn't in A10. Perhaps Latta needs to grab a more recent version of the linking code from Signals? I've fixed a ton of strange linking bugs since this forked off! I'm not sure how easy that is to do though, given the significant changes that were made on both sides since then...

First, this is a terrible, awful, horrible thing to do, and should never ever be done. I love it.

Second, wouldn't it be better to use IL Opcodes instead of raw x86, in hopes of a little portability? Or does this hack only work after JIT, and thus too late for IL?

And finally, I'd imagine this doesn't work all too well with DEP enabled?

I swear, this mod isn't abandoned! Updated to A11, in first post.

Last time I used WinRar (which was many years ago, admittedly), it was rather bloaty, and was only a trial for free, has this changed? That was my reason for switching to 7zip, and I've never bothered to look back since it hasn't failed to deal with anything I've thrown at it (which is not a short list...).

And I disagree with you: One tool that does everything is better than a couple dozen "native" tools, because it's easier to keep the system up to date!

Not sure about on a mac, but for Windows/*nix, 7-zip will open anything: http://www.7-zip.org/

It looks like the list comes from code, so it's non-trivial for us mere mortals to change:

Code Select Expand


// RimWorld.Dialog_AdvancedGameConfig
private static readonly int[] MapSizes = new int[]
{
200,
225,
250,
275,
300,
325,
350,
400
};

[...] Eventually I'm also hoping to [...] make some components that link with the A2B belts to allow smarter thing-routing.

That sounds like a great idea. Let's get in touch when you get to that stage to make it happen one way or another. By then, the A2B mod should have reached a new stable level with underground belt instead of teleporters. And (hopefully) food degradation.

I'm in the middle of some upgrades to the Pressure Plate (so it reports the stack count in it's square as a 9-bit signal), and adding in some higher-order logic components (specifically, 3/9 bit comparators and constants), but once I finish those I'll probably be work on this next, and you'll definitely hear from me if I run into trouble making the belts do what I want!

The biggest problem I see so far is that the building class(es) for the belt components I want will have to reference both the A2B assembly, and the Signals assembly, which means it can't be included in either without then requiring the other be present. I'll probably end up doing it as a separate "integration" mod that must be loaded after the two "base" mods.

There is a size option when generating the world, and the "Advanced" button when selecting a colony site allows you to set the size of your colony-map. You want one of these, but it's unclear from the wording of your question which.

Updated OP: Updated to A10(c), and added wide (3x and 9x) conduit and Mux/Demux components. I'm not super happy with the inconsistent ordering of bits when a wide signal turns corners before being split back apart, but I haven't come up with a good way to handle that yet.

I also made some major architectural changes to how signals are implemented to do this, including adding a custom properties class to give options to CompSignal in the XML, and collapsing all (except for Source) back into CompSignal directly.

I think my next changeset will be some more useful sensors, especially now that Tynan has taken away the last of our manual power controls...

EDIT: Don't lay signals of different widths directly against each other in this release, they'll try to connect and throw errors.