call same function in different eventsheets from one included eventsheet

Hi,

I have two layouts (L1 & L2) with both an eventsheet (ES1 & ES2) and one common eventsheet (ES_common) that's included in both ES1 & ES2.

In ES1 & ES2 there is an event MoveSprite.

Is ES_common I have an event Keyboard(On [Space] Pressed).

What I want is to call 'MoveSprite' from ES_common.

If L1 is active it has to call 'MoveSprite' in ES1.

If L2 is active it has to call 'MoveSprite' in ES2.

Before the new build in function it worked. But now two functions can't have the same name.

My workaround now is to create two functions moveSprite1 & moveSprite2.

In ES_Common is use two conditions:

LayoutName = "L1" -> Call moveSprite1

LayoutName = "L2" -> Call moveSprite2

(This is of course a very highly simplified project)

Is there a more elegant way to solve this?

project file: drive.google.com/open

Thanks

Wim

You can use a Family to simplify things:

http://www.blackhornettechnologies.com/Construct3Stuff/Samples/comgamer_ESInclude.zip

Elegant is a word used by those who get paid entirely too much to sit and think of ways to make science appear attractive to the artistically inclined mind. For the rest of us, functional replaces elegance.

LayoutName = "X" -> Call Y

If it ain't broke, don't fix it.

In this situation if you want to do something completely different depending on the layout, you really ought to have two different functions. The old Function plugin only allowed this usage by accident, and I really think it's a poor way to structure your events - for example if you look at a "Call function" action, you can no longer tell what that does, and "Go to function" can't work - it depends on which layout you're on, which also involves reviewing the tree of event sheet includes across your project, which is hard work. If you just call a different function it's much more obvious what it does.

How to better structure the events depends a lot on the details of your project. If you have a "common" event that really needs to call two completely different functions, I'd argue that is not actually a common event and ought to be implemented as layout-specific logic. This will involve rearranging the whole way those events are used, but I think it will be much clearer afterwards. Alternatively a quicker (but not particularly elegant) approach is just to have a global variable with the game mode that you set on each layout, and dispatch to different functions depending on the mode. I'd avoid relying on the layout name, because people normally expect to be able to rename things without breaking anything, and you end up in the situation where you can accidentally break your events just by renaming a layout.

Fengist, Ashley, Thank you!

Fengist: I'm not a native speaker, so I miss the subtle difference between English words, but 'functional' is indeed a better word to describe what I want. :-)

So I have to put all keyboard events in all layouts. In my project this seems like a lot of double code. Maybe I made my example to simple, so I try to explain myself better:

- I'm making a game for children with a motor disability, so they have to access it by keyboard.

- It's a game about recognizing colors.

- They can choose a color by the corresponding key (r: red, g: green, y: yellow, p: purple, ...).

- On layout1 when they press 'r' a red balloon pops.

On layout2 when they press 'r', the red airplane makes a loop,

on layout3 when they press 'r' the red helicopter flies away, ...

- So every layout contains a keyboard event and a corresponding function:

My current "common Eventsheet" contains:

Keyboard(On [r] Pressed) -→ keyPressed(Red)

Keyboard(On [o] Pressed) -→ keyPressed(Orange)

Keyboard(On [g] Pressed) -→ keyPressed(Green)

Keyboard(On Pressed) -→ keyPressed(Blue)

Keyboard(On

Pressed) -→ keyPressed(Purple)

Keyboard(On [y] Pressed) -→ keyPressed(Yellow)

Keyboard(On [w] Pressed) -→ keyPressed(White)

When I define this in every layout I get:

On ES1:

Keyboard(On [r] Pressed) -→ keyPressed1(Red)

Keyboard(On [o] Pressed) -→ keyPressed1(Orange)

Keyboard(On [g] Pressed) -→ keyPressed1(Green)

Keyboard(On Pressed) -→ keyPressed1(Blue)

Keyboard(On

Pressed) -→ keyPressed1(Purple)

Keyboard(On [y] Pressed) -→ keyPressed1(Yellow)

Keyboard(On [w] Pressed) -→ keyPressed1(White)

On ES2:

Keyboard(On [r] Pressed) -→ keyPressed2(Red)

Keyboard(On [o] Pressed) -→ keyPressed2(Orange)

Keyboard(On [g] Pressed) -→ keyPressed2(Green)

Keyboard(On Pressed) -→ keyPressed2(Blue)

Keyboard(On

Pressed) -→ keyPressed2(Purple)

Keyboard(On [y] Pressed) -→ keyPressed2(Yellow)

Keyboard(On [w] Pressed) -→ keyPressed2(White)

...

Is this the most functional way?

If it works, then it's all good.

Years ago when programmers had to write code for Commodore 64's they had to be super efficient. They had to write elegant code in order to make it fit in 64k of ram and they had to make it elegant in order to run quickly on an 8 bit CPU.

Today, programmers have a LOT more freedom to write functional code rather than elegant.

The questions you need to ask yourself as to whether your method is the best.

1. Does the code work as intended?

2. Can you follow how the code works?

3. Is this code for public consumption or just for internal use?

Does the code do what you want, does it do it quickly enough, does it not gobble an excess of ram... is it functional?

The only time I get concerned with elegance is if I'm writing code for someone other than myself who also understands how to write code. In that case, I try to make it elegant so they don't think I'm a total noob. For my own use, I comment my code so I can come back later and figure out "what the hell was I thinking."

In all honesty, the vast majority of your end users won't give a damn about code elegance. What they will give a damn about is how it looks, is it fast and does it contain bugs.

If you already have duplicated 'On key pressed' events in layout-specific event sheets, you may as well just call the right function directly, instead of calling a common function that then has to work out which function to call.

Ashley,

I'm sorry I did not make myself clear (my last reply contained your solution not mine):

- These are no onkeypressed functions in my layoutspecific eventsheets.

In the common eventsheet there are 8 onkeypressed functions, but on the layout-specific eventsheets there is only one 'function that does all the action' with the 'keyboardkey' as parameter.

So there are no duplicate functions in my example.

Number of functions in the project:

- Your solution:

(3 layouts) x (8 'onkeypressed functions' + 1 'function that does all the action')

= 27 functions.

--> a lot of duplicated code

My solution:

(8 common onkeypressed functions) + ((3 layouts) x (1 'function that does all the action'))

= 11 functions.

--> no duplicated code

ComGamer

I have a library for making buttons that I use in a lot of projects - it covers all the states, multi-touch, overlapping, and other things.

what I do is store the name of the function to call when the button is clicked in an instance variable of the button family. That way I can create a new sprite for a button, add it to the family, give it the name of the function to call, and everything else is handled automatically.

You could do something similar... when the r key is pressed, let the object determine what function to call.