Request: Please remove case-sensitivity

Discussion and feedback on Construct 2

Post » Tue Sep 02, 2014 10:12 am

Yeah.

Just recently I spent two hours trying to figure out why an event suddenly didn't run anymore. Turns out it was because I set an animation string to "Falldown" instead of "FallDown" somewhere else in the code. The animation wasn't affected and would play no problem but the event "Character.sprite_animation = "FallDown"" would no longer come true. The extra fun part is that this bug only began to kick in after I changed something seemingly unrelated.

It can be pretty aggravating to hunt down bugs like this and it's happened before so is it possible to make case-sensitivity either go away or at least behave consistently?
B
40
S
16
G
6
Posts: 543
Reputation: 7,649

Post » Tue Sep 02, 2014 10:24 am

My personal opinion is, the developer himself must retain his own consistency. This kind of feature might break other people's game you know. :?
B
28
S
8
G
4
Posts: 553
Reputation: 4,924

Post » Tue Sep 02, 2014 10:28 am

Agree with DuckfaceNinja, it is up to developer to maintain himself, but typo's happen.
And one of most asked features is "Modularity"

But that might be sometime, so not an ideal work-a-round, but I create an eventsheet called functionref and I add constant variables
FunctionFallDownF = ""
OtherGetXYZ = ""

So when you type in a function or something it lists the variable (you can't use the variable) then i delete the F so that it isn't linked to variable.
Upside, I get same spelling everywhere on input.
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,728

Post » Tue Sep 02, 2014 10:36 am

This kind of feature might break other people's game you know.

But if the case-sensitivity doesn't behave *consistently* then how can people make code that relies on it? I imagine removing it would fix a lot more problems than it would create. Of course it's up to the devs to decide what's best in the end.

Agree with DuckfaceNinja, it is up to developer to maintain himself, but typo's happen.

I agree and like you said, typo's happen. The problem arises when C2 lets it pass sometimes, but not always. If it bugged out right away you'd know where the problem was and how to fix it.

EDIT:
Good solution you posted there. Thx for sharing :)
B
40
S
16
G
6
Posts: 543
Reputation: 7,649

Post » Tue Sep 02, 2014 10:44 am

ErekT wrote:But if the case-sensitivity doesn't behave *consistently* then how can people make code that relies on it?

It's hard for me to accept that computer make mistake, or am I missing something here? Inconsistent behavior by a computer must be influenced by something, which I would think 100% of the time because of human factor.
B
28
S
8
G
4
Posts: 553
Reputation: 4,924

Post » Tue Sep 02, 2014 12:09 pm

Hmm okay, I made a simple example:

Image

Here I'm deliberately using lower-case in the first event and upper-case in the second event. If case-sensitivity applied then 'Sprite' should never get its animation set back to "Default". But it does. So in this example there doesn't seem to be any case-sensitivity yet in my game (which is waay too big to post here) switching from lower case to upper case suddenly makes the bug I'm experiencing go away. Now if case-sensitivity isn't supposed to make a difference like the example above implies then what on earth could I be doing wrong in my own code to somehow activate it? Unless it *does* make a difference, it just doesn't kick in all the time. So, inconsistent.

It's hard for me to accept that computer make mistake

Yes, but as far as I know Ashley and crew are human beings :P
B
40
S
16
G
6
Posts: 543
Reputation: 7,649

Post » Tue Sep 02, 2014 12:20 pm

I stick with UPPERCASE to Global Variables, lowercase to local variables and Capital only on object and animation names.

I think you're lacking in how events works, allied with the case sensitive system, if not, report a bug with the minimum necessary to reproduce the bug in a consistent way and the developer will be able to help you.
Image
B
108
S
24
G
18
Posts: 1,376
Reputation: 22,830

Post » Tue Sep 02, 2014 12:57 pm

Okay, I found out that upper-case/lower-case for the animation name you set in the image editor needs to match the one you use in events exactly or the events won't trigger. Events themselves don't seem to mind if you mix upper-case/lower-case between them. So it's not a bug really, just inconsistent behaviour. I'll leave it alone now, probably won't make the same mistake again. I still think it's something that needs fixing tho'.
B
40
S
16
G
6
Posts: 543
Reputation: 7,649

Post » Tue Sep 02, 2014 3:37 pm

The animations system was designed to be case insensitive. If you find part of it which is case sensitive, please file a bug report following all the guidelines.

Note if you use some features like "compare values" from System, that is by default case sensitive, because it is a general purpose comparison as opposed to part of the animations feature.
Scirra Founder
B
403
S
238
G
89
Posts: 24,653
Reputation: 196,143

Post » Wed Sep 03, 2014 7:21 am

Usually, if the world was a perfect place, the IDE, here Construct2, should take care of highlighting bad references.
The problem is that Construct2's "IDE" have either an overly tight referencing of object and variables (so you can't temporarily write an expression without having all variables/objects involved already defined/created, where common IDE would just display a warning or an error) and a loose referencing over any properties accessed using strings (like animations, functions or layout names, no checkings done and no warning displayed, and I believe that's the reason why almost everything is case-insensitive in C2...).
Few exceptions exists, like when you try to create a "disable group" event with the name of a group that doesn't exist, C2 will prevent you to do it (though I'd say it should allow it but display a warning), but if you later change the name of the group, nothing warns you.

All that falls into the domain of modularity/refactoring feature C2 is sadly lacking (at least for now let's hope). If you want such features, you can try your hand on... dudum... classical programming :D

For now, I would suggest you use a consistent naming convention throughout your entire code-base. I usually use a lot of camelCasing for everything. And families have the first letter uppercased.
B
68
S
22
G
14
Posts: 1,485
Reputation: 16,561

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 7 guests