Crash while materializing pipe card
Hiranus opened this issue ยท 4 comments
Issue type:
- ๐ Bug
Short description:
I got crash (CTD) while I tried materializing pipe card.
Steps to reproduce the problem:
- Make operator Entity->NBT
- Make operator NBT+String->List
- Pipe those two operators together
- Try materializing pipe card
Expected behaviour:
I get materialized Entity+String->List operator
Versions:
Log file:
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).
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
(.) = 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:
- 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))
- 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
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:
- I applied an Integer with value 64 to a Greater Than Operator as a first value.
> :: int -> int -> bool
b6 = apply 64 > :: int -> bool
- 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
- I piped the Operator from step 2 to the Operator from step 1
pipe (II b6 ) = pipe ( (apply ( ILC [item] ) ) (apply (64 >) ) ) :: item -> bool
- 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
B A A = apply2(B, A, A)
whereB,A
are both operators and
B :: a -> b -> c
- any other operators that is derived from 1.
- 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