Not sure if this will help you, but it seems a good point to interject in this thread for completeness.

You could possibly skip the tokenizing thing completely, and just use the Mid() expression to isolate the individual characters. The len() expression is a natural companion to it, also. Assuming that Mid() is 1-based instead of 0-based (not sure if that's correct), this pseudocode would tokenize a string into delimited single characters:

string = "Minor"
newstring = ""

For index = 1 to len(string) - 1
    newstring = newstring + mid(string, index, 1) + ","
Next index

newstring = newstring + right(string, 1)[/code:3i2hfww5]

newstring would equal "M,i,n,o,r" after that. BTW, subtract one from both ends of the For line if Mid() is 0-based.

That said, if all of the tokens will always be a fixed number of characters as above, then I'd skip the tokenstring expressions and just use the mid() expression whenever you need one of the characters.

Another question: should the 'set instance variable' action force the type? *SNIP*

I'm of the opinion that it should fail if the type is incorrect, at run time.

If you're talking about when it's entered into the editor, then I suppose a choice would be good. The options that make sense to me would be:

1) Construct automatically coerces the value into the correct type by explicitly adding the correct typecasting function around the value in the editor, and points it out to the user, so that they know what they did wrong.

2) Cancel. Perhaps the user meant to use a different value entirely.

3) Always allow Construct to convert. Not sure I like that, but some may find it useful.

Pretty much what lucid said, I think. However, I'd be fine with just making the user pay attention to what values they are working with, and letting it error in all cases. As long as there is a meaningful error message, it would seem much the same as the choice to me.

I find that 'Strongly typed' is a bit ambiguous in this case, so I'll respond using my understanding of the subject matter.

Short version: I'd be fine with it, as long as it seems uniform throughout.

I'm used to strong typing in most of the programming languages that I've used, where there is no implicit type conversion that happens at run time. If you want to perform an operation upon two different data types, you must explicitly cast one of them into the type of the other. I prefer this.

In my experience with the original Construct, it was at least somewhat weakly typed, in that one could concatenate numbers and strings implicitly. I did find it somewhat confusing that it was not uniform in that matter. For example, on a text object, if I 'set text' the result of the addition of a number and a string, it would implicitly cast the result to that of string in order to assign it to the object's Text instance variable, but the result would only be the string representation of the first variable. The second was just ignored, even if the string only contained numeric characters.

In my opinion, it should either result in error because the variables were not explicitly cast, or be more fully weakly typed and allow for implicit conversion of strings to numbers where the string consists of numeric characters.

On the other hand, I like dynamically typed variables. I like to be able to store whatever I want in a variable, whenever I want, even if I have to type check/cast in the code in some cases to make sure that it doesn't cause problems. I do occasionally use such practices.

I suppose that the cases that I can think of where this is useful can be worked around with using different variables. In fact, I'd not likely care if variables are statically typed, if the only types available are boolean, number, or string. I'd more likely use complex types in such a way.

I share newt's sentiment that there should be other data types allowed as regular variables, such as arrays (especially!) Construct was too limited with the use of arrays. They are essential to solving many problems.

However, I think that they also need to be able to be created at run time as well. I'm not sure how this would work with Construct 2. If they are allowed as instance variables, then I'd say that there needs to be a way to create arrays on-the-fly and allow arrays of arrays. Or, new instances of an object could be created in order to contain a new array, which would probably also work for me.

If arrays are separate objects as in Construct, then it would be nice if they can have more than one instance, as other objects can. Then, perhaps my sprite object (or whatever) can store an index number to the array instance that was created for it, and reference the array object by index. If I wanted each sprite to have an array associated with it, and I create sprites at run time...

Really, it's hard for me to say how I'd feel about it without knowing exactly what data types there are, and how they can be used.

I think that those ideas would be good. I have a similar, but slightly different ideal for such things.

My preference slants more toward regular programming language features, but I think that they would fit well with the object model used in Construct.

I would like to see all variables treated equally, to be dynamically typed, and to be object-oriented. Very much like Python. While I think that this would be difficult to work into Construct that way that I would like it to be, I have some ideas that would come somewhat close, I think. Here they are:

• Global (and local, if available) variables can store any usual datatype, and can be tested with system conditions at runtime to see what type that they currently store.

• Datatypes should at least include integer, floating-point, string, array, hashtable, and boolean.

• It would also be quite useful if a variable could be used as a reference to an object. In this way, one can store a reference to a specific instance of, for instance, a sprite. This would be a way around many common picking problems, as well.

• It would be nice to see some way to use something like classes. I think that a logical way to do this could be to offer a generic object type (without the overhead that a sprite or other object would incur,) that can be used mainly for it's ability to have instance variables and be used like a collection type. The big thing here is that new instances can be created at runtime, making things a lot more dynamic. Hopefully these could be referenced easily by index and/or storing a reference to them in a variable.

• The array and hashtable types should be able to store any of the above types as well. This could be complicated, though, when it comes to hashtables of arrays. Perhaps not nested arrays, but arrays being able to store references to objects would be nice.

• Arrays could certainly benefit from a simple sort method, and stack/queue methods

So, I'm out of time, but I think this is pretty inclusive of most of my wishes.

I'm curious what others may think about the subject as well.

Baking soda (Sodium bicarbonate) is a good toothpaste alternative, and has been used by many people for quite a long time. Some like to mix a small amount of hydrogen peroxide or salt with it, though those can be corrosive to metal fillings.

I've always thought it ridiculous that fluoride is added to water in so many places, while in other places the people suffer from their water being contaminated with it. Seems a bit stupid to me.

That sounds like a great solution to me. Much more intuitive than using families, I think.

I wonder if that case would fit some situations where there are multiple sprites colliding simultaneously. I think so, but I'm a bit fuzzy on whether something like this would be needed sometimes, or at all:

Sprite: on collision with Sprite:

• System: Pick Sprite instance 0 -> Do one thing...
• System: Pick Sprite all other instances -> Do another thing...

.

I can't be arsed to buy a new version of Windows until I have to. Vista was a piece of crap, Windows 7 seems o.k, but Windows XP works just fine for me, still.

I have to agree with toralord. The correct choice was definitely made by the developers. The same choice has been made countless times before by many others as well, as it is the logical one.

Besides, how can anyone feel indignant that the developers move on from a project that they gave away? It's still there to use, for free. If anyone started working on a major project using a product that was somewhere in the alpha to beta release stages, then they should expect to have to start over at some point just because of that, really. Consider it a learning experience, and you'll come away with a better product.

Anyway, I think this move is the right one on many points. I can't say that I'm thrilled about the HTML5 at this point, or the apparent lack of proper scripting, but I'll be interested to see where this goes.

I do hope that variables come with much more robustness than the previous version. That was one thing that made me prefer Python over Events in the previous version. Some sort of data collection, like classes or structs, is needed. Ability to create new instances of them at run-time is a must. And functions need to have more elegant argument passing, as well as local variables. THESE THINGS ARE IMPERATIVE! AGREE!

I'm already impressed with what is here currently, though. I wish this project well.

As Davioware pointed out, the code above doesn't seem to allow what you describe that you want it to do.

It's difficult to figure out a code fragment like that without knowing what happens before or after with this data, though...

If you have six character slots, and you want each newly available character to be added to the first open slot (apparently as a unique number), then you should be setting the same slot as you are checking in each event, and also include a 'no open slots' case if that is possible.

On function "ObtainElli":

    'slot1' <= 0 : set 'slot1' to 1

    else 'slot2' <= 0 : set 'slot2' to 1

    else 'slot3' <= 0 : set 'slot3' to 1

    ... etc ...

    else 'slot6' <= 0 : set 'slot6' to 1

    else : call function("noRoomLeftInParty")
[/code:2cjhgygj]

Then it would seem that the next "ObtainCharacter" function should set each to 2 instead of 1. If this is how it should work, then you could do this with one function that accepts a parameter for the number to set the first empty slot to, and call it with a different number for each character.

I doubt that (m)any people have tried such a thing. Given the fact that it is almost always undesired behavior for any unfocused application to respond to input, I would think that you'd have to insert some kind of 'hotkey' hook into the os interrupt handler that would send messages to the background application in question. This is probably infeasible with Construct. Perhaps it's possible with the aid of Python.

I could be way off base, I suppose...

I'm pretty sure that you can't have collisions on particles. You'd have to make your own custom particle emitter with sprites or some object that supports collisions, but that would be terribly cpu intensive.

[quote:3eq1azei]Is there a way to check how much speed the sprite has in downward movement?

If you're using physics behavior, you can use the expression 'Get velocity Y component', which will look like Sprite[Physics].VelocityY in the event sheet. Just use the System Evaluate condition to compare it with your thresholds, and make sure to use Else for each separate range check.

Also, if you happen to need to convert an int or string to a floating point number, there is float() for that.

http://sourceforge.net/apps/mediawiki/c ... xpressions

Lots of other system expressions are described in the wiki link above, if you haven't seen it.