Integrated Dynamics

Integrated Dynamics

63M Downloads

Crash while materializing pipe card

Hiranus opened this issue ยท 4 comments

commented

Issue type:

  • ๐Ÿ› Bug

Short description:

I got crash (CTD) while I tried materializing pipe card.

Steps to reproduce the problem:

  1. Make operator Entity->NBT
  2. Make operator NBT+String->List
  3. Pipe those two operators together
  4. Try materializing pipe card

Expected behaviour:

I get materialized Entity+String->List operator

Versions:

  • This mod:
    obraz

  • Minecraft: 1.16.5

  • Forge: 36.0.46

Log file:

https://paste.ee/p/Ylv1s

commented

Thanks for reporting!

commented

Since this is like 4th bug report made by me, maybe it will be easier for both me and you to just tell you my goal and you will be able to fix everything so that it will work.
My goal is to create single operator card that will help me automate rerolling trades of librarian villager. I use Quark mod because it allows me to move lectern with piston, but same thing could be achieved with world importer and exporter from this mod. Basically, I need 2 cards (both operators, as I can easily duplicate them):

  • Entity->Bool operator - I want to emit redstone signal if villager has no profession, which powers piston, allowing him to become librarian.
  • Entity+NBT->Bool operator - This one will be more complex. It involves reading villager trades, filtering out everything that is not enchanted book, and then extracting enchant info out of enchanted book and comparing it to provided NBT. If it matches, it powers piston, effectively locking villager trade.
    I made it work without operators, but it requires ton of variable cards, and is not really portable and easy to duplicate. I want to make it in operator form because those can be easily duplicated, If you want I can make some screenshots of whole contraption and step-by-step information on how to create it with operators (but I wont be able to materialize it because bugs).
commented

Issue type:

  • ๐Ÿ› bug

Short description:

seems to be the similar type of bug so i added here
Rendering item bug
card items that are trying to be rendered in the inventory ui, that comes from materializing certain operators crashes the client

Steps to reproduce the problem:

  • example 1: (trying to make a pipe_2 operator)

(x1 -> x2 -> y) -> (y -> r) -> (x1 -> x2 -> r) as the final goal
process:
create

  1. (.) = flip pipe (composition operator)
(.) :: (y->z)->(x->y)->(x->z)

(.) tested doesn't crash when materialize
2. ((.).(.)) = pipe (flip pipe) (flip pipe)

((.).(.)) :: (y->z)->(A->(x->y))->(A->(x->z))

tested that when we now insert ((.).(.)) into materializer and try to make a copy of it, client crashes
3. flip ((.).(.)) = flip ( pipe (flip pipe) (flip pipe) )

flip ((.).(.)) :: (A->(x->y))-> (y->z)-> (A->(x->z))

this operator when put in the materializer also crashes, though we know that it hasn't achieved the Integrated Dynamics
version of pipe_2

4. using expOpRes

expOpRes :: (a->(b->c))->(a-> b -> c)
expOpRes = apply( (.) , apply)

tested expOpRes, this operator doesn't crash when you materialize it

pipe_2 = apply(expOpRes, (flip ((.).(.)) flip ((.).(.))  expOpRes )  ) 
pipe_2 :: (A->(x->y))->(y->z)->(A-> x -> z)

pipe_2 crashes when materialized

  • example 2: (trying to make a rotate_3_1_2 operator)

(a -> b -> c -> d) -> (c -> a -> b -> d) as the final goal
process:

  1. make rotate_2_3
    using previous (.) card, we get
rotate_2_3 = apply (.) flip

rotate_2_3 tested in materializer and works fine
2.

rotate_3_1_2 = apply rotate_2_3 rotate_2_3  

rotate_3_1_2 crashes when materialized

  • example 3: (trying to make a pipe2_2 operator)

(x1 -> x2 -> y1) -> (x1 -> x2 -> y2) -> (y1 -> y2 -> r) -> (x1 -> x2 -> r) as the final goal
process:

pipe2_2 = pipe pipe2 (pipe (apply (.) (.)) (apply (flip (apply expOpRes flip)) liftM2))
  1. make
apply (.) (.)

apply (.) (.) crashes when materialized

Expected behaviour:

having a materialized pipe_2/rotate_3_1_2/pipe2_2 card inside inventory, and while inventory being opened, client does not crash

conclusion:
operators that crashes when materializing :
((.).(.)) / flip ((.).(.)) / pipe_2 / rotate_3_1_2 / apply (.) (.)

operators that doesn't crash when materializing :
expOpRes / rotate_2_3 / (.)

from observing most crashes from example1, seems like if you try to materialize any operator that is derived from an operator that crashes, it will crash
also from the patterns of crashing, it seems like if we have an operator that has two inputs, and while we apply to this operator another operator onto both of its input,
for example

B A A = apply2(B, A, A)

where B,A are both operators and
B :: a -> b -> c
it will crash, though it might just be a coincidence
I think whether or not B or A are "higer order" operators(functions)/functionals might make a difference, apologize for the mix of terminology, but by higher order i mean whether or not

B :: a -> b -> c
a,b,c is operator

Versions:

  • CommonCapabilities-1.16.5-2.5.6
  • CyclopsCore-1.16.5-1.11.4
  • IntegratedCrafting-1.16.5-1.0.13
  • IntegratedDynamics-1.16.5-1.6.1
  • IntegratedTerminals-1.16.5-1.1.3
  • IntegratedTunnels-1.16.5-1.7.0

only showed mods that i think are relevant, im using Stacia-Expert-1.9.6.3 modpack if thats necessary

Log file:

different crashes from different examples
crash-2021-03-20_17.04.10-client.txt
crash-2021-03-20_17.31.09-client.txt
crash-2021-03-20_16.47.08-client.txt

commented

Issue type:

  • ๐Ÿ› Bug

Short description:
another similar type bug, this time doesn't require B A A = apply2(B, A, A) type situation, but does involve a higher order function: pipe
exact copy of a problem brought upon the CyclopsMC discord, tested this in game with the given version, and crashes when trying to materialize

Steps to reproduce the problem:

  1. I applied an Integer with value 64 to a Greater Than Operator as a first value.
> :: int -> int -> bool
b6 = apply 64 > :: int -> bool
  1. I created a Item Item List Count Operator in which I applied a List as a first value.
ILC = item_list_count :: [item] -> item -> int

II = apply ILC [item] :: item -> int

  1. I piped the Operator from step 2 to the Operator from step 1
pipe (II  b6 ) = pipe ( (apply ( ILC [item] ) )  (apply (64 >) )  ) :: item -> bool
  1. materializie pipe (II b6 )
    client crashes

Expected behaviour:
getting a materializied pipe (II b6 ) operator with signature item -> bool inside inventory and doesn't crash the client

summarizing all possible crashes from all examples above

  1. B A A = apply2(B, A, A)
    where B,A are both operators and
B :: a -> b -> c
  1. any other operators that is derived from 1.
  2. operators that is of kind pipe(A, B)
    the disjunction of 1,2,3 crashes when being materialized

Versions:

  • CommonCapabilities-1.16.5-2.5.6
  • CyclopsCore-1.16.5-1.11.4
  • IntegratedCrafting-1.16.5-1.0.13
  • IntegratedDynamics-1.16.5-1.6.1
  • IntegratedTerminals-1.16.5-1.1.3
  • IntegratedTunnels-1.16.5-1.7.0

Log file:
crash-2021-03-22_15.16.40-client.txt