ZLib variable editor (relay_zlib.ash)

[fronobulax]

Exact error message from r10708

Function 'to_boolean( familiar )' undefined. This script may require a more recent version of KoLmafia and/or its supporting scripts. (relay_zlib.ash, line 22)

Line 22 from the code I am running which I believe to be unmodified ;-)

if(!vars[i].to_familiar().to_boolean()) vars[i] = write_check(vars[i].to_boolean(), i, "").to_string();

 

[Veracity]

he^3's version, in the original post...

Line 22 of the script in the original post:

  matcher m = create_matcher("^(always|never|timely)( [123])?$", fields[name]);

Edit: that file works. At least, when I put it in my relay folder and start it up, it gives me a page of variable names and buttons and checkboxes and such.

Edit 2:

vars[i].to_familiar().to_boolean()

What is that supposed to MEAN? It takes a string, coerces it into a familiar and then it turns it into a boolean. What determines if a familiar is "true" or "false"? Is a Mosquito "true"? Is a Leprechaun "false"?

Since you said "there was a simplicity ... that I preferred", I assume that you understand that expression and can explain the "simplicity".

Thanks.

 

[fronobulax]

The version I am running was DL'd to my computer on 07/02/2010 (and attached for reference). The version in the first post is is 8 months newer so I clearly missed an update ;-) I really need to remember that it is 2012 since something about seeing the first post dated exactly a year ago short circuited something in my thinking. The newer version does work but one major difference is that I don't recall the older version doing any type assignment/checking. As for the simplicity comment, I was referring to the simplicity of the page layout and the absence of type checking. Unless line 22 in the old version adds fuel to the argument about coercing familiars to a Boolean (or not) this whole exercise seems to have been pointless except for reminding me that I should not presume everything I run has version checking.

 

[Veracity]

Regarding coercing familiars:

I looked at the old code in ASH's RuntimeLibrary.java. It took the "int value" of the familiar - the familiar id # - and if it was 0, you got false, and if it was non-zero, you got true. The "int value" of $familiar[ none ] is -1. Therefore, ALL familiars - including no familiar - returned "true" when coerced to a boolean.

I fail to see how that is ever useful.

Now, maybe the coder thought that $familiar[ none ] would be false and any real familiar was true. Not so, but, going with that and assuming it was intending to test for "not $familiar[ none ]", which code expresses that intent more clearly:

!familiar.to_boolean()

vs.

familiar != $familiar[ none ]

I know where I put my "good coding" vote.

 

[fronobulax]

Regarding coercing familiars:

I looked at the old code in ASH's RuntimeLibrary.java. It took the "int value" of the familiar - the familiar id # - and if it was 0, you got false, and if it was non-zero, you got true. The "int value" of $familiar[ none ] is -1. Therefore, ALL familiars - including no familiar - returned "true" when coerced to a boolean.

I fail to see how that is ever useful.

Now, maybe the coder thought that $familiar[ none ] would be false and any real familiar was true. Not so, but, going with that and assuming it was intending to test for "not $familiar[ none ]", which code expresses that intent more clearly:

!familiar.to_boolean()

vs.

familiar != $familiar[ none ]

I know where I put my "good coding" vote.

Just supposin' ....

The old code is pulling a value out of a file that is supposed to be a string that is a familiar. But it can be edited in numerous places outside of the control of the script. So a good script writer is going to look at the string and somehow try to validate that it is a familiar before doing anything with it.

So in this context

vars.to_familiar().to_boolean()

would seem to be true if vars was a string that "was" a familiar and false otherwise.

If so "cleverness" won out over "clarity" but at least the author thought there was some justification for doing so.

As I said, though, just supposin'...

 

[Veracity]

vars.to_familiar().to_boolean()

would seem to be true if vars was a string that "was" a familiar and false otherwise.

Nope. vars.to_familiar() turns into $familiar[ none ] if it is an invalid familiar. $familiar[ none ] - just like every single valid familiar - has a non-zero familiar id and thus to_boolean() would make it "true".

There is no way that that code as written would ever get "false" for any value of vars[ i ].

 

[fronobulax]

Nope. vars.to_familiar() turns into $familiar[ none ] if it is an invalid familiar. $familiar[ none ] - just like every single valid familiar - has a non-zero familiar id and thus to_boolean() would make it "true".

There is no way that that code as written would ever get "false" for any value of vars[ i ].

Try revision 10682. If it broke anything else, YOU get to fix it.

Maybe we found the thing I am supposed to fix ;-) or maybe my supposin' is just that.

 

[heeheehee]

I honestly have no idea what was going on there. Likely it was just supposed to say to_boolean (no to_familiar), since zarqon's is_100_run takes either false or a familiar, for some reason.

edit: except that wouldn't work, either. I'm not sure what I meant. Probably just some mis-typed hack that I ripped out later on.

 

[zarqon]

zarqon's is_100_run takes either false or a familiar, for some reason.

Not quite -- is_100_run was originally a boolean (hence the boolean-indicative name) but it was changed a good long time ago to contain a familiar instead. Someone may still have a boolean value in their vars file from long ago, but that would be normalized to $familiar[none] the next time they ran ZLib, so there's no reason for any boolean value to exist in is_100_run.

 

[darkcodelagsniper]

I was having problems with Bale's folding-list version not working properly in Chrome (list items wouldn't expand when the inputs were ticked). I fixed it by changing line 60 from

	writeln("		input.fold:checked + label.fold + ul { display:block; }");

to

	writeln("		input.fold:checked + label.fold:nth-child(n) + ul { display:block; }");

Just a heads up in case anyone else has the same problem