Minecraft Forums

Quote from McJty»

<Terrain Islands>, <Biome X>, <Single Controller>

That should do it.

Thanks! worked like a charm.

I think I mostly finished with the basic Modular Storage system. I have more plans in the near future (more on that later) but this is the basis and I want it to be tested well before I put it into a real release because I'm doing some things I haven't done before in order to get this to work.

So if you want to help me test this a bit you can download the latest dev build from here:https://drone.io/github.com/McJty/RFTools/files

Warning! Do not do this on your real worlds or make a backup first.

What kind of feedback am I looking for:

Basic operations. Do you like the GUI, what can be improved. Suggestions and so on.

Does the storage system work well in combination with automated systems as a normal inventory. Does it work well with AE. No unexpected item losses or unexpected interactions.

Does it never under any circumstances delete or duplicate items. This is important of course. This includes things like removing the storage module while the chest is being filled and so on.

Does the system work well with mods like Inventory Tweaks and other mods that add functionality to inventories. I'm already aware of one weird issue with the mouse wheel while scrolling in my list of items. Sometimes it picks up an item there.

I have more plans for the near future but it is possible I will release RFTools in the stage it is right now (if no major bugs are found) and postpone the new features to a future release. Here is a list of plans:

Make remote access to these storage cells possible. To do this I would make a new block that can hold up to 4 storage modules but otherwise has no way to interact with items in the cells. Then there will be a 'remote storage module' which in itself contains no items but which you can link to a 'remote sender' or else to the storage module itself (have to decide that still). Then you can insert this 'remote storage module' in a modular storage block to get access to that remote inventory or else just right click it and have your remote access everywhere in the world (that will require power).

Add various modules for things like bees, thaumcraft aspects, and so on.

The current 'generic type module' is configurable in the rftools config. It has a very limited setup there. This section will have to grow a lot before it can classify enough items to be useful (food, machines, ...).

Quote from McJty»

Hmm that's a very weird error. I have never seen anything like that before. Your minecraft installation seems to have issues with loading the mod. My mod hasn't even had a chance to initialize yet. I don't know what's wrong there but perhaps upgrading forge may help.

At a suggestion from someone on the FTB IRC, I downgraded from 2.83 to 2.82, which fixed the problem. I'll try upgrading forge!

Edit: updated Forge to the current latest version, which... Allowed the game to load. But now I cannot open my world- It just takes me back to the main menu.

Edit: But that's not an RFtools problem! I removed the rftools jar file and reloaded, still wouldn't open my save. Hooboy.

Trying going back to the recommended version, which is what I think I was on before, but I can't be positive.

Regarding the modular screens: Would it be possible to make the background color of a module changeable? I had some trouble with my Inventory checks, since it happens the inventories I wanted to check contained only charcoal blocks. So if there was one charcoal block in there, it was completely invisible on the screen, and else I could see only the number. Also, it would be cool if several screens connected to make one bigger one like Computercraft's monitors do.

BTW, I'm loving your crafters! The most compact compressed-cobblestone generator ever...

OKAY. It works on Forge 1291. Whew, that was fun. The most recent version of my pack is on 1291, but I somehow have a weird hybrid, so I must have retained an earlier version.

Then when I tried to upgrade, I overshot with the most recent build, rather than recommended.

Quote from Ieldra2»

Regarding the modular screens: Would it be possible to make the background color of a module changeable? I had some trouble with my Inventory checks, since it happens the inventories I wanted to check contained only charcoal blocks. So if there was one charcoal block in there, it was completely invisible on the screen, and else I could see only the number. Also, it would be cool if several screens connected to make one bigger one like Computercraft's monitors do.

BTW, I'm loving your crafters! The most compact compressed-cobblestone generator ever...

The modular screens can already be colored. Just put a dye in your hand (lapis, bonemeal, whatever) and right click on the screen to change color.

Quote from Itssnowing»

OKAY. It works on Forge 1291. Whew, that was fun. The most recent version of my pack is on 1291, but I somehow have a weird hybrid, so I must have retained an earlier version.

Then when I tried to upgrade, I overshot with the most recent build, rather than recommended.

Ok, glad you resolved it!

May I suggest to make the "liquid water" dimlet craftable? You're going to need it as often as the "material none" (=stone) dimlet, and it comes up very rarely from the research...

Was curious, does a powered Shield stop wither boss projectiles without breaking?

Quote from Ieldra2»

May I suggest to make the "liquid water" dimlet craftable? You're going to need it as often as the "material none" (=stone) dimlet, and it comes up very rarely from the research...

For liquid water you need 'liquid none' and that is already craftable.

Quote from Foxtails»

Was curious, does a powered Shield stop wither boss projectiles without breaking?

It should

Quote from McJty»

For liquid water you need 'liquid none' and that is already craftable.

OK. That's rather unintuitive btw, given that a dimlet "liquid water" exists. May I suggest to rename the dimlets "Material None" and "Liquid None" to "Material Default" and "Liquid Default" - similarly to the biome controller "Controller Default", so that using all the default dimlets gets you a standard overworld-like dimension? "None" is rather suggestive of, well, nothing, and I'd expect to get a world without liquids if I use "Liquid None".

Yes, the names may not be the best chosen. I'll see about renaming that.

Tested and confirmed, shield also contains the initial wither boss explosion.

Quote from McJty»

It should

Yes I know. I'm (ab)using all of you again for testing purposes

But this is a rather complicated feature to get right and I want to be sure everything is absolutely ok. In the last release you got the modular storage system was mostly working. In this beta I added remote storage support. Basically what is new:

• There is a new Remote Storage Module. This module as such cannot contain items. However, it can be linked to a real Storage Module.
• There is a new Remote Storage block. This block needs energy and can make up to four storages available remotely. To do that you put a real storage item (empty ore filled previously in a normal modular storage block) in one of the four slots. Then you place your remote storage module in the right slot. When you do that it will get linked to the real storage module and you can remove the remote storage module again.
• A linked remote storage module can be inserted in a Modular Storage block just like a normal storage module. From that point on the modular storage block can be used as a normal chest. Inserting or removing items will affect the actual storage module in which is still sitting in the remote storage block. This only works if the remote storage block is in the same dimension OR you enabled global access in the remote storage GUI.
• You can link multiple remote storage modules to the same inventory. In fact you have to do that to make this feature useful. That's basically how you link up different 'chests' to the same inventory.

This was really complicated to get right. So it is possible that some things are not 100% right. You should look out for issues related to:

• WAILA tooltip now showing the right amount of items.
• NEI tooltip hovering on the real storage module (not the remote one) not showing the correct amount of items.
• Front panel of modular storage block not indicating the right amount of items in the block. Note that a green bar means a normal storage module while a yellow bar indicates the storage block is linked to a remote storage.
• Check that items stop being fed into the block if the remote storage is removed, out of power or in a wrong dimension. I tested with enderio itemducts and hoppers.
• Check that everything synchronizes nicely. i.e. inserting an item into block A should also show in block B if both have a remote storage module that refers to the same storage.

One thing that I did not implement is the ability to access the remote inventory by right clicking the remote storage module itself (like an ender backpack). This is something that I still have to do.

The new beta can be downloaded from Curse now:

http://www.curse.com/mc-mods/minecraft/224641-rftools#other-downloads;t1:other-downloads

Again! Don't do this on an established world.

Sorry for all the trouble but I want this to work 100% right before I release this to the world at large. Thanks!

Hmm. I must admit I have never tested the syringe with the ender dragon but were you actually close enough to hit the dragon with it?

Just for clarification before I commit my rarity 6 dimlet: Is it correct that you can disassemble a realized dimension tab in the workbench and if the workbench is infused, you'll get all the dimlets back?

Another question: if you break a dimension's matter receiver and take it back home with you, the dimension will become inaccessible and in fact effectively non-existent. The matter receiver remains available in the destination list since the matter transmitter destinations are determined by specific receivers regardless of where they are at the moment, but you'll be able to re-use it elsewhere and there will be no permanent clutter-up of the destination lists by surplus experimental dimensions. Is this correct? If so, then the only remaining thing to do to delete an unwanted dimension is to delete the its subfolder in the save folder of your world. You don't actually need to do this but it may decrease the CPU/HD resource requirements of your world.

And another one: dimensions stay realized and active if you take the dimension tab out of the builder, they just lose power continuously, right? If so then you can build a power plant within a dimension, take its dimension tab there and power the dimension from within itself. Correct?

Quote from Ieldra2»

Just for clarification before I commit my rarity 6 dimlet: Is it correct that you can disassemble a realized dimension tab in the workbench and if the workbench is infused, you'll get all the dimlets back?

Another question: if you break a dimension's matter receiver and take it back home with you, the dimension will become inaccessible and in fact effectively non-existent. The matter receiver remains available in the destination list since the matter transmitter destinations are determined by specific receivers regardless of where they are at the moment, but you'll be able to re-use it elsewhere and there will be no permanent clutter-up of the destination lists by surplus experimental dimensions. Is this correct? If so, then the only remaining thing to do to delete an unwanted dimension is to delete the its subfolder in the save folder of your world. You don't actually need to do this but it may decrease the CPU/HD resource requirements of your world.

And another one: dimensions stay realized and active if you take the dimension tab out of the builder, they just lose power continuously, right? If so then you can build a power plant within a dimension, take its dimension tab there and power the dimension from within itself. Correct?

On on the first question you seem to be a bit confused. A realized dimension tab can NOT be deconstructed in the dimlet workbench. The dimlet workbench is for deconstructing dimlets. Not dimension tabs. However, you can 'extract' the dimlets back out of a realized dimension tab by using the dimension enscriber instead (and no infusion is needed for that). That way the dimension will not be deleted but you get your dimlets back. Note that without a dimension tab it is not possible to power your dimension. You can later recreate the tab if you need it again.

To properly delete a dimension you can use the /rftdim safedel <id> command and then delete the dimension folder from disk. That will also remove the destination from the list but you are right that you can also manually get the receiver from the dimension. But don't try to delete the dimension folder without first doing /rftdim safedel.

A dimension that is not active will still constantly drain power UNLESS it contains an Activity Probe. That's a useful block to have in a dimension which makes sure dimensions that are not in use don't consume power. And yes, you can power a dimension from within itself but that can be dangerous if for some reason the power generation fails and you end up with a dimension that no longer runs.

Here some feedback on the dimlet filter. I have attempted to use it to sort my dimlets by type but I gave up on it. There are several problems:

(1) A dimlet that fits none of the defined output sides will stay in the filter even if there is an output side with no condition set. Which means I can't simply pump my dimlets into one side and route them through consecutive additional filters to be sorted, but I must filter at the input. This needs about 12 additional conduits (there are 12 dimlet types) and - more to the point, 12 additional block spaces.

Suggestion: it would be nice if dimlets that don't fit any condition set for a side would be sent to an output slot with no set condition if there is one. (Edit: I just realized that this may already work and the reason my dimlets stayed in the filter is related to the next point since when I encountered this problem first I assumed output would be automatic)

(2) Even worse: the filter doesn't automatically output. Which means that again, I need additional conduits that extract the dimlets from their respective sides (I attempted to place the filters next to the destination containers to output directly into them first, before I noticed that this doesn't work). This also means that any attempt to stack filters will be awkward since I need conduits between them.

Suggestion: it would be nice if the filters would automatically output.

All this means that the most space-efficient setup to sort my dimlets will need 6 filters set in a row close to each other, with two sides taking in one dimlet type each from conduits, and another pair of conduits pulling them out of the two other remaining usable sides and sending them to their destination. This is a 3x3x6 space taken up by the filtering system...With automated output, this could be reduced to 2x2x6, and with dimlets fitting no output being sent to an undefined output it could be reduced to 2x1x6.

This is RFTools v2.83 in the Resonant Rise modpack.

Addendum: this may be a bug: if I place a dimlet filter and pick it up again, the description says "contains 9 stacks" or something to that effect, even if all the slots are empty. Also, filters placed and picked up again will not stack even if they're all empty.

Auto extract is something that I might do.

Filters picked up and not stacking is normal MC behaviour since a filter gets NBT information once it is put down. Even if empty.

I'll check if I can reproduce the 9 stacks of something bug.