Release Candidate 0.11.0.6 is available!

BlackCloakGS

Release Candidate 0.11.0.6

Fixes:

• Fixed punctuation in game project filenames causing errors and potentially crashes.
• Fixed text wrapping where it shouldn’t be on Android
• Fixed Animation behavior prompting user with image sequence popups for every change made. Now it should only pop up when the user drags multiple images from Finder or from the image library.
• Fixed text not aligning correctly after keyboard input
• Fixed RevMob causing apps to not respond if the iOS device was not connected to the internet

Known Issues:

• The Release Candidate version of Creator will not open if your GateKeeper settings are set to “Mac App Store” or “Mac App Store and identified developers”

Report Any Bugs
If you find bugs in the Release Candidate, let us know! We'll be watching the forums and support tickets for info on this. Once we're all happy with the state of the build then we'll make it stable.

Take a moment to review the "known issues" section of the release notes before reporting any bugs. No need to duplicate reports on what we already know, right?

Thanks for your help!

Go Get It!

See the release notes here:

http://gamesalad.com/download/releaseNotes/creator/rc

Download the release candidate here:

http://gamesalad.com/download/releases

Scroll down until you see "Release Candidates"

FallacyStudios

@BlackCloakGS‌ If load times aren't going to be properly fixed and brought down to acceptable levels by the time the stable version is out. Can you atleast make sure you will make it the focused top priority to be released in a patch as soon as possible?

Hopscotch

Great work! The quick updates are much appreciated! Thank you @BlackCloakGS and all involved.

GameLabs222

@FallacyStudios @Hopscotch Agreed

Socks

The colour wheel seems to be stable !! I tried to adjust the opacity and brightness using the sliders - something that has crashed every version for the past 4 (5?) years - and regardless of my manic slider moves Creator stayed afloat !!!

A minor miracle !!

. . . . but the link between prototypes and instances is still broken, makes laying out large complex actor heavy projects a real pain.

NimbleBug

Yes please fix loading time,it is taking more than double time to load ,compared with stable version.

BlackCloakGS

@Socks can you give me your support ticket for "The link between prototypes and instances is still broken, makes laying out large complex actor heavy projects a real pain." if you don't have one please submit one.

Yes, I know we need to get load times down. I will see if we can find a path or a small fix to do to try to bring them down.

Socks

Damn !

Sorry ! Spoke too soon, the colour wheel is as unstable as it has always been !! I guess I just got lucky for a few minutes (the issue has always been intermittent).

The problem only shows itself when attempting to make a coloured actor white, once you've selected white (for instance from the custom colour palette) the colour doesn't take (i.e. GS doesn't recognise the change), the only way to get GS to turn the actor white is to move either of the sliders around (brightness or transparency) . . . 75% of the time it works, the rest of the time Creator crashes.

Anyhow, it can't be a big issue as I never hear anyone else mention it, I think the answer is to avoid using the colour wheel when you need to turn your actor white and instead use the three R,G,B values in the actor's attributes.

TaoOfSalad

@Socks said:
The link between prototypes and instances is still broken, makes laying out large complex actor heavy projects a real pain.

We can look into this; perhaps you can provide some more specifics in a bug report. We made two fixes recently for when you open an instance to edit, the attributes and behaviors wouldn't reflect changes to the prototype. I suspect maybe the remaining issue is not in the actor editor but when editing the scene layout? Does the issue affect preview/publishing or only editing?

Socks

Interpolate bug present and correct.

I'd miss it if were to be fixed, it's like a little pet bug

Socks

@BlackCloakGS said:
Socks can you give me your support ticket for "The link between prototypes and instances is still broken, makes laying out large complex actor heavy projects a real pain."

I've not got a support ticket for _"The link between prototypes and instances is still broken, makes laying out large complex actor heavy projects a real pain".

I've mentioned it several times in these threads working on the notion that: "We'll be watching the forums and support tickets for info on this".

I won't submit it as a bug - and I won't bore you with my reasons - if you want to fix it that'll be cool, if not then no big deal, it's not a show stopper, it just makes working with GameSalad a little more of a struggle in certain scenarios.

Socks

@TaoOfSalad said:
We can look into this; perhaps you can provide some more specifics in a bug report. We made two fixes recently for when you open an instance to edit, the attributes and behaviors wouldn't reflect changes to the prototype. I suspect maybe the remaining issue is not in the actor editor but when editing the scene layout? Does the issue affect preview/publishing or only editing?

A simple example would be to make an actor, drag it onto the scene 5 or 6 times, then change the colour of the prototype from its default white colour to - for example - blue, now take a look at your scene, all the actors are still white.

The issue does not effect preview (and presumably then publishing), the main issue is that it makes laying out actor heavy projects a pain in that once you've dragged your actors onto a scene you cannot then adjust their colour (as it appears in your layout), deciding to change the colour of - for instance - a brick, where you might have 200 in a scene, involves removing all 200 bricks, and then placing them in the scene again - something made all the more harrowing given that GameSalad places actors to sub-pixel values so you need to open up the attributes for each of the two hundred actors and manually round both the X and Y position values up/down.

This (200 bricks) might be an extreme example, but I've had situations that have come close.

Quitting GameSalad can often force the instances to take on the correct colour - but not always, in the first incarnation of this issue you could double click on the instance, unlock the actor, then hit 'revert to prototype', you might not want to have to do this to 80 actors, but it worked, this no longer works as a solution.

Hopscotch

@Socks, reverse psychology? I must say I haven't noticed it anymore, not even when copying copies of actors on the scene.

Socks

@Hopscotch said:
Socks, reverse psychology?

Yes. (no).

AlkaPP

Hi, I see that the creator was updated 4 or 5 times this week. Just want to say thank you to Gamesalad Team for working very hard on fixing bugs

TaoOfSalad

@Socks Thanks for the detail. We'll get this issue into the database. In this case, I think it was a reported bug that was only partially addressed but some cases were not covered. The more detail we have, the better we can investigate and do regression testing.

Socks

@TaoOfSalad said:
Socks Thanks for the detail. We'll get this issue into the database.

Cool !

Hopscotch

@Socks, @TaoOfSalad, does the color attribute not fall in the category of self.attributes and its values SHOULD be independent of the prototype?

If all the instances change color when you change the prototype's color ... that would be a bug in my view. You would not be able to individualise colors of instances.

NimbleBug

@BlackCloakGS Yes, I know we need to get load times down. I will see if we can find a path or a small fix to do to try to bring them down.

Thanks

BBEnk

@BlackCloakGS‌ , @TaoOfSalad‌

This Bug I reported and you guys told me you could not reproduce I think is related to what @socks is saying.
for me its putting a actor on the scene and then opening said actor and clicking revert to prototype and it will goto x0,y0.. And then goto prototype and change X,Y to say 512/384 and then go back to scene and actor will still show at 0,0 BUT you can't click on it because it's really at 512/384 at least the hit zone is. and if you click there it will highlight and if you move it the image will snap to it.

Its still in this build.

TaoOfSalad

@Hopscotch said:
Socks, TaoOfSalad, does the color attribute not fall in the category of self.attributes and its values SHOULD be independent of the prototype?

If all the instances change color when you change the prototype's color ... that would be a bug in my view. You would not be able to individualise colors of instances.

I'll have to look at the code but I think no for the case of color. What matters to the engine is if the attribute is overridden (unlocked, not reverted) from the prototype or not. When you drag an actor onto the scene, it creates a new instance and always unlocks the position.x and position.y to reflect where you dragged it to. I think size and maybe rotation might be the same way because you can alter the size and rotation from the scene layout. But color doesn't have that special treatment. An instance should be locked to its prototype's color until it is explicitly overridden.

If that's not the case, that's worthy of a bug report. Position, size, and rotation might be automatically overridden (unlocked, not reverted) when you drag an actor onto a scene. But other attributes should stay locked to the prototype.

EDIT: What's most informative is if the scene editor layout matches preview and publishing. If it matches, then that's what the engine interprets and everything is consistent. If there is mismatch between editor and preview, then that's a bug because the editor's data isn't being updated on every change.

Hopscotch

Thanks @TaoOfSalad, if it keeps its color when overridden and only changes to the prototype when unlocked and reverted again, then its fine.

If the color was never altered from that of the prototype, then it should stay in sync with the color of the prototype as @Socks requests.

TaoOfSalad

@BBEnk Yes, prima facie, I think it could be the same issue. I'll include your test case with the new bug report.

Socks

@Hopscotch said:
Socks, TaoOfSalad, does the color attribute not fall in the category of self.attributes and its values SHOULD be independent of the prototype?

No, the colour has always reflected changes made to the prototype.

It only started displaying this new behaviour when the link between the prototype and instances was broken a few months back.

In situations like the one sketched out above (a scene with 200 'bricks') you could lay your scene out safe in the knowledge that you could adjust the colour of the bricks at any stage in the project's progress - and all 200 'bricks' would follow the prototypes colour.

@Hopscotch said:
If all the instances change color when you change the prototype's color ... that would be a bug in my view. You would not be able to individualise colors of instances.

You individualise colour in the same way that you individualise any other attribute, If you want a particular instance to be green (while all the others are yellow) then simply unlock the actor and change it to green. This is the same for every attribute.

If you change the rotation speed value in your prototype you should expect to see it reflected in every instance of that actor ! And when you do that's not a bug ! And if you want to individualise the rotation speed value of just one brick, then unlock it and change its value.

Socks

@BBEnk said:
. . . . BUT you can't click on it because it's really at 512/384 at least the hit zone is. and if you click there it will highlight and if you move it the image will snap to it.

At last ! Snap to grid !

Socks

@TaoOfSalad said:
EDIT: What's most informative is if the scene editor layout matches preview and publishing. If it matches, then that's what the engine interprets and everything is consistent. If there is mismatch between editor and preview, then that's a bug because the editor's data isn't being updated on every change.

Yes, that's basically the issue, the scene editor layout does not (always) match the preview.

stueynet

@BlackCloakGS said:

Fixed Animation behavior prompting user with image sequence popups for every change made. Now it should only pop up when the user drags multiple images from Finder or from the image library.

Perhaps I am insane but since upgrading to RC6 It prompts me for sequence or not every time I open any actor that has any animation.

BBEnk

@TaoOfSalad said:
BBEnk Yes, prima facie, I think it could be the same issue. I'll include your test case with the new bug report.

No need for name calling.

BBEnk

@Socks said:
At last ! Snap to grid !

LOL, I think they did it wrong.

Socks

@BBEnk said:
No need for name calling.

imGua

@BlackCloakGS is it normal that a 8bit image with tranperent parts saved in PS, no linger has transparent parts? Transparent parts of image are white now.