The config file option that limits the number of chunks a player can load: Is that server-wide, or does it just limit the maximum size of any one chunkloader?
The dimensional-anchor.log file on my server hit 2gb yesterday in about a week.
It has hundreds of these entries per second:
[2012-08-07 11:54:20] Loaded world info for outlands
[2012-08-07 11:54:20] Loaded world info for nether
[2012-08-07 11:54:20] Loaded world info for world_griefed
[2012-08-07 11:54:20] Loaded world info for frontier
[2012-08-07 11:54:20] Unloaded world info for outlands
[2012-08-07 11:54:20] Unloaded world info for nether
[2012-08-07 11:54:20] Unloaded world info for world_griefed
[2012-08-07 11:54:20] Unloaded world info for frontier
And that's all it has, over and over and over and over and over...
The config file option that limits the number of chunks a player can load: Is that server-wide, or does it just limit the maximum size of any one chunkloader?
Just a quickie regarding the buffer block. Would it be possible to add a mode so that it increases in speed based on the number of occupied slots? So when all full it is 0.5 pulse, all empty 5 sec pulse, and ramp it up .. something like...
Yup. I disabled logging, not a big deal. THanks for the reply. The server-wide limit is pretty darn spiffy, I'm extremely pleased to see that...
It will probably break chunk loaders in those worlds, by the way. And might cause extra server load (although I'm not sure how much, and nobody's told me about it causing problems with that)
Coding error found with the retrievulator : rather than storing as a state variable the current redstone state of the retrievulator, you just have a line that inverts the current redstone state of the retrievulator.
Unfortunately, this lazy trick breaks it in many situations, because if there is ANOTHER retrievulator adjacent, it gets confused and no longer cycles. (because it receives power from the adjacent one, and mistakenly thinks it is emitting power)
Also, your code is a real mess. Just a nightmare of flags and not symbols. And it gets called way to often, and doesn't do any caching. I'm tempted to try to fix it.
1. Is it intended, that the ACT2 cannot have a Tubeconnection to the Topside? So that i can use Retrievers to extract the Items.
That's visual only. When there's nothing in the output slot, it pretends there is no output slot so you can't put things in it accidentally. It has the side effect that tubes sometimes don't look like they connect.
2. Could you fix that first-degree-Redstonesignal from the Retrievulator, by making it second-degree? Because otherwise i cant use Filters, to extract things out of the ACT2. (I mean that extremly strong RS-Signal)
I tried doing that, but I couldn't find a way to make it work. I know you're a modder too; if you have any idea how to emit a weak redstone signal please tell me.
3. Is it possible to add a Redstonemode, which prevents constant Redstonesignal, when the Retrievulator is stuffed? Its interferring with the Filter ontop of the ACT2. You could also just make the ACT2 transparent, to not let it conduct Redstonesignals through it.
Emitting a weak redstone signal would also fix that, right?
Also, added versions to the topic title at FuzzyPurp's request.
GregoriusT / Immibis : the "can't put stuff in" behavior is essential, and needed. However, there's another way to implement this. Give the output of the ACT2 TWO output slots. The first slot always exists, preventing the visual bug. The second slot only exists when there is a valid output in it. This way the tubes always connect, allowing 1 slot to fill with random crap, leaving the other slot reserved for actual crafting outputs.
Another thing : immibis : make absolutely certain your code for the retrievulator inserts the retriever jammed BEFORE removing the last item from the retriever. With mag tubes, items move so fast that even a 1 tick delay is enough to let the retriever accept some random item. This is because mag tubes accelerators can connect directly to retrievers (something you probably don't test it with)
Coding error found with the retrievulator : rather than storing as a state variable the current redstone state of the retrievulator, you just have a line that inverts the current redstone state of the retrievulator.
Guess what redstone_output is? It's a state variable with the current redstone state of the retrievulator.
Also, your code is a real mess. Just a nightmare of flags and not symbols. And it gets called way to often, and doesn't do any caching. I'm tempted to try to fix it.
I fixed that visual Bug of the ACT2 with Redstonetubes, which seemingly ever connect to it, and that thing with "cannot put accidently Stuff in", is not really needed and i know absolutely no other Machine, which has that behaviour.
Furnaces and furnace-like machines from other mods, such as macerators, can have their output blocked if a retriever requests too many items and the excess items flow backwards to the nearest valid inventory.
GregoriusT / Immibis : the "can't put stuff in" behavior is essential, and needed. However, there's another way to implement this. Give the output of the ACT2 TWO output slots. The first slot always exists, preventing the visual bug. The second slot only exists when there is a valid output in it. This way the tubes always connect, allowing 1 slot to fill with random crap, leaving the other slot reserved for actual crafting outputs.
Then you have either an invisible slot where your stuff can go without warning where it's almost impossible to find (hey, what happened to that stack of red matter?) or an extra GUI slot with no real purpose.
@BrickedKeyboard: Better Idea. Your additional Slot, but Invisible and already filled with "random Crap" like the Retrieverjammer, with the same ID, but with another Damagevalue (So that it doesnt get pulled by jammed Retrievers).
And then everyone who uses filters or transposers for output gets their tube network flooded with retriever jammers.
And why has the Retrievulator only a 127-Limit? Is there a Barrier Codewise? The 63-Stack of Cobble in my Projecttable looks very annoying.
The default saving of item stacks can't handle stacks bigger than 127. The network protocol also can't handle them. Possible but difficult to overcome.
The Meaning of Life, the Universe, and Everything.
Join Date:
6/29/2012
Posts:
50
Member Details
I've tried a transposer, and a filter, to take items out of the bottom of my ACT2, but neither one does it, the buckets just stay in the red inventory line.. any suggestions?
I've tried a transposer, and a filter, to take items out of the bottom of my ACT2, but neither one does it, the buckets just stay in the red inventory line.. any suggestions?
Did you power it with redstone pulses? It's not automatic like the buffer.
Immibis Core 49.2.1 fixes crashing when placing any microblock, and fixes the transparency on the saw.
Please understand : I'm not some coding snob. I don't care what a piece of code looks like, only that it works and isn't too cpu intensive. And I appreciate what you've done to make the retrievulator possible, when it works it is quite neat to use and it massively simplifies things.
HOWEVER, in it's current state the retrievulator is broken to the point of being useless. It has several major bugs, the most severe being that it will trigger retrievers with empty inventories. (your code to send redstone signals is out of sync with the code that puts the retriever jammer in)
Also, the strong redstone signal problem, and of course the frequent pulse rate. Look, every time a retrievulator pulses the retriever is it connected to has to search the ENTIRE pipe network for the desired item. Even if that item is nowhere to be found, just like it was half a second ago when the last pulse was sent. Large numbers of retrievulators will cause massive lag if used on a multiplayer server with a lot of players.
Every 5 ticks is too often if you are scanning an entire target inventory (like a diamond chest) every time. I was thinking about how to optimize it, and I would make the update speed variable.
If the retrievulator has not succeeded in receiving an item for a long time, the update interval would slow down to a much longer interval. This way, idle retrievulators would not update as often as ones in busy use.
On the other hand, a retrievulator that has been receiving an item often (because it got used for whatever reason) would lower it's update interval to the redpower speed limit of every 8 ticks.
Also, retrievulators need to be smarter so they don't retrieve excess items. This is a simple calculation to make.
And they ought to rotate themselves to face the correct direction, since adding a screwdriver like item to tubestuff is not a good idea, and eloraam won't let you link to hers. Basically they would rotate themselves to the first retriever that is adjacent to them, unless they are already rotated to face a retriever.
And there's some caching tricks I have thought of as well.
Anyways, the way your code is written, a small upgrade isn't possible. The whole thing has to be refactored. I'm willing to work on it if you're willing to use the improvements.
The calculation to prevent excess item retrievals is simple.
It's (Target_size - Current_inventory) / retriever_stack_size. Iterate through multiple items to find the lowest of these numbers.
The retriever would do bursts of pulses with no more pulses than the formula I just gave. It would then wait 5-10 seconds for items to show up. And then another burst, and so on.
Greg : if you use mag tubes, 5-10 second time delays would be fine. If you aren't using mag tubes, there's your problem.
Summing up multiple stacks is an obvious thing to add in a rewrite of the retrievulator code.
Another thing I'd like to do that isn't in the retrievulator directly is to figure out a way to make the retriever jammer item self destruct. Or, at the minimum, make sure that when a retrievulator is broken is will not drop retriever jammers.
I have to ask, do the Black Hole Chests play nice with BC and Logistics Pipes in terms of page creation? I plan on using these as upgrades for my diamond/crystal chests.
I'm still learning about RP (I'm learning a lot from you Greg over on the IC2 forums though)
Edit: Btw, you could make the Blackholechest sorting items automatically after amount, so that Items with low amount are getting on the first Pages, while massitems (multiple Stacks) are going to the last Pages.
Possibly, but sorting your chests shouldn't be my problem.
I have to ask, do the Black Hole Chests play nice with BC and Logistics Pipes in terms of page creation? I plan on using these as upgrades for my diamond/crystal chests.
I'm still learning about RP (I'm learning a lot from you Greg over on the IC2 forums though)
Immibis, you seem to be ignoring me. Is this on purpose or did you not read my posts?
Sorry. It's not on purpose.
I couldn't find or even reproduce the bug where there's a delay between removing the items and inserting the retriever jammer allowing other items to enter the retriever. Were your retrievers in slider or non-slider mode?
The config file option that limits the number of chunks a player can load: Is that server-wide, or does it just limit the maximum size of any one chunkloader?
The dimensional-anchor.log file on my server hit 2gb yesterday in about a week.
It has hundreds of these entries per second:
[2012-08-07 11:54:20] Loaded world info for outlands
[2012-08-07 11:54:20] Loaded world info for nether
[2012-08-07 11:54:20] Loaded world info for world_griefed
[2012-08-07 11:54:20] Loaded world info for frontier
[2012-08-07 11:54:20] Unloaded world info for outlands
[2012-08-07 11:54:20] Unloaded world info for nether
[2012-08-07 11:54:20] Unloaded world info for world_griefed
[2012-08-07 11:54:20] Unloaded world info for frontier
And that's all it has, over and over and over and over and over...
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's server-wide.
Known and fixed, but I'm guessing you're using Tekkit?
Yup. I disabled logging, not a big deal. THanks for the reply. The server-wide limit is pretty darn spiffy, I'm extremely pleased to see that...
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt already does do something like that.
It will probably break chunk loaders in those worlds, by the way. And might cause extra server load (although I'm not sure how much, and nobody's told me about it causing problems with that)
Unfortunately, this lazy trick breaks it in many situations, because if there is ANOTHER retrievulator adjacent, it gets confused and no longer cycles. (because it receives power from the adjacent one, and mistakenly thinks it is emitting power)
Also, your code is a real mess. Just a nightmare of flags and not symbols. And it gets called way to often, and doesn't do any caching. I'm tempted to try to fix it.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's visual only. When there's nothing in the output slot, it pretends there is no output slot so you can't put things in it accidentally. It has the side effect that tubes sometimes don't look like they connect.
I tried doing that, but I couldn't find a way to make it work. I know you're a modder too; if you have any idea how to emit a weak redstone signal please tell me.
Emitting a weak redstone signal would also fix that, right?
Also, added versions to the topic title at FuzzyPurp's request.
Another thing : immibis : make absolutely certain your code for the retrievulator inserts the retriever jammed BEFORE removing the last item from the retriever. With mag tubes, items move so fast that even a 1 tick delay is enough to let the retriever accept some random item. This is because mag tubes accelerators can connect directly to retrievers (something you probably don't test it with)
Yes. The "fake items" are being rendered by your minecraft client as if they were real items.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGuess what redstone_output is? It's a state variable with the current redstone state of the retrievulator.
Yes.
Yes.
Is every 5 ticks too often?
Yes.
Ok.
Furnaces and furnace-like machines from other mods, such as macerators, can have their output blocked if a retriever requests too many items and the excess items flow backwards to the nearest valid inventory.
Then you have either an invisible slot where your stuff can go without warning where it's almost impossible to find (hey, what happened to that stack of red matter?) or an extra GUI slot with no real purpose.
And then everyone who uses filters or transposers for output gets their tube network flooded with retriever jammers.
The default saving of item stacks can't handle stacks bigger than 127. The network protocol also can't handle them. Possible but difficult to overcome.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDid you power it with redstone pulses? It's not automatic like the buffer.
Immibis Core 49.2.1 fixes crashing when placing any microblock, and fixes the transparency on the saw.
HOWEVER, in it's current state the retrievulator is broken to the point of being useless. It has several major bugs, the most severe being that it will trigger retrievers with empty inventories. (your code to send redstone signals is out of sync with the code that puts the retriever jammer in)
Also, the strong redstone signal problem, and of course the frequent pulse rate. Look, every time a retrievulator pulses the retriever is it connected to has to search the ENTIRE pipe network for the desired item. Even if that item is nowhere to be found, just like it was half a second ago when the last pulse was sent. Large numbers of retrievulators will cause massive lag if used on a multiplayer server with a lot of players.
Every 5 ticks is too often if you are scanning an entire target inventory (like a diamond chest) every time. I was thinking about how to optimize it, and I would make the update speed variable.
If the retrievulator has not succeeded in receiving an item for a long time, the update interval would slow down to a much longer interval. This way, idle retrievulators would not update as often as ones in busy use.
On the other hand, a retrievulator that has been receiving an item often (because it got used for whatever reason) would lower it's update interval to the redpower speed limit of every 8 ticks.
Also, retrievulators need to be smarter so they don't retrieve excess items. This is a simple calculation to make.
And they ought to rotate themselves to face the correct direction, since adding a screwdriver like item to tubestuff is not a good idea, and eloraam won't let you link to hers. Basically they would rotate themselves to the first retriever that is adjacent to them, unless they are already rotated to face a retriever.
And there's some caching tricks I have thought of as well.
Anyways, the way your code is written, a small upgrade isn't possible. The whole thing has to be refactored. I'm willing to work on it if you're willing to use the improvements.
It's (Target_size - Current_inventory) / retriever_stack_size. Iterate through multiple items to find the lowest of these numbers.
The retriever would do bursts of pulses with no more pulses than the formula I just gave. It would then wait 5-10 seconds for items to show up. And then another burst, and so on.
Summing up multiple stacks is an obvious thing to add in a rewrite of the retrievulator code.
Another thing I'd like to do that isn't in the retrievulator directly is to figure out a way to make the retriever jammer item self destruct. Or, at the minimum, make sure that when a retrievulator is broken is will not drop retriever jammers.
I'm still learning about RP (I'm learning a lot from you Greg over on the IC2 forums though)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIntended but missing from the OP - OP is fixed now.
They do whenever they get unloaded.
Possibly, but sorting your chests shouldn't be my problem.
As far as I know they do.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSorry. It's not on purpose.
I couldn't find or even reproduce the bug where there's a delay between removing the items and inserting the retriever jammer allowing other items to enter the retriever. Were your retrievers in slider or non-slider mode?
If you can fix any bugs, I will use your fixes.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI don't think so, but you can do it manually. I'll add that to the OP.