I think in the mean time, you could achieve a similar effect with a careful use of blend modes, but this is a nice suggestion IMO

I tried that, but it was selecting all ships, not just the one in the same container. Thank you for confirming what I thought it was supposed to do, though. Maybe I'll set that up again and see if I can find something else in the code that is causing the problem.

Would it make a difference that all the gun turrets are in a family and all the ships are in a family? So it actually has the gun turret family has a target, then the ship family bullet speed is set to ...

Indeed, families and containers do not work well together, and it is a known issue that will not be fixed:

In that case, you would have to do the correct picking yourself, I am not able to currently use C2 at the moment, so all I can do is suggesting either to do the conditions for each type of gun turret (easy but troublesome), or to store the UID of the ship inside a family variable of the gun when they are created together, and vice versa so you can add the condition "Ship: pick by unique id, the variable that contains it from the gun"

I think in your case, just have the condition Gun turret has target, and the action should be ship: set speed to...

And have also Gun turret has NOT a target, ship: set speed to...

Since you said they were in the same container, they are always picked together.

Ashley What's better: every n seconds or every dt*n seconds? Thanks

Every n seconds is already frame rate independent (as the name suggest, it is time based and not framerate based, even though it cannot occur under dt itself), if you want something to happen every 2 or 3 ticks, you would be better with something similar to compare two values: tickcount%2 = 0 or tickcount%3=0.

It all depends onnwhat you prefer to do

Just to be sure I understand clearly, NV are nerfing performances on some programs for reasons that are wrong, and WE should work around that?

They did not do a good job, and they choose to do it that way, they are the ones that should do something about that since every workaround you could do would go currently against their decisions and so will be countered everytime until they change it themselves.

I would say complain to them, but do not try to overwrite their choice, not worth it + not your job + you will be supporting a platform that does not try to support you anyway, since they are doing the exact opposite currently.

codah - that is a good workaround! ... I general I have tried to stray away from global constants as they can quickly bloat the editor with a lot of stuff. To keeps things organized I create holder objects for variables. I would probably create an object called Function strorage or something. I have alot of objects whose sole purpose is to aid in organization.

example:

Player_Physics (is the actual collision object with the physics behavior)

Player_State (tracks the players states such as in air, on ground, etc)

Player_Abilities (tracks the players upgrades and potential upgrades, like fireflower or star power in mario)

Player_Constants (a storage for unchanging variables such as walk speed, run speed, etc

Player_CurrentStats (a storage container for tracking variables such as current max speed, jump pwer etc)

Player_IsSwimming_collider

Player_inventory

Player_expandedMath (such as old position, vector maths, and so on - provides a way of knowing projection vectors and velocities in a direction other than x,y)

Global_PhysicsConstants

Global_currentPhysics

Global_GameManager

Level_State

...and on and on the list goes. Storing all those things as an event variable would be cumbersome to deal with. Keeping them all in one object, like all the player stuff in player would be a hassle too. Plus the player as well as many other in game objects are much more than one collision box.

You can have local constants and variables in groups for some particular use that will not be listed outside of their scope, that can help a lot in bigger projects.

I also prefer to have my global variables inside their own event sheet(s), you do not even have to include the event sheet where your variables are declared for it to work, so you have a list of variable and constant you can simply read and edit.

Performance is not the main argument in that case, as usual I would recommand using the one that gives you the more readeable and maintainable code for your use in particular.

That is weird, did you placed the trigger once after the score > 5?

Also, does the debbuger shows the variable changing or not?

System: trigger once while true should do the trick

If you skip PNG recompression isn't it a near-instant export?

I think the idea is to not reexport the images but keeping the already compressed ones obtained inna previous export

Unless skip png compression checks the already present images sizes before replacing them?

You should not use only one event sheet, it will not help when you need more organisation, also if you really think you will go into performance issues, do it this way:

First make a working prototype at a smaller scale, just working, do not think about optimising yet

Then try to organise it well, so you can modify the needed part easily, read them quickly, and know where everything is

Then see if there are redundancy of actions or conditions (you should not have to recheck the value of something twice inside the all event system, you can if that helps you organise it.)

Then see if there are checks or actions that are done in case where it does not matter (exemple, checking if an the player is alive constantly is not needed, just check that when needed, same goes for updating the hud or other things.), if you do not find them all, it is not a problem at all, it is just to make the events of the prototype easy to read, and to write, yet performant enough.

Do performances measurement, see if you need every element of the game to exist (pretty sure you don t need every thing to exist everywhere on the map at everytime), so if there is a problem, try to deactivate behavior or to destroy uneeded object, keep in mind that when you are not targetting old mobiles, performances are pretty good in C2 so don t go into try to optimise every event and go into micro optimisation, not only it takes time for absolutelly nothing and makes everything harder to read, but also it won t help you learn how to design correctly your game, try to see what is needed and when it is needed, so you can make the device have less calculations to do.

Tl;dr : test early, see if it is working, organize, see if it can be optimised by not checking useless things, do not try to optimise every single event you make, learn to see what could cause a performance drop in which case, so you don t fall into the trap a lot of people fall into: "optimising everything, except what needs to be optimised"

And remember, working code is your first priority, then organisation, then flexibilty, then performances adjustement, if you have a optimised code that is unreadeable nor flexible, you are going to have a worse time that if you have a code that is clean but needs performances adjustement.

So you are saying that if I use only one tile and rotate it, there would be only 1 draw call for it (instead of 4 draw calls for 4 tiles). Also, are draw calls used when the tilemap is invisible ?

Rotated tiles are considered as different tile for rendering I think

And the draw on screen is skipped for invisible objecs, so the draw calls should not be a problem