To make it so the input_text isn't capitalized?

I’m writing something that gives you the choice to choose a color, which is going to come up at a later date, and I can get it to where, if you choose a preset color, it’s capitalized where it needs to be, and not where it doesn’t need to be. However, I allowed the option to choose your own color, but it you capitalize it in the input_text box, then it captilizes it where it’s not supposed to… if that makes sense. Is there another way to go about doing this? Else I’m probably just going to put in a lot of colors to choose from and let it be that.

If you’re using !{variable}, the exclamation is causing it to capitalize. Just use {}

Yeah, I used it without the !. It’s just the fact that if someone types it in the box with a capital letter, then it stays like that, which makes the next sentence commenting on the color funky.

You could always put a little note before the box to let the player know to make it lowercase. The only other things I see are to hope that they can survive with a capitalized color or to hope they decide to make it lowercase themselves.

@Galador- I think I’ll do that, at least then it’ll make it so there aren’t a thousand different choices :stuck_out_tongue:

*input_text varname

Then for *temp variables:
*script temps.varname = temps.varname.toLowerCase();

Or global/*create variables:
*script stats.varname = stats.varname.toLowerCase();

That’ll force the whole string to lowercase, but as always use of *script is a touchy subject.

2 Likes

If *script is used, will it work just fine in all the version of games? (android,apple…).

@cynicthnkr
Strictly speaking, yes… The problem is that script allows you to do pretty much anything, so it’s hard to say “yes it will always work” (CoG don’t “support” it) - but for the most part, it should.

It’s behaviour is near infinite, so there are bound to be situations where it’s use is going to cause problems.

The *script command itself will work on all platforms to my knowledge (except maybe the Kindle??), but what you actually *do* with the script command may not work… If that makes sense?

It’s a bad analogy but think of it as a ‘You can drive a car through a field’ - whether or not that’s a good idea will depend on the driver, the field in question, the car itself etc.
Strictly speaking yes, you can - but that doesn’t mean it’ll always end well.

@CJW
Supposing driver == writer and car == choicescript . I am worried about the field ie the plateform. Basically what kind of wrapper is used to run it on different platform. Does it uses the native browser of the device like in phonegap or it provides its own browser similar app to run the game. Something like how cocoonjs works.

Sorry, I am new so don’t know a lot of things.

I’ve not seen the wrappers myself, but remember that the cs interpreter is actually written in javascript, all *script does is allow you to execute custom javascript outside of the scope of choicescript’s commands - so in theory, there should be no problems with it. I suppose you could think of it as a way to write your own cs commands within the cs files? All cs commands are javascript (*script), the difference is that they’ve been tried and tested, anything you write with *script will likely be unique to you, and *might* cause unforeseen issues.

There is a JAVA branch of the interpreter, but I *think* it’s only used for the Kindle Fire (but I could be wrong) - *script won’t work with that.
But hosted label games aren’t seemingly offered the kindle platform anyway.

@CJW
Thanks! that made a lot of things clear.