My ongoing list

Why not just make the function global then you dont need it in every layout.

Why not just make the function global then you dont need it in every layout.

That's what I am doing. What made you think that I set them to local?

Edit: Ah, I see, what I wrote was kinda stupid. What I meant was that I need to use function events coupled together with another event now for timed events all the time, which makes things a little more cluttered. If the 'execute it for 400 ms, then set back to what it was before' condition was in there, it'd be simpler.

39) Aeal already asked for this yesterday on the chat, but so that it won't be forgotten:

Layout Variables would be awesome. I want to set certain variables that only get triggered on a certain layout - that'd really help making the layouts come to life with events without having to clutter the whole project with tons of global variables.

In general, I think for bigger games we sorta have the problem that global variables aren't really all that organized in the system right now. It's just a huge fucking list. It'd probably be cool if we could create a higher level organizational layer to the global variables, like folders. Create a system folder with its set of variables, a combat folder with it's set of variables, etc. - that we could then trigger through actions. For a typical adventure where you'd have tons and tons and tons and tons of global variables otherwise, this would really help keeping things nice and tidy.

Aaaand:

40) Being able to give objects a 'Trigger only once' attribute. Like, in a runtime, there are various things I'd only EVER want to do ONE single time throughout the whole game and not repeat it once I re-enter the layout. That's a bit of a bitch to do right now, cause I'd always have to set variables and use them as conditions or I'd have to come up with some other clever idea like using hash tables or whatever and that's still sorta crappy in terms of organization.

If we'd have an adventure game where you could set an event to only happen once EVER, it'd make things a lot simpler.

40) Being able to give objects a 'Trigger only once' attribute. Like, in a runtime, there are various things I'd only EVER want to do ONE single time throughout the whole game and not repeat it once I re-enter the layout. That's a bit of a bitch to do right now, cause I'd always have to set variables and use them as conditions or I'd have to come up with some other clever idea like using hash tables or whatever and that's still sorta crappy in terms of organization.

If we'd have an adventure game where you could set an event to only happen once EVER, it'd make things a lot simpler.

I think it's necessary to take a step back and look at how a story line should logically be run here.

You want to run a part of the story only once per play through, therefore this event has a designated name or identifying feature, maybe it's called "Meet Robert", for example. The method you propose would arbitrarily make just one event run only once, with no identifying feature or name to signal what it is. What if you want two events linked to it? What if you want to reset the event, for example, you meet an enemy, battle him, and lose. What happens then.. do you get stuck? Using a hash table requires one condition (the same amount as your method would), and then just 1 action to signal that the event's happened (adding the identifying name to the hash table). This hash table entry can then be deleted (to allow replaying), or even incremented (if you want to allow it to happen several times). Another major advantage is that this list of events that's happened can be checked in the debugger, and also that it can be saved/loaded to disk. A system condition to check would not persist over save/loads, nor be in any way superior to organise as a hash table. You'd quickly forget where and how many story line items were going on, and their names, whereas with a hash table they're safely organised and named.

41) It'd be neat if we'd have a 'wait' action in our platform behavior. It'd just freeze the platform behavior for a certain amount of ms and then keep going again.

So if I want to send a guard on patrol, I'd have an invisible wall where he'd 'wait' and set the animation back to idle - then, after a certain amount of time he'd start patrolling again, heading into the other direction. Hits a wall, waits, idle, starts patrolling again, etc.

We could also use 'Wait' for timed stuff in Cutscenes. If Cutscene happens, wait for 5000ms, then move forward, etc.

42) It'd be cool to have a 'repeat last action' key in the IDE. So if I just toggled an event, I could select another one, hit the 'repeat last action' key and boom, this event also is toggled. Should also work with delete, invert, etc.

Try the timer behavior. It would work well.

On collison with wall

• >Stopenemy

->Start timer resetenemy for 5000MS

On timer resetenemy

->startagain.

43) Platform behavior again.

I'm currently designing enemies and it's kinda hard to define their behavior. What I want to achieve is this: The enemies are patrolling - which means they walk left for x amount of pixels, stop and go to the idle animation, then they turn around, walk x amount of pixels, stop and go to idle, etc. etc.

Very basic stuff. The problem is this one: I want the enemies to move based on the platforming behavior, since it already has all the stats set-up. The speed, gravity, jumping, everything. But it's kinda hard to define right now (at least I don't see how it could be done efficiently) that the enemy should walk from his current position to X:360 and from X:360 to X: 1200, etc.

That also makes it hard to take control over the character in cutscenes - usually, what do we do in cutscenes? We set the player inputs to ignore and run an event, so that the designer can 'take over' for a while.

It'd be cool to have a couple more actions with which we could actually control our characters behavior in form of simple events.

What I want to achieve is this: The enemies are patrolling - which means they walk left for x amount of pixels, stop and go to the idle animation, then they turn around, walk x amount of pixels, stop and go to idle, etc. etc.

I don't really think that's hard to achieve. You'll just have a PV on the enemy called Range or something similar and then you compare its current position to its last stopped position. If the difference is bigger than the PV Range, the enemy will go idle.

Here's a little example.

Interesting. I've used invisible walls so far for this Gotta take a look at your cap in a bit.

44) Okay, just wanna know if I miss something about the hotspots - Is there any better way to set them to the same coordinates for all frames? If my Attackcycle has different sprite dimensions (because the sword makes the whole sprite larger) than my runcycle and I need to adjust the hotspot of one animation cycle to the other (so that I don't get jerky movements when I start running after I attacked), how am I doing that? Do I really have to go into every single animation frame of the cycle that I want to adjust and manually, by hand (using the arrow keys on the keyboard) match them up?

Cause that'd be quite terrible. For detailed animations, that could take me HOURS - when all I want to do is to save the hotspot coordinations of one animation cycle and copy them to the next. Or save the hotspot coordinations from one frame and copy it to the other. Especially since I can't playback the animation in the sprite editor.

I find the best way to do it is to create all the animation frames the same size originally, so when they import, you can alt-click which sets the point on all the frames to the same spot. Then you alt-click crop.

46) Just a little thing:

I just tried to solve an 'an unexpected error' occurred issue for 30 minutes, until I figured out that Construct crashes before the start of the runtime because I had an event that set my player sprite automatically to the layer "Base" and the new layout I just added did have that spawner in it, but no "Base" layer yet.

That's a bug that needs reporting to the tracker.

47) It'd be cool if there'd be an 'opacity' value under the parameters of each effect, so we could set the strength of each effect individually, just like in Photoshop or any other comp package.

48) Is there a smart way to create a timer that can be accessed after it's started? i'm currently working on the combo system and I figured the smartest way to do it would to add a timer when the attack key is pressed and the animation plays until the 'attacking' gv is set back to 0 (which determines whether the player can hit the enemy or not).

So if I hit 'Attack' once, it'll start the timer (which is set to 600ms) and play the animation of the first part of the combo. Then, while the first combo is still playing, I hit attack again, the timer resets to 600ms again and the second part of the animation is being played, etc.

After the fourth combo, even if you hit Attack again the timer won't be restarted, the fourth animation completes and after 600ms, the attacking gv will be set back to 0.

Makes sense? Right now, the problem is that I don't have access to the timer once it started. So it'd be cool if I could define a timer entity and reset the value to its default or another value again.

49) Being able to deactivate individual controls would be enormously helpful. Say I want to deactivate only the players movement while the combo plays - only the arrow keys, but the player can still jump 'n stuff - so I'd just add a couple of 'deactivate control' actions while the combo is being played.

47: the meaning of 'opacity' depends on the effect. As they are plugins, each should implement it by itself. Effects developers: more options!

48: you're much better off doing a state machine. See flags below, only set the current state in a number, add the number as a condition to the events that can only happen in the current state. Change said state within the event.

49: use flags. 1 to enable, 0 to disable.

+On control "left"

+global('movementEnabled) equals 1

do stuff