Pulling out of an apiary ?

[whizzball1]

Set your gate to IF redstone=false THEN pulseGate
No discussion about princesses, drones, ..., just pump permanently.

A not as ticklag heavy option would be to set it to:
Containerxempty = true then Pulsegate.
Do you know why?
When it is set on yours,

1. It must check for a redstone signal every tick and then if there is none,
2. It must check the Inventory for an item and pull it out.

When it is set on mine,

1. It must check for items in inventory, then pull it out.

As it has already checked for the item in the inventory, it need only to pulse.
Two checks per tick are required for yours.
One check per tick is required for mine.

 

[Loufmier]

That's baloney. Easily proven by putting a chunk loader next to them and having everyone log off. They'll still operate despite there being no "clients" to "calculate" their progress.

i`m not sure about this, but dont chunkloader cause them to work on server side?

 

[Hydra]

A not as ticklag heavy option would be to set it to:
Containerxempty = true then Pulsegate.
Do you know why?
When it is set on yours,

1. It must check for a redstone signal every tick and then if there is none

Doesn't matter. WHatever conditions are set they are checked and it doesn't really matter what condition you set. If you set it to check for an empty inventory they're still doing the same work.

 

[Bomb Bloke]

Dunno what the underlying code looks like, but assuming it's efficient it'll be first checking to see if the gate state is true, then if so, checking to see if it can pump. If the gate state isn't true the second check has no reason to be performed, so Occam's Razor suggests that it's not.

The checks are quick, but they add up over the massive amount of ticks the server has to process.

Regarding chunk loaders, they don't shift work away from the client. They merely prevent the server unloading chunks it would otherwise dump due to lack of user presence. If you're unsure, consider: whose client is processing the load of the engines when two users are nearby? If the client gets to dictate their output, then doesn't that open the door for cheaters with hacked clients?

All the client has to do that the server doesn't is render the animations. I think that'd be what the server owner was referring to.

 

[Loufmier]

Regarding chunk loaders, they don't shift work away from the client. They merely prevent the server unloading chunks it would otherwise dump due to lack of user presence. If you're unsure, consider: whose client is processing the load of the engines when two users are nearby? If the client gets to dictate their output, then doesn't that open the door for cheaters with hacked clients?

All the client has to do that the server doesn't is render the animations. I think that'd be what the server owner was referring to.

probably you`re right. i this case the load on server shouldnt be noticeable in this case, because i dont think he`d setup something that would cause strain on server, he`s responsible for.

 

[southernfriedbb]

A not as ticklag heavy option would be to set it to:
Containerxempty = true then Pulsegate.
Do you know why?
When it is set on yours,

1. It must check for a redstone signal every tick and then if there is none,
2. It must check the Inventory for an item and pull it out.

When it is set on mine,

1. It must check for items in inventory, then pull it out.

As it has already checked for the item in the inventory, it need only to pulse.

Two checks per tick are required for yours.
One check per tick is required for mine.

Two checks are not always worse then one, it depends on how the checks are coded. I'm also not entirely sure that the pulse with no redstone signal requires a inventory check, it may just run the pull without. Also given the magnitude of the check any likely impact on a server is going to be negligible.

 

[Bomb Bloke]

The pulse itself requires a check, as you cannot remove what isn't there. The server has to inspect every inventory slot in order to see if the pulse is actually possible and what it's going to spit out - which is a complete waste of time if you're pulsing constantly and the inventory is usually empty.

Again, the extra server work doesn't matter "much". But when enough users start setting up enough constant checks for it to perform you'll start to see the problem. In this case there're less stressful options easily available, so at least on SMP it's polite to use them.

 

[southernfriedbb]

The pulse itself requires a check, as you cannot remove what isn't there. The server has to inspect every inventory slot in order to see if the pulse is actually possible and what it's going to spit out - which is a complete waste of time if you're pulsing constantly and the inventory is usually empty.

Again, the extra server work doesn't matter "much". But when enough users start setting up enough constant checks for it to perform you'll start to see the problem. In this case there're less stressful options easily available, so at least on SMP it's polite to use them.

The problem is that "Items in Inventory" still has to check every tick. Neither option pulls every tick (which would be the most likely place for a performance hit.) Also you don't need to inspect the inventory slot to see if the pulse is possible, you just need to know if there is anything in the inventory at all. Roughly in code terms, you are just checking the length of an array(number of items in inventory), or checking a Boolean value(do I have a redstone signal) + checking the length of the array(number of items in inventory). If there is lag associated with redstone off/pulse option, it's not related to the gate logic.

 

[twisto51]

if you have an alveary with some frames, and bees that have a lifespan of a decent length, you`ll se that delay can be quite noticeable

But since you've automated it from end to end and have at least 16 alvearies working round the clock you never waste your time standing there seeing how long it takes to cycle in a new princess/drone.

 

[Loufmier]

But since you've automated it from end to end and have at least 16 alvearies working round the clock you never waste your time standing there seeing how long it takes to cycle in a new princess/drone.

of course not, but i`em close to 16(cant remember exact number) alvearies, and when combs go to centrifuge in such batches, it may cause lag via overflow, and unused centrifuges most of the time. so i wouldn`t call this setup optimal