Build 292.22 - Release version

Strings with strings and counters with values. Absolutely awesome.

[MENTION=5114]Yves[/MENTION] I'm working with the Active Picture object and trying to figure how much memory it use.
In the example I attached, I've created six examples:
In the first three examples, the picture of 1920X1080, respectively divided in one piece, two pieces and six pieces are created as Active Obj, then pasted as Bkg.
The memory occupied is 60MB, 65MB and 56MB, probably due to the different sizes of the images used.
From the fourth to six examples, the same images are created as Active Object, but they are'nt pasted as backgrounds. It seems that this is the best choose to do because in this way, the memory occupied is only 42MB.
Is this behavior right? I mean, it seems that the different image's size doesn't make any difference.

Quote

- App properties, new "Event order" option: allows you to define if global events and/or behaviors have to be executed before frame events.
- App properties, new "Alterable values for counters and strings" option: allows you to use alterable values, strings and flags in counter and string objects. Note: this option is OFF by default, to avoid beginners to be confused between alterable strings and the String object's alterable string, for example.

GREAT stuff, thank you CT!

"Comme d'habitude un peu plus de précision et un MFA exemple sont indispensables quand vous rapportez un problème, "Ca ne marche pas" ça peut vouloir dire beaucoup de choses. Quand je lance en HTML5 l'exemple fourni avec Move Safely 2 il marche apparemment parfaitement, alors quel est le problème exactement? Merci."

Merci pour l'aide

Please login to see this attachment.

Quote

- App properties, new "Event order" option: allows you to define if global events and/or behaviors have to be executed before frame events.

ohhhhh yeahhhhhhh, thank you so much!!

Quote from Yves

In DirectX mode, the Active Picture object loads the image directly in the video RAM, it doesn't keep a buffer in system memory, unless you select "Software mode" in the properties of the object. When you create a backdrop object, the Active Picture object creates a copy of the image in the system memory and adds it as image in the internal image bank so that the backdrop object can use it.

That's why frames #1 to 3 use more memory.

Note #1: if you use the APO to just create backdrop objects, you should select "Software mode" in the properties of the object, the creation of the backdrop objects is much faster.

Note #2: when you create backdrop objects, the images are not compressed in memory, unlike backdrop objects created in the editor (if the "Optimize image size in RAM" option is selected). Just in case you've the choice between internal backdrop objects or created backdrop objects.

Understood, thank you!

I wonder if there could be a way of involving frame and behaviors in a custom pause method, now they can be reordered. Custom pauses are generally done by having a Main group with all of the game events in, and a Pause group, and toggling the Main group on and off. It might be convenient to have frame specific events (such as bosses or level specific features) in the frame events or behaviors, but they'd have to really be inside the Main events for them to be pauseable. It would be interesting if possible though, now.

1.
I found that if you put a "break" action in a parent event, while it's also a child event, childs of this event will execute as normal. Does this work as intended? Is it necessary to prevent users adding this action to the parent event?
Please login to see this attachment.

2.
Is it possible to add split line for string object (like active obj) ?
Please login to see this attachment.

Quote

- App properties, new "Event order" option: allows you to define if global events and/or behaviors have to be executed before frame events.

This is very nice to have, though it still doesn't address the issue that was brought up recently (and which IIRC was the catalyst for this new change being considered), regarding green events not fully honouring the event order. With the default order (Frame>Global>Behaviour), a Start of Frame global event will fire before an always frame event. This inconsistency will continue in one form or another no matter what order the user selects. If the user changes the order to (Behaviour>global>frame), then Start of Frame frame events will fire before always global events, and so on.

The thing that I personally would really like is the ability to have some global events fire before frame events, and some global events to fire after frame events. For example, both my player input code and my camera code are in global events, but while the player input code would benefit from firing at the very beginning (to minimise input lag), the camera code would benefit from firing at the very end (so that it can adjust the camera position to any changes that have just occurred).

One way I can think of splitting global code into 'before' and 'after' sections is to take advantage of the 'phenomenon' I mentioned in my first paragraph (that green events will fire before black events no matter the order) and give us a new green event that fires each loop - something like every iteration. Then we could keep Global events after Frame events, but add that condition to any Global events we want to run early. Though this would admittedly be an inelegant workaround.

Another option, now that we can change the order of frame/global/behaviours is to set the order as behaviours/frame/global, and put all of your 'after' code in global, and all of your 'before' code in behaviours. The problem with this though is that behaviours are still very cumbersome to access: go to frame editor or workspace toolbar, find the object in question and click it, go to properties toolbar, hit the "Events" tab, go down to the behaviour and click the label area to reveal the "edit" button, click the edit button. That involves 4 or 5 clicks, multiple toolbars, and searching for an object, so you couldn't reasonably use this approach for frequently-accessed code.

I suppose all of this is a long-winded way of asking: can we have a more convenient way of accessing behaviours, preferably with a single hotkey?

Alternatively, could we have a new, second set of global events? Perhaps they could be called "header events" or "early events", and would always play before global/frame/behaviour events, no matter the settings. Alternatively, you could just call them "global events 1" and "global events 2" and let the user choose their order however she pleases.

Most of the above suggestions involve some level of extra complication for the user, whether this involves a new green event or an additional type of global event. I suppose the hotkey for a key object's behaviours would be the least intrusive method, though adding such a hotkey would itself involve some unorthodox UI decisions.

At any rate, I think it would be really useful to have some way of having global (ie. coded once, but played on every frame) code that fires before frame events, and some that fires after, and for both to be easily accessible with a hotkey.

Just a little thing: is it possible to add option for center counter text ?

Good, but I'm waiting for an updated version of Direct3D 11. Can you work on it?:cf25+:

Quote from Wizard1

Good, but I'm waiting for an updated version of Direct3D 11. Can you work on it?:cf25+:

Isn't it fine enough as it is?

Quote from Yves

Not sure if I understand what you mean. "Always" is not a green event, it will be always executed after a Start of Frame event. And Start of Frame events are always executed first, before any event.

I don't see why? If you select "Behaviour>global>frame", then Start of Frame events from behaviors will be executed before the ones in Global events, and before the ones in Frame events.

What I mean is that if you have Behaviour>Global>Frame, then the events will run something like this:

Behaviour green
Global green
Frame green
Behaviour black
Global black
Frame black

On the one hand, this makes perfect sense: green must always go before black. But on the other, it can seem confusing that some frame events will play before some global events, while other frame events will play after some global events.

And it may seem confusing that, no matter what order you choose in the settings, you'll never get a frame "upon pressing a key" condition to fire before a global "any key is pressed" condition.

But anyway, that wasn't the main point of my post. My main point was that it would be useful to have a method of firing some global events before frame events while firing other global events after frame events (apart from what's already possible with the existing handful of green conditions)

Please login to see this picture.
When child event has an "or" in condition, both filtered and logical, break action seems don't work.
Please login to see this picture.
X)