Defold 1.12.0 BETA

[Visionaire]

There is an error in the text labels of the GUI nodes; In previous versions the text was very well concatenated, now not anymore!

Defold 1.12.0 beta version.

Console with an example.

[Mathias_Westerdahl]

Hi!
I’m not sure I understand the issue exactly. Can you describe it in a little more detail?

[Visionaire]

The error occurs when you choose to create new lines of text in a label in the GUI!

Lua interpreter code: print(“In a Lua interpreter”..“\n there is no mistake…”)

Defold console code: print(“In a Defold Console”..“\n there is no mistake…”)

gui.set_text(gui.get_node("text"), 
"In the text node".."\ncreated in a GUI".."\n there is an error!)

When you render the text node in the GUI, it doesn’t print three lines of text, it prints on a single line separated by ~sign.

[aglitchman]

@Mathias_Westerdahl

NEW: (#7277) ‘Introduce late_update script function’ by ekharkunov
New script function late_update(self, dt) was introduced. That function runs after regular update(self, dt) function. All in-games messages are dispacthed in between update(self, dt) and late_update(self, dt). You can safely update game object’s transforms in late_update(self, dt) because components will update inner transforms after script execution.

I played around with the new update and the new late_update and I want to say that it would be better to call everything by its proper name and add a pre_update function to scripts (which is what update is right now!). Otherwise there will be terrible confusion - I can already see people explaining in chats that the update in scripts is actually pre_update, and so on . Adding one more function will not affect performance, but it will make life more flexible.

Why is this needed? For example, I need a regularupdate in a script AFTER fixed_update as it was before, so I’ll use late_update obviously, but… now when sending messages in late_update to another script and updating the transform in this message, the position and rotation of the object only change in the next frame (!). So, on the one hand late_update is a good thing, but on the other hand it is inconvenient and difficult to apply.

So I am in favor of calling everything by its proper name, not catering to 3.5 hypothetically broken projects that might have broken because of the change in the update/fixed_update order, and introducing an additional pre_update function, while calling update in the actual update of internal components.

My two cents.

[Dragosha]

@aglitchman

3.5 hypothetically broken projects

sounds like the name of a heavy metal band

[Mathias_Westerdahl]

We agree (and plan to) also switch the order of “fixed_update()” and “update()” script functions, so that they arrive in the same order as the game object’s Update/FixedUpdate.
The fact that we had to introduce an internal notion of a “pre” update, should hopefully remain an internal detail.
We’ll post here once the beta is updated.

[Mathias_Westerdahl]

I’ve submitted a fix to the beta now, so your should be able to update the editor in ~1 hour.

[Visionaire]

They updated it and it’s still the same, take it easy, there’s no rush, you’ll have the solution later! Thanks for this version…

[AGulev]

@Visionaire

They updated it and it’s still the same, take it easy, there’s no rush, you’ll have the solution later! Thanks for this version…

no, it’s still building Fixed issue with incorrectly handling explicit line breaks in the tex… · defold/defold@ef6281a · GitHub

[Visionaire]

oopss… Ok! Thank you.

[NaakkaDev]

There might be a leaky pipe somewhere. There is a non-zero chance I had a particle running in the editor for ~3 hours while afk. It could have been paused too.

Edit:

[Visionaire]

Updated…

Excellent work!

[Hunter_Loftis]

@Mathias_Westerdahl

We agree (and plan to) also switch the order of “fixed_update()” and “update()” script functions, so that they arrive in the same order as the game object’s Update/FixedUpdate.
The fact that we had to introduce an internal notion of a “pre” update, should hopefully remain an internal detail.

It sounds like some of the earlier assertions (“Order of lua callbacks update(self) and fixed_update(self) stays the same as it was before”) won’t be true upon release.

Anyone who has built deterministic physics in defold has had to dig deep into the current sort of quirky order and restrictions, in order to build workarounds (for example, being unable to get current-frame global physics position). A crystal-clear “1.11 frame lifecycle” and “1.12 frame lifecycle” doc that includes both internal engine lifecycle steps and user-facing lua lifecycle hooks would be really useful for me, even in high-level bulleted list form.

[aglitchman]

@Mathias_Westerdahl

We agree (and plan to) also switch the order of “fixed_update()” and “update()” script functions, so that they arrive in the same order as the game object’s Update/FixedUpdate.
The fact that we had to introduce an internal notion of a “pre” update, should hopefully remain an internal detail.
We’ll post here once the beta is updated.

I am interested in learning more about this already this week to have time to test it before the beta release

[britzl]

@aglitchman

I am interested in learning more about this already this week to have time to test it before the beta release

We are currently reviewing the changes and will likely do further changes to clarify and align the implementation with expected behavior. We should be able to share more information soon. The beta will be extended to give everyone time review, provide feedback and adapt their projects.

[Hunter_Loftis]

This is probably the sort of alignment you’re already looking at, but I wanted to share a concrete issue in the lifecycle of Defold 1.11.2.

For a physics-based game (not necessarily physics-sim based, just a game that needs to run in real time with a fixed timestep that is decoupled from the rendering update speed), if you script update, fixed_update, on_input, and use msg.post(“.”) for a simulated late_update, you’ll see in a given frame, in order:

1. zero or more on_input calls
2. one update call
3. one late_update message
4. zero or more fixed_updatecalls

Having both the start callback and the end callback of each frame be called 0-N times carries some awkward side-effects. For example, the recommended way to track input state (clearing it in update and updating it in on_input) won’t work - if you clear it in update or simulated late_update, it’s empty by the time any fixed_update reads it. If you clear it in fixed_update, then on a frame where multiple fixed_updates are called, the player’s input is ignored for all but the first one.

Ideally, the lifecycle would look more like:

1. zero or more on_input calls
2. zero or more fixed_update calls
3. one update call
4. one late_update call

That would allow each frame to start with a clean simulation step (input + optional physics), followed by a single render (update) that is able to read from the latest physics state (for instance, to attach visuals to physically-simulated objects), followed by a consistent late update that marks the seam between frames and allows for clean frame-by-frame logic like “clear the input state.”

[Mathias_Westerdahl]

Correct, that is what it’ll be like, and we’ll update the documentation as well.
We’re currently reviewing the final PR, and we’ll have a build to test soon after that.

Note that “render” is called after the late_update step.

[Hunter_Loftis]

@Mathias_Westerdahl

Note that “render” is called after the late_update step

Good clarification! And thanks, I’m really looking forward to this update!

[Mathias]

One thing that bothers me is the multiple on_input calls..
If you want to handle combinations of inputs at the same time (say L1+cross on a gamepad, or just left+right at same time) you cant react to an on_input call because you dont know if its the last call of it, so you have to gather states on the object and react to the input in the update phase…which defeats the point to have a reactive on_input function in the first place, since now you have to test the state of your input at each frame in update!

Why dont we have juste on call to, say, “on_inputs” function with an array gathering all the inputs of the frame?
Or at least an information in on_input that it is the last call in the frame, so you can use your input state in this call.

Wouldnt it make more sense?

You handle all input in on_input to change the state of the object in a reactive way (think here change the state of a state machine for exemple), then the update step just use this state, but dont handle inputs again.

I know this is not directly link to fixed_update order, but since you are rethinking the workflow of the engine, I felt it was appropriate

[Mathias_Westerdahl]

While there is merit to the idea, it’s not something we’ll change right now, as it would be a really big change from how current games works right now. We would have to support both types of input functions, and we don’t really want to support two code paths.

In any case, as you say it’s not part of this change.