Issue type:

🐛
Incorrectly using apply on an already applied 0 parameter operator caused an invalid cast exception fatally crashing the server.

Short description:

In the process of learning/figuring out your operator delegate system I discovered that if you use apply with a single parameter operator, passing in a fixed value, you end up with a 0 parameter operator, which you can unfortunately use in another apply, and bring down the entire server.

Expected behaviour:

The exception internally handled and the operator throwing a usage error to the client instead halting.

Actual behaviour:

Server throws and invalid cast exception and halts.

Steps to reproduce the problem:

1. create an operator variable that takes one parameter
2. create an apply operation providing the one parameter
3. create a second apply operation, doesnt matter what you pass.
   ...
4. profit?

Versions:

Exact versions of the following mods, not just latest.

• This mod: 0.11.3
• CyclopsCore: 0.11.4
• Minecraft: 1.12.2
• Forge: 14.23.1.2610

Log file:

https://gist.github.com/xannor/b1c2e91752cc0745f7c3a32f447d5ae4

P.S.
Where can I possibly find the variablestore and/or display screen data so I can remove the offending operation and recover my server w/o having to rollback.

P.P.S. Suggestion...
Maybe the apply* should require an operator that accepts +1 parameters and an exec operation exists for "reducing" a 1 parameter operatior to an operation.

”0 parameter operators” aren't supposed to exist. How exactly did you get one of them? Exactly what did you put in apply to do this?

For me at least, if I use the apply operation with a 1 parameter operator, and specify a fixed value in the second slot, the result is a 0 parameter operation.
i.e. I have an operation variable that accepts an entity and returns an NBT value. If I use it in an apply with an entity variable, the resulting variable can be placed in a display to see the result. It seems it can also be used again in an apply.

Which operator specifically did you use?

unfortunately I am not sure and I cannot launch the server to see, I am just going by memory of what I was attempting when it all went south. If I could find the variable store and/or display NBT data I could provide precicely what the operation was. Would I have to MCEdit the world or is the data stored in a separate file?

It's stored as regular NBT.

Ok, breaking down the NBT as far as I can go...
In the display I have:

ID217:apply:ID216,ID175

In variablestore2:
ID216:apply:ID196,ID126
ID196:pipe:ID160,ID182
ID126:entity - from entityreader

In variablestore1:
ID182:pipe -- this is an existing chain that already worked previously, it is basically Item->NBTTag(key) -> NBTTag(key) -> NBTInt(key)
ID175:apply -- this is an existing chain that already worked previously, it is basically valueInt > [operator]
ID160:operator:entity->item

I worked backwards from the display following the variable IDs until I hit labeled variables that I know were working because I was using them in other locations.

I think ID 216 is where I created the 0 parameter operation.
If I delete the NBT data for either 216 or 217, do you think that would let the world load back up?

update:
I removed 217 as it was the one in the display, and the only thing using 216, and it let my world come back up.

update2:
the world came up but the ID network is unresponsive. logs show an NPE in org.cyclops.cyclopscore.network.PacketCodec:loopCodecFields:350 so that didn't work. going to have to restore the backup I made before the edit and wait for a suggestion.

@xannor You can start the server in safe-mode to remove the offending block(s). (see config file)

Actually I managed to do it with MCEdit and a little brute force. I edited the 217 variable, dumping its VariableIDs tag and operatorName tags, loaded up the server, logged in, got the NPE error, and disconnected/reconnected the variable stores and it restored the networks from a corrupted state. so far everything seems to be working.

I also figured out where I went wrong, i used the two values in the wrong order: 175/216 gives the correct result, 216/175 causes the crash. I think it is because the operators are untyped, there is no real way to verify you have them in the right order, on top of the fact you can create a 0 parameter operator.