Variables not Updating

So I’ve got the following event:

I want to track the player’s position and round it to the grid’s position. I want the variables to be always updating so that I can reference the character position, however during testing they only update value when the scene starts and no longer (in the debugger at least).

I’m also trying to track a timer to but nothing is happening. I supposedly start the timer at the beginning of the scene, but it doesn’t start, because the rest of code doesn’t do what it’s supposed to be doing.

Is there a problem with these events?

Have you looked at using The Rectangular grid extension?

image


Yes. In your third event, you unpause the timer “RestartFrequencyTimer”. But you’ve never created/started it anywhere.

Hello MrMen, thank you for your response,

Have you looked at using The Rectangular grid extension?

Thank you for referencing this behavior, however I don’t want to use it as it doesn’t really help me with what I need right now. I just use the grid to check the player’s position to help with some of the game logic, but I don’t need the character to snap on the grid or anything like that.

The problem isn’t really about what the purpose of the expression is, the problem is that the code is not working and I don’t understand why. I just want to understand why it’s not working so I can fix it.
Sure maybe there’s a behavior that could help with this particular situation but there will be other situations on the game where I will just need to update a variable each frame, and for some reason it’s not working. How am I supposed to make a game if something like updating a variable is not working?

Yes. In your third event, you unpause the timer “RestartFrequencyTimer”. But you’ve never created/started it anywhere.

Thank you for spotting that, I realized that I was starting the first timer when the scene begins too, but the player character is created on runtime. It would be great to have an “On Creation” condition, the way it is now makes it so convoluted to check if an object has been created.

I’m feeling really tempted to quit on this engine, feels like it has a lot of potential but it’s missing some pretty no-brainer features like just checking if an object has been created in the scene, missing a simple “else” condition, check if an object has been destroyed, etc.
It’s too manual labor dependent. I’m basically trying to create a base engine for RPGs to make it easy for people to make RPGs in gdevelop, but I need to do workaround after workaround. I want a simple event that just updates a variable on every frame (which is the basis for a lot of systems) and it just doesn’t work god knows why. This makes this engine super unreliable.
I don’t know, I want to like gdevelop and I do in some aspects, but it’s getting really frustrating to work with this…

Are there multiple instances of Map_Character_Object? Because pick all objects doesn’t mean the actions will be applied to all objects. It just means all objects are now in consideration for the event, and commonly used in a subevent when the parent event has a condition that filters the objects with conditions.

The way you have your event, the action will only be performed on the first object GDevelop has in that list, usually the first one that was created in the scene. Instead, you’ll need to iterate over each one using the “Repeat for each instance” event.

And as a BTW, the condition “Always” is redundant. I believe it’s a hangover from an earlier version of GDevelop. The default is that all conditions of an event must be met before the actions are run.


GDEvelop requires a different approach than programming in the traditional sense. Once you get your head around that, it becomes a bit of fun.

1 Like

Thank you for the insight :pray:

I was following Construct3 logic, which applies the actions to the picked objects. So if you pick all objects, all objects are affected. Using a for each for every frame won’t affect performance?

GDEvelop requires a different approach than programming in the traditional sense. Once you get your head around that, it becomes a bit of fun.

Hope to get the hang of it, there are a few things that I really like about the engine, as it comes with a lot of important functionalities that make life easy, but also there are some limitations that really hope are addressed in the future

Excessive usage can have an impact, but on the whole, no, it shouldn’t have any noticeable impact.


Yeah, and they’re the fun bits; an interesting challenge to work within those limitations. With the behaviours and extensions, GDevelop is fantastic for getting the basics of a game up and running in a short space of time.

1 Like

Just to clarify, the “Create object” action is already it’s own “On Creation” condition. Any actions that target an object and are immediately following the “On Creation” event will target that created instance.

Alternatively, you can make a behavior out of your events, add that behavior to the object in question, and any events in the behavior will occur once it is created, but I usually just ensure my creation events have anything that need to target newly created objects instead.

To be more precise, the object creation will automatically add the object to the current filter. It means that it will change all the objects on the current filter, and if you had none (which is commonly the case), it will change all of the objects.

Having a real “on creation” event could be really helpful x)

1 Like

I think the design ethos for the engine looks at “anything OnCreate” (or destroy) required as a behavior. But it is there:

Just to clarify, the “Create object” action is already it’s own “On Creation” condition. Any actions that target an object and are immediately following the “On Creation” event will target that created instance.

It’s not really the same though, sometimes you want to reference the object’s creation separately from the action where it is created in order to keep the code organized, sometimes you may need to reference the object creation in a different external event from where the object was created.

Additionally, that method does not work for objects that are placed on the scene through the editor, and hence are created when the scene is loaded. Since they weren’t created using an action, you can’t reference them on their creation because they are created as soon as the scene loads. So if you have some instances of the same object that are created both on beginning of the scene and spawned mid-way through the game, what happens is that the code can become convoluted real fast. For the same action you would always need 2 conditions, one for the beginning of the scene and the other if you create the object during runtime. But because you have no condition for On Creation, you may need to put the same code twice, (or reference a function twice), one after a beginning of the scene condition and one after the creation action. Unnecessary repetition…

But I came up with a solution that seems to be the best for this, just create a boolean for the object called “On Creation” that starts as true, and have an event set it to false in case it’s true. So as soon as the object is created, there’s a little bit there where the boolean is true and you can use that to check that the object was created. Seems like the simplest solution to this that works regardless of when the object is created.
For me it was a simple solution to come up with, but for someone with no experience in coding, making an On Creation condition would be the best way to achieve this. And I think it’s a common and useful enough condition that would make sense to be available on the engine without needing unnecessary workarounds.

Also, an On Creation check is simple enough because you can reference the object since it’s in the scene, but an On Destroyed, would be harder to achieve because you can’t reference the object any longer. You probably would need an array just to track deleted objects, which again feels like it’s over complicating something that could be 1 click away. In this case On Deletion is actually even more important than On Creation in my opinion.

As for the custom behavior, I’m not sure how I would create an on creation method that would work for all objects and all situations. I still need to figure out the custom extentions, haven’t used these yet, although I like the premise. Seems like a pretty powerful feature of this engine.

Totally valid, I was just meaning more it was an option within the design ethos of the engine, but probably used too definitive of wording.

That said, behaviors could expand upon any on create/destroy things you need, and there is a lot of functionality there to play around with.

2 Likes