Simple example for better understanding of the input stack

The Defoldmine
#1

This is a minimal example I made to explain how the input stack works in Defold.

InputStack.zip (13.2 KB)

The setup:

  • 3 collection proxies
  • A couple of scripts
  • In the main collection, you can change the delay on loader scripts to change the order in which the collections load.
  • When you run the project, it prints logs with the order in which scripts acquire input.
  • Use space to print a log with the order in which scripts receive events.
  • You can also uncomment return true in internalN.script - on_input to see where exactly input propagation will stop.
Register #1 is [main:/go3#loader]
Register #2 is [main:/go1#loader]
Register #3 is [main:/go2#loader]
Register #4 is [col2:/go#internal2]
Register #5 is [col1:/go#internal1]
Register #6 is [col3:/go#internal3]

Input in url: [col2:/go#internal2] reg #4
Input in url: [main:/go2#loader] reg #3
Input in url: [col1:/go#internal1] reg #5
Input in url: [main:/go1#loader] reg #2
Input in url: [col3:/go#internal3] reg #6
Input in url: [main:/go3#loader] reg #1

I hope this will be helpful.

14 Likes
#2

Thought this would be useful to diagnose a change in behaviour in our game, which occurred between game releases in which we also upgraded Defold version.

It’s one of those ‘I don’t understand how it was working before’ situations, as the script which receives input first acquires input early, so should be towards the bottom of the stack.

Strangely, the output of the example changes between Defold versions, and neither matches what’s posted above. Has there been any engine change which could explain this? Nothing stands out from the release notes.

Defold 1.6.4

Register #1 is [main:/go3#loader]
Register #2 is [main:/go1#loader]
Register #3 is [main:/go2#loader]
Register #4 is [col2:/go#internal2]
Register #5 is [col1:/go#internal1]
Register #6 is [col3:/go#internal3]
Input in url: [main:/go2#loader] registered #3
Input in url: [col2:/go#internal2] registered #4
Input in url: [main:/go1#loader] registered #2
Input in url: [col1:/go#internal1] registered #5
Input in url: [main:/go3#loader] registered #1
Input in url: [col3:/go#internal3] registered #6

Defold 1.8.1

Register #1 is [main:/go1#loader]
Register #2 is [main:/go2#loader]
Register #3 is [main:/go3#loader]
Register #4 is [col2:/go#internal2]
Register #5 is [col1:/go#internal1]
Register #6 is [col3:/go#internal3]
Input in url: [main:/go3#loader] registered #3
Input in url: [col3:/go#internal3] registered #6
Input in url: [main:/go2#loader] registered #2
Input in url: [col2:/go#internal2] registered #4
Input in url: [main:/go1#loader] registered #1
Input in url: [col1:/go#internal1] registered #5
#3

Yes, the order how we create objects was changed (as you remember this order is not guaranteed, and game logic shouldn’t depend on that)

#4

Which I think I did know, but unfortunately doesn’t leave much that can be learned from the example which is stable between engine versions.

1 Like
#5

The main goal of this example is to show how input stack works with collection proxies:

Because many people don’t get it, and in both cases you posted, you see that it works the same way: it goes through the main stack, entering the collection proxy stacks.

  • Register #1 is [main:/go3#loader]
    ---- Register #6 is [col3:/go#internal3]
  • Register #2 is [main:/go1#loader]
    ---- Register #5 is [col1:/go#internal1]
  • Register #3 is [main:/go2#loader]
    ---- Register #4 is [col2:/go#internal2]

So it goes from the bottom of the main stack to the top:
#3 [main:/go2#loader] in the main scene
----#4 [col2:/go#internal2] in the proxy
#2 [main:/go1#loader] in the main scene
----#5 [col1:/go#internal1] in the proxy
#1 [main:/go3#loader] in the main scene
----#6 [col3:/go#internal3] in the proxy

So, it is the main stack with many collection proxy stacks. It goes from the end of the main stack #3 [main:/go2#loader] to #1 [main:/go3#loader], and if an entry has its own stack, it will be entered there.

In this sense, #4 is more like #3.1.

You can check this example to make sure it follows the same substack logic and shows that proxy objects’ inputs still depend on the main stack.

3 Likes