How to change color?

Team6Labs

Is it possible to change the color of an actor with the behavior change attribute? Are there any other behaviors? for example, if I was something that's white to become green after 5 seconds, how do I do this?

Thanks

JarrenH

You can't directly change the color of an actor, but you can change it's RGB value. On the change attribute, go to self.color then Red, Green, or Blue. Each value is a real number between 0 and 1. So if you wanted to turn a white actor to green, you would set red and blue to 0 and set green to 1.

As for changing the color after 5 seconds, check out the "timer" behavior .

tatiang

You can open the Colors panel and choose a color and then click on the sliders button to view the RGB values. To convert from those values to the ones used in Change Attribute self.color.Red/Green/Blue, just divide by 255.

Be sure to use the expression editor to enter those values.

Socks

What @tatiang said !

Geta-Ve

I am not sure if this is obvious, but for anyone else looking at this thread as I was, dividing by 255 no longer works (for me at least ... )

tatiang

It works. Make sure that you are entering the expression into the expression editor rather than trying to type it in. For example, if you need 125, you would enter 125/255 into the expression editor. If you try to type 125/255 in as text without clicking the expression editor, it won't work.

Geta-Ve

Oh! Silly me I didn't know there was a difference for numbers, I assumed there wasn't simply because when I entered 1 (not in the exp editor) it worked ... I suppose for any numbers it's fine, but when you start to get into maths it all needs to be in the exp editor?

Thanks tatiang, I didn't know this!

Might be worth not letting the user enter anything at all then no? ^_^

tenrdrmer

Might be worth not letting the user enter anything at all then no? ^_^

No there is a legitimate use for just typing in without opening the expression editor. People just need to spend the time to learn all the uses. Its part of learning the tool. Im sure you will find many more things that would make it "easier" on you to do if GameSalad would just restrict you only to later find out there is a reason you have access to use the "restriction"

Good luck

Aaron

Geta-Ve

I'm not sure if you were trying to be snarky or what, but couldn't you have just layed out some of the legitimate uses instead of simply telling me that they exist?

tenrdrmer

Anything that doesn't require an expression (equation) is the legitimate use. why add an extra step instead of just knowing when you can type it in and when you need to open the expression editor. There is nothing snarky about it. people need to spend more time learning gamesalad these days. its not directed at you personally. its just an overall fact.

Geta-Ve

I will be honest, I still am unsure of what you'd need to input that couldn't also go in the EE.

Unless there are items that simply can not, or more to the point, should not, be typed into the EE, then I feel like there is no real reason for the division between the two states. If you want to eliminate a step, simply make the EE the default, and instead of a popup window, have it all as a drop down.

That being said however, as you pointed out, and as I am well aware, I am new, so, wha-do-I-know. lol

I've read through the manual and there doesn't seem to be any real mention of the distinction between the two states. :P

EDIT: By the way, when I say 'simply' I obviously am not referring to the complexity in which said features should or should not be viably implemented.

I'm jus' "sayin"

tenrdrmer

its not that it wouldn't work in the Expression Editor. its the fact of why on earth would you want to add 100+ mouse clicks a day when setting change attributes to a specific preset value. There is no need to click and open the expression editor which you then have to click again to close and save the entry. If i know i want the attribute to change to 200. Then i can simply type in 200. you may not see it but those little bitty steps you can skip that maybe save you a half a second add up when your doing them over and over and over as you will find out when you sit down and start really using gamesalad. So Why the hell should gamesalad remove that time saver to, No offense, "idiot proof" the tool.

tatiang

@Geta-Ve, here are some examples:

Direct entry
---------------
0 (integer)
150 (integer)
8.45 (real)
Enter your name: (text)
true (boolean)

Expression editor
-----------------------
2*self.Position.X (real)
"Welcome, "..game.PlayerName (text)
floor(self.Position.X/50)*50 (integer)
random(1,10) (integer)
Game.Paused (boolean)

Note that boolean attributes can not be concatenated in the expression editor. So "Paused? "..game.Paused (boolean) will return an invalid expression.

Geta-Ve

its not that it wouldn't work in the Expression Editor. its the fact of why on earth would you want to add 100+ mouse clicks a day when setting change attributes to a specific preset value. There is no need to click and open the expression editor which you then have to click again to close and save the entry. If i know i want the attribute to change to 200. Then i can simply type in 200. you may not see it but those little bitty steps you can skip that maybe save you a half a second add up when your doing them over and over and over as you will find out when you sit down and start really using gamesalad. So Why the hell should gamesalad remove that time saver to, No offense, "idiot proof" the tool.

That is kind of my point though, the current division between the two states already causes the user clicks that wouldn't be needed if the EE was the default state, ie, not having to open/close it every time you want to use it. I would think it would be beneficial for everyone to not have to worry in which you should enter the information.

Your "idiot-proof" remark rings as ironic given the engine that you are defending. Game Salad is already "idiot-proofing" the whole process -- This is not a bad thing! The developers themselves have stated in many places that this is their intended goal. Game creation for everyone.

But I digress, it is what it is.

@tatiang: I knew about the text and int/real already, but, what if you wanted text that simply stated "true"? How would you do that? How does GS differentiate between standard text and code? I ran into a situation where typing in a pow gave me mathematic feedback (this was not typed into the EE).

Furthermore, if I type in a function, without opening the EE is it still a function? In my example above it certainly acted like one. How about if I open the EE after having typed the function, will it then activate as a function since it has now been implemented within the EE?


Either way, thank you both for your feedback, this has all been quite illuminating and enlightening.

tatiang

I think one thing that can get confusing is that text that has been entered in the expression editor looks exactly the same as text that has been directly entered without the expression editor. It would be great if GameSalad styled these entries differently. Based on your example, I tried typing in pow and true without using the expression editor and both worked as expected (they were interpreted as text, not as mathematical or boolean expressions). Furthermore, if I enter those directly and then click on the 'e' (expression editor), the field is then blank. It hasn't converted anything.

Your mileage may vary with Windows creator if that's what you're using, but with the newest Mac version I didn't find those issues.

I like your idea of a single entry field without designation as either expression or non-expression.

Socks

. . . what if you wanted text that simply stated "true"? How would you do that?

1 = true
0 = false

Socks

. . . why on earth would you want to add 100+ mouse clicks a day when setting change attributes to a specific preset value . . .

I think that is what he is saying, why the need for the extra clicks, hundreds a day, to open the expressions window when you could simply have the pull-down menu on the top level, if you want sin or cos or random or magnitude simply click on the pull-down and select, rather than open the expressions window then click on the pull-down and select - it removes an extra step, and if you want to enter a specific value then you should be able to simply type it into the same window.

I think his idea makes a lot of sense given the current deign, but ultimately we are talking about improving what, to me at least, is an already flawed HCI, the idea of forcing someone to spend their days working in a tiny one character high and 30 character wide interface is a little insane given people have often got vast monitor real estate at their disposal.

Geta-Ve

@tatiang: Aye, I am indeed using the Windows version. I think I may have just been experiencing a bug last night, because, for whatever reason, I can't get it to do the same thing ... :P Also, I definitely have UI discrepancies (missing elements, etc). I shall have to mess around to see if I can reproduce these issues, then submit a bug report.

@Socks: You hit the nail on the head. Just because this is the status quo, does not mean there isn't any room for improvement. I find this kind of thinking in any software that has long time users. I myself have been guilty of this. We get used to working one way for so long that we get defensive at a new idea, especially from new users. In retrospect I think it's the new users who provide the most valuable feedback.

I've found that alot of great game developers work this way. They are constantly testing their game against new audiences. Valve is famous for this.

I think a semi optimal input interface would be a code editor with all the advantages of Game Salads drag and drop utilities. Granted I have only been using GS for a couple of weeks, but I've already run into instances where I know exactly what piece of code I want and it would be simpler to type it in than to go through 5 layers of menus.

Anyhow, there are probably good reasons for the current implementation behind the scenes that we aren't privy to. Which I am obviously fine with, like I said, it is what it is, but I find it silly when anyone suggests that the current implementation is good enough as-is, simply because they are used to it being a certain way.

Cheers guys! Thanks for the awesome feedback.