Applied Energistics 2

Applied Energistics 2

137M Downloads

Inscribers accept wrong items

tomevoll opened this issue ยท 13 comments

commented

Inscribers with a press that will not accept the wrong metal/item when trying to insert it in the gui, will return true that the item is valid and allow insertion with a hopper or any other pipe.

As an example you can insert redstone to a Logic press with a hopper, but not in the gui.

commented

appliedenergistics2-rv3-alpha-13
forge 1.7.10-10.13.4.1558

commented

first, please update to the beta branch, the alpha is waaay outdated
as far as i remember this is a normal bahaviour, you will have to to some brain work to get your setup flawless and not wasting energy (when your output buffer is full, the last cycle will not finish and permanently consume energy, this is by design)

commented

not sure what you mean by wasting energy, it wont make anything with the wrong items inserted or run at all from what i can see, energy usage says 0, redstone is not a valid item for that slot if a logic pres is in it, i also did another test and if using a hopper or a pipe you can pipe whatever you like into that slot, ,the gui prevent you from inserting it, but there seem to be missing a check when pipes try inserting items, not sure why you would let invalid items enter the slot by design, its the input slot not output slot, output slot is empty.

commented

I've never seen a cycle 'start' with invalid items. That's either a bug or pretty new.

The ability to insert the wrong items is intentional at this point. It makes automating the inscriber more complicated and an interesting challenge later on, and still pretty simple to set up a semi-automatic system with hoppers. Just put in the right press and however many items you want to make, and keep hopper logic in mind when filling any chests with multiple items.

commented

2016-07-26_10 46 45
2016-07-26_10 47 02

tested in beta 6

commented

as i said, GUI is the one thing, pipe injection (afaik) is not checked
it is kind of to force you to build an intelligent contraption around it to automate it :) this has been discussed several times (also by me) but rejected so far
and by wasting energy i mean the following:

  • put a valid press recipe in there, and let the output fill up
  • see how the next production cycle starts but never ends, still consuming the energy
commented

A cycle does not start with the wrong items.
If the ability to insert any items is by design there is no bug :)

commented

Item insertion by pipes isn't checked for performance reasons.

commented

Well, technically this could be fixed, but it is true that it is a bit more costy in terms in performance. Compare

final ItemStack top = this.ti.getStackInSlot( 0 );
final ItemStack bot = this.ti.getStackInSlot( 1 );
if( s == this.middle )
{
for( final ItemStack optional : AEApi.instance().registries().inscriber().getOptionals() )
{
if( Platform.isSameItemPrecise( optional, is ) )
{
return false;
}
}
boolean matches = false;
boolean found = false;
for( final IInscriberRecipe recipe : AEApi.instance().registries().inscriber().getRecipes() )
{
final boolean matchA = ( top == null && !recipe.getTopOptional().isPresent() ) || ( Platform.isSameItemPrecise( top, recipe.getTopOptional().orNull() ) ) && // and...
( bot == null && !recipe.getBottomOptional().isPresent() ) | ( Platform.isSameItemPrecise( bot, recipe.getBottomOptional().orNull() ) );
final boolean matchB = ( bot == null && !recipe.getTopOptional().isPresent() ) || ( Platform.isSameItemPrecise( bot, recipe.getTopOptional().orNull() ) ) && // and...
( top == null && !recipe.getBottomOptional().isPresent() ) | ( Platform.isSameItemPrecise( top, recipe.getBottomOptional().orNull() ) );
if( matchA || matchB )
{
matches = true;
for( final ItemStack option : recipe.getInputs() )
{
if( Platform.isSameItemPrecise( is, option ) )
{
found = true;
}
}
}
}
if( matches && !found )
{
return false;
}
}
if( ( s == this.top && bot != null ) || ( s == this.bottom && top != null ) )
{
ItemStack otherSlot = null;
if( s == this.top )
{
otherSlot = this.bottom.getStack();
}
else
{
otherSlot = this.top.getStack();
}
// name presses
final IItemDefinition namePress = AEApi.instance().definitions().materials().namePress();
if( namePress.isSameAs( otherSlot ) )
{
return namePress.isSameAs( is );
}
// everything else
boolean isValid = false;
for( final IInscriberRecipe recipe : AEApi.instance().registries().inscriber().getRecipes() )
{
if( Platform.isSameItemPrecise( recipe.getTopOptional().orNull(), otherSlot ) )
{
isValid = Platform.isSameItemPrecise( is, recipe.getBottomOptional().orNull() );
}
else if( Platform.isSameItemPrecise( recipe.getBottomOptional().orNull(), otherSlot ) )
{
isValid = Platform.isSameItemPrecise( is, recipe.getTopOptional().orNull() );
}
if( isValid )
{
break;
}
}
if( !isValid )
{
return false;
}
}
return true;

with

if( this.isSmash() )
{
return false;
}
if( i == 0 || i == 1 )
{
if( AEApi.instance().definitions().materials().namePress().isSameAs( itemstack ) )
{
return true;
}
for( final ItemStack optionals : AEApi.instance().registries().inscriber().getOptionals() )
{
if( Platform.isSameItemPrecise( optionals, itemstack ) )
{
return true;
}
}
}
return i == 2;

Currently the piping into the inscriber inventory just checks if this is just valid for the slot without much concern for the context.

Not sure if this is intended or not

commented

maybe allow the player to lock the slot to a specific item, not that its that important at all that only valid items can enter, as stated earlier it forces people to be a bit more creative about the setup, but that will eliminate the scanning of recipes, maybe just a button to lock it to the current item in the slot.

commented

Locking the slot would achieve the same exact effect as filtering the input method. I don't know if performance would change though.

commented

would it not be better to only pull the valid recipes for the inserted press 1 time when the press is inserted, or that slot changes instead of pulliing it everytime a isvalidforslot is called, i think pulling recipes is very slow if i remember right.

commented

Caching might make it a bit better, but the effort is not really worth it. Minecraft and Forge pretty much defy any sane approach of it and pretty much require reimplementing half of the stuff needed should we actually want to do it.

But there might still be thousands of valid recipes for a single press and we had to iterate over every recipe to find at complete or partial matches. Also it would highly depend on the insertion order. The press might not be the first item being inserted. Thus it might insert a diamond first and then try to insert a different press into it. So it also has to check for the inverse and which presses are valid for the current item, which is not limited to one. Like a name press is pretty much always a valid option. So instead of producing a Printed Engineering Circuit it will just name your diamond.