Error using zero or null as optional parameter

[limonovthesecond2]

Using zero or null in a function as an optional output parameter results in the error "Cannot use a literal value as an output parameter". Such constructions as in the example below are used to avoid creating unnecessary variables if the output result is not important.

Example:

ulocate building core 1 @copper outx outy found1 building
ulocate building core 1 @copper outx outy found2 0
ulocate building core 1 @copper outx 0 found3 0
ulocate building core 1 @copper null null found4 null
ulocate building core 1 @copper outx outy null building

Error message:

Code in game:

[JeanJPNM]

When making the prototype, I decided to use _ as the variable for ignored inputs/outputs because of how it
has the same use in multiple other languages, but it seems I forgot that null and 0 are the defaults used by the game. I implemented this error message as a way to prevent situations like this:

# oops, output and false are in the wrong order
uradar player any any distance _ output false

I could change the standard to use either null instead, but I find that it doesn't read as nicely, nor is immediately clear what null in a parameter means, it could be:

• that the instruction will use null as the value for that parameter
• that the parameter is ignored by the instruction and you put null because of that
• that the parameter is an output parameter that you chose to ignore by giving it null.

But this is something that one can get used to as time goes on. Do you have any suggestion on how to handle this?

[limonovthesecond2]

Thanks for the reply. I didn't know _ was already used to ignore optional parameters. The problem is that using symbols like _ or / as optional parameters creates an empty variable. Which doesn't happen when using 0 or null. Since such an exception exists in the mlog, it is probably worth reproducing it here too.

nor is immediately clear what null in a parameter means, it could be:

• that the instruction will use null as the value for that parameter
• that the parameter is ignored by the instruction and you put null because of that
• that the parameter is an output parameter that you chose to ignore by giving it null.

As far as I understand, all of this is also true for 0. But in the process of checking these statements i found one difference / bug:

control config unloader1 @copper 0 0 0
control config unloader2 @copper 0 0 0
control config unloader1 null 0 0 0
control config unloader2 0 0 0 0
stop

The result will be that the configuration of unloader1 will be unset while the second one will have copper. That is, when using 0 as the configuration type, the instruction was not executed at all.

Personally, I prefer to use 0 simply because it's shorter. Using null is not an error and in this particular case works identically to 0.

[JeanJPNM]

As far as I understand, all of this is also true for 0. But in the process of checking these statements i found one difference / bug:

control config unloader1 @copper 0 0 0
control config unloader2 @copper 0 0 0
control config unloader1 null 0 0 0
control config unloader2 0 0 0 0
stop

This is not a very good example because the parameter you are using for the demonstration is actually used by the instruction, so it is expected that giving an invalid value (in this case it expects an item or null) causes the instruction do not do anything. It's like saying that print null and print 0 print different values.

A more correct example would be:

control config unloader1 @copper 0 0 0
control config unloader2 @copper null 0 0

Regardless, I will change the ignored variable to 0, but I still think some kind of marker would be useful to tell the user what function the zero has.