This is *very* annoying (type conversion)



Why can’t max convert an integer to bool!? You can’t say “1 as booleanclass”, its an error. At least C++ defines the bool type in such a way that any nonzero integer is implicitly converted to true, and 0 is false. Why can’t max do this?

Or at least allow me to Read and WriteBool. If all you give me is a byte, then let me store an integer to signify true/false, but that is not allowed.

Due to this rather annoying problem, i have to set up a separate “table” of flags, just to store a copy of my boolean values, so they can be used in checkboxes etc.

Bloody hell.

I am sorry for my very angry tone, but I am truly very annoyed.


Nice, just noticed it doesnt support the ternary syntax ( ? : ) for some terseness. That helps.


Indeed, I can think of many times I would like maxscript to know this based on a number. I use this function in my scripts for the same effect.

function bool value allowNegatives = (
  	case value of (
  		"true": return true
  		"false": return false
  		true: return true
  		false: return false
  		default: (
  			try (
  				if allowNegatives == true then (
  					if ((value as float) * 1) != 0 then ( return true )
  				else (
  					if ((value as float) * 1) > 0 then ( return true )
  			) catch ( return false )
  			return false
  	return false
     so if by your example, using a checkbox, I would do
checkbox.state = (bool <value> <allowNegatives>)
     Where &lt;value&gt; can be a number,string,or already a boolean value and &lt;allowNegatives&gt; is a boolean.  If true, then any number not zero will be true, where as false will consider any number &lt;= 0 as false.

The only thing with this function is that uppercase letters in bool stored as a string will always return false, since I’m only looking for lowercase in string bools. For me, it’s not worth it to look for uppercase letters, since I personally would never write them with any.


Stop writing MAXScripts, go back to C++. :wink:

(val > 0) is shorter than (val as booleanclass). It would be great the have implicit handling as you mentioned, but it is not the case, so live with it or use the SDK. In 99% of the cases, it has not stopped anyone from getting the job done.

I still don’t see the problem, but I don’t know what exactly you are doing. In most cases, people do not save data to binary files from MAXScript (unless the data is reaaaaaly huge). For saving checkboxes and other GUI stuff, INI files are the way to go. Or just write your own ASCII files. MAXScript can convert (“true” as booleanClass) to true in Max 7 and higher. Or you can call (execute val) if val is the string “true” and you will get your boolean value from the file.

Btw, the binary data access was a 3rd party extension that got incorporated around Max 4, but it has never been a good one, and I don’t know many people that actually use it.

MAXScript is not C++, start using it the way it was intended to be used, not how YOU wished it would work. It might make you happier :slight_smile:


How about this? It would catch any cases since matchpattern is by default case-insensitive unless you specify otherwise. It also does not use return statements which are SLOW, but tries to return the value directly

fn bool value allowNegatives:false = (
	case classof value of (
		String: matchPattern value pattern:"true" or matchPattern value pattern:"on" 
		BooleanClass: value
		default: (
			try (
				if allowNegatives then value != 0 else value > 0 
		)--end default
	)--end case
)--end fn

bool true --> true
bool false --> false
bool "true" -->true
bool "false" -->false
bool "TRUE" -->true
bool "False" -->false
bool "on" -->true
bool "off"  -->false
bool "bobo"  -->false
bool 1.0 -->true
bool 0.0 --false
bool 0.1 -->true
bool -1  -->false
bool -1 allowNegatives:true -->true
bool 0.000001 -->true
bool teapot -->false
bool (teapot()) -->false


How slow, you ask?
Well, I tried running the following test with both versions of the bool function:

  st = timestamp()
   for i = 1 to 100000 do bool (#(true,false,"true","false",1.0,0.0,1,0)[random 1 8]) false
   timestamp() - st

The original one took 51124 ms (51 seconds).
The optimized one tool 453 ms (0.45 seconds)

This means it was 112 times slower when using return statements.


Damn! I didn’t realize that return statements were so slow! (I also never checked either, so that would certainly be my own fault)

I have a feeling that my previous bool function won’t be making anymore appearances around town anymore.


Ah, cool, thanks Bobo, that function would save me heaps of duplicated code! Though I would simplify it by getting rid of the second parameter completely, defining any nonzero integer to be true, as in C++.

I do understand that MXS is a scripting language, and is not C++, but you’d think that if C++ can implicitly convert between most fundamental types, a much higher level language (MXS) should be able to do it with ease. Other high level languages like php can do this easily.


You can skip the second parameter - I made it optional in my example. It assumes that anything higher than 0 is true. I kept it there because the original code had it.

It is really not about DIFFICULTY. It is fairly easy to implement (as you can see, even using MAXScript itself). It is a concious decision of the developers of the language whether to allow 0 and 1 to be seen as true and false or not. MAXScript already has some features that make it tricky to debug - for example the type-free variables you can overwrite anytime with whatever you want or use without explicit declaration of type and value at any point.
Having 0 and 1 behave like false and true in an IF expression for example could potentially lead to uncaught errors. Right now, IF expects a BooleanClass and would error out if you would pass ANYTHING else. Even worse, passing by mistake an integer or a float as a parameter to a function where a booleanClass is expected could trigger functionality that the user never intended to summon…
I assume John Wainwright designed the language to be used mainly by artists and not by programmers, so he made several such decisions - like case-insensitivity, one-based indexing and so on. Being primarily an artist myself, I really appreciate some of these design decisions, but I can understand if experienced programmers are a bit annoyed… :wink:


This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.