Skip to content

Commit

Permalink
undo monitor ticking limit
Browse files Browse the repository at this point in the history
  • Loading branch information
@PrototypeTrousers
PrototypeTrousers committed Feb 21, 2021
1 parent d25a8a5 commit e50eb79
Showing 1 changed file with 1 addition and 4 deletions.
5 changes: 1 addition & 4 deletions src/main/java/appeng/me/cache/NetworkMonitor.java
View file
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,6 @@ public class NetworkMonitor<T extends IAEStack<T>> implements IMEMonitor<T>
private boolean hasChanged = false;
@Nonnegative
private int localDepthSemaphore = 0;
private boolean ticked;

public NetworkMonitor( final GridStorageCache cache, final IStorageChannel<T> chan )
{
Expand Down Expand Up @@ -140,10 +139,9 @@ public int getSlot()
@Override
public IItemList<T> getStorageList()
{
if( hasChanged && ticked )
if( hasChanged )
{
hasChanged = false;
ticked = false;
this.cachedList.resetStatus();
return this.getAvailableItems( this.cachedList );
}
Expand Down Expand Up @@ -328,7 +326,6 @@ void forceUpdate()

void onTick()
{
ticked = true;
if( this.sendEvent )
{
this.sendEvent = false;
Expand Down

2 comments on commit e50eb79

@trishume
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing you realized this caused bugs where if storage changed twice in one tick and then not in further ticks level emitter updates could be indefinitely delayed.

I think solving the level emitter performance issue is definitely tricky without changing the current 0-tick delay of level emitters, which may actually be part of why they break with redstone conduits, because they can update their redstone state multiple times in a single tick. I have some contraptions that rely on level emitters being faster than the 5 tick update cycle of Gregtech conveyors/pumps but nothing that relies on them being 0-tick, and I bet nobody else relies on that either, so it may make sense to have level emitters update on a one tick delay. Same theory as redstone torches, your output needs to be based on multiple factors determined by the ticks of different things, so you need to delay if you want to combine all of that reliably.

A way to implement the 1 tick delay solution might be to have postChange and other things just schedule the need for an update in some kind of after-all-the-ticking event phase, where you then call getAvailableItems() but you can't update the redstone since it's not a valid time to cause ticks, so you just store the needed redstone state and then maybe do a redstone update on the next tick.

@PrototypeTrousers
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty much it lol.
and implementing the storage drawers slotless item handler alleviated some of that cost so it was not worth to keep it.

Please sign in to comment.