Last Legacy Suggestions

[KABOOM]

Check Keypress - Checks whether a certain key on the keyboard has been Pressed/Held/Released. (would probably have to have a constantly running script for this to work).

Maybe there could be a Wait for Keypress event?

[AwesomeJRFD]

Check Keypress - Checks whether a certain key on the keyboard has been Pressed/Held/Released. (would probably have to have a constantly running script for this to work).

Maybe there could be a Wait for Keypress event?

You mean like the "Sleep Until Not Touching" event? That's a pretty good idea actually.

[JSlayerXero]

Has the option for a trigger to completely kick you out of a level been suggested yet? It applies to levels where your lives are being tracked and you can get a game over, levels where during certain parts of that level you only have one chance or restart the level. It'd mostly serve to make the level harder. It would also force reset on local variables. Currently local variables don't get reset when you die. I really don't find that an issue since you can make a global variable used by a single trigger to do the same thing. Can you guess how I found this out? *coughsmbllcough*

[KABOOM]

I've probably suggested this already, but add a "disable?" checkbox to every item, or at least every enemy.

EDIT: Also, PLEASE bring back the ability to activate doors with a trigger, and also add "onEnter" triggers to doors.

[AwesomeJRFD]

"Move Item" and "Move Character" need to have a "use tag" checkbox just like "Move Camera" does.


How about a way to change local variables non-locally without interfering with stuff? For example:
"door1.a" = 1
That would set the local variable "a" to 1 for all items tagged "door1". This would allow us to store data on items which don't have a trigger event, and would be especially cool if x and y coordinates of every item were local variables in said item.


Also, the ability to put a variable in any field that asks for integers/floats, as well as strings, would be extremely useful.

[KABOOM]

Add some way to make small menus where you can choose options. The user can assign a number to each option, and when that option is selected the code will go to that line.

[Runouw]

Since it is getting an increasingly difficult issue for me to face, I figure I would ask it here.

Trigger variables only contain integers right (whole numbers) now. But I want to add more advanced math functions like "divide", "sin", "cos", "sqrt", "random" and stuff. The problem with adding these is that it would require handling both integer and float numbers in triggers. And the biggest problem with using floats for triggers is that they aren't perfectly commutative (0.2 + 0.1 - 0.1 = 0.20000000000000004), so it's possible that people would blame the game for a code not working because it relies on adding numbers together perfectly. Note that a branch if equal would not work on "if 0.20000000000000004 == 0.2".

So I was thinking of doing something a little more interesting and adding a couple of instructions that work like an FPU. This means that I would leave integer operations as they are, and those always expect the input to be integer, if they aren't they would be type cast to an integer (rounded down). And then I would have a set of floating point operations which type cast any integers to floats if they are used as inputs.

This would leave the following triggers instructions:

Integer Operations:

• Set (rounds down if you used a float)
• Add (should the numbers round down before or after the add is applied? ".6 + 1.6 = 2.2 -> 2" or "0.6 + 1.6 = 0 + 1 -> 1"?)
• Subtract
• Multiply
• Divide (returns a whole number rounded down)
• Mod (returns the remainder of a divide)
• Random (sets a random whole number between a and b)

Floating Point Operations:

• Set
• Add
• Subtract
• Multiply
• Divide
• Power
• Sqrt
• Log
• Sin
• Cos
• Mod
• Random (sets a random number between 0 and 1)

Then in addition, since you can use functions like Sin and Cos I would add math constants for PI, and E.

All of this could make a couple of complex trigger functions to be simplified a lot. And there are other pretty cool uses for it. Like if you were allowed to input numbers into the "Move Item" instruction, you could set the x or y position to follow a sine wave.

I also like the idea of adding OOP styled accessors for an item's variables because it would be useful to read an X or Y of something and store it to a variable. Like so: "Add: myItem.x = myItem.x + 1". So you could bypass the need for the Move Item instruction. You would even be able to do that locally if you are writing a trigger for myItem: "Add: x = x + 1". But that means I have to reserve simple variable names like "x", "y", and even "rotation". Is everyone okay with that?

[KABOOM]

I also like the idea of adding OOP styled accessors for an item's variables because it would be useful to read an X or Y of something and store it to a variable. Like so: "Add: myItem.x = myItem.x + 1". So you could bypass the need for the Move Item instruction.

But what would happen to "chars stick to"?

[JSlayerXero]

Since it is getting an increasingly difficult issue for me to face, I figure I would ask it here.

Trigger variables only contain integers right (whole numbers) now. But I want to add more advanced math functions like "divide", "sin", "cos", "sqrt", "random" and stuff. The problem with adding these is that it would require handling both integer and float numbers in triggers. And the biggest problem with using floats for triggers is that they aren't perfectly commutative (0.2 + 0.1 - 0.1 = 0.20000000000000004), so it's possible that people would blame the game for a code not working because it relies on adding numbers together perfectly. Note that a branch if equal would not work on "if 0.20000000000000004 == 0.2".

So basically, float is not available because of how finicky it is. I can understand that. Currently the only thing that's supposed to use float in the trigger system is skipping through music. In that case there's no real need for addition or subtractions unless you specifically want the song to warp in an arbitrary manner that is affected by pausing.

I also like the idea of adding OOP styled accessors for an item's variables because it would be useful to read an X or Y of something and store it to a variable. Like so: "Add: myItem.x = myItem.x + 1". So you could bypass the need for the Move Item instruction. You would even be able to do that locally if you are writing a trigger for myItem: "Add: x = x + 1". But that means I have to reserve simple variable names like "x", "y", and even "rotation". Is everyone okay with that?

I don't know anybody that specifically uses "x" or "y" as a trigger. I imagine that for anybody that does this would break something. However, you already made a global variable specifically for keeping track of coins. While doubtful anybody actually used that exact variable, in theory if somebody did it would break something provided that level had squares in it. Considering you've already reserved a variable in the past I don't see why you can't assign a few more. While it could potentially be a nuisance to anyone who used those variables, unless the entire level depends on it I don't see a problem. And even if the entire level did in fact depend on a single variable, if it's unique enough that it only appears in trigger code, then you can open up a word processor and just replace every instance of that variable that way. Even if it isn't unique you can just sift through the various instances and replace any trigger related ones with a new variable.

While presumably low, this could break a few levels. However the change from v0.2 to v0.3 broke a few levels. Heck, even some boulder related puzzles were destroyed when you updated v0.3. I can't speak for everybody, but I don't see anything wrong with reserving a few more variables.

[Runouw]

But what would happen to "chars stick to"?

If you change an item's x or y with a trigger instruction that is not Move Item, I assume it will not stick the character to the platforms. If you wanted this functionality you would have to use Move Item.

I have a solution to x and y being used already by older levels. I can add everything to an item's "transform" variable.
So we have:

• transform.x
• transform.y
• transform.scaleX
• transform.scaleY
• transform.rotation
• transform.color.red
• transform.color.green
• transform.color.blue
• ect

So is there any other variables for items that people want to modify?