big problem - new game salad version has nuked my builds

SquareHeart

I uploaded a new build of super spin tanks to the app store, turns out it has critical crash bug on game start. argh!
Reloaded old versions - all have the same problem. I have no idea what the problem is, but it seems to be something to do with the new version/s of GS.
I thought I could resubmit an earlier build - but got this error on delivery to the iOS application loader!

any suggestions, especially with the above upload errors? If I can get a stable build back onto the App Store, thats the first hurdle - need help!

hah and my PRO membership only just run out, great timing

Hopscotch

@SquareHeart‌, the are quite a few current versions of GS at the moment. Which do you mean? Stable, RC, Nightly and which version?

SquareHeart

current stable build, including previous RC builds.
Think i've found the culprit behaviour, but no idea how to fix it currently..

This wee behaviour is what connects the tank movement behaviour to the players touch input. I've looked through the touch input behaviours, and that all works just fine.
The tank behaviour is an extremely simple conditional for tank movement.

As a test i've moved this behaviour off the tank object and to other various objects - I'd thought it might have been a code order problem, but it all causes the same issue - a total freak-out lockup. The magnitude is kinda critical to work - but there is some real nasty conflict occurring.

This has been a stable game since it's 1.0 release, with no change to this code.

BigDave

@SquareHeart
kind of confusing that you add info(code) about your tank in-between.

I think there is a warning at the top of the screen in the portfolio section that you should not release any iOS builds until the new version is there.

SquareHeart

@BigDave said:
SquareHeart
kind of confusing that you add info(code) about your tank in-between.

I think there is a warning at the top of the screen in the portfolio section that you should not release any iOS builds until the new version is there.

The behaviour is as required - player taps where they wish to move to -> touchTarget actor indicates where you have tapped -> tank actor auto-drives to the location.
Control, other than firing, is indirect in a sense.

I had held off from updating the game until a stable build was released 11.11.11 - There was no warning that I'm aware of for this build.

Hopscotch

@SquareHeart‌, are you saying that if you remove this code then the API-issue goes away? Or how did you localize the problem?

Approw

@SquareHeart‌ try reinstalling gamesalad and give your mac a reboot. I had some weird errors to a while back. Not sure if it's related to this but give it a shot if you cant find any other option.

SquareHeart

@Hopscotch said:
SquareHeart‌, are you saying that if you remove this code then the API-issue goes away? Or how did you localize the problem?

I, actor by actor, removed them from a game until I only had the offender left - then I worked through the behaviours until I found it - I then introduced other actors back into the scene to see if there were any weird interactions (all good). I then loaded a fresh scene and turned off the offending behaviour on the tanks - getting a working scene.
I also checked that the touch input wasn't wigging out.

SquareHeart

@Hopscotch said:
SquareHeart‌, are you saying that if you remove this code then the API-issue goes away? Or how did you localize the problem?

Actually two problems (I should read your question better
1) Actor behaviour causing game lockup using newer GS versions
2) As an interim I attempted to resubmit binary (from october 2013) which threw up the API errors - no API errors on uploaded binaries from newer GS versions (but instead broken game

SquareHeart

@Approw said:
SquareHeart‌ try reinstalling gamesalad and give your mac a reboot. I had some weird errors to a while back. Not sure if it's related to this but give it a shot if you cant find any other option.

trying now, lets see if 'turn it off and on again' works...
app zapped everything, rebooted and reinstalled - no dice....

The_Gamesalad_Guru

Redo the behavior from scratch. don't just drag it out an in. The behavior itself could be corrupted or the actor could be corrupted.

Hopscotch

@SquareHeart said:
2) As an interim I attempted to resubmit binary (from october 2013) which threw up the API errors - no API errors on uploaded binaries from newer GS versions (but instead broken game

So, actually good news that the latest GS does not have an API problem.

Now it is down to solving your lockup.

Do as @The_Gamesalad_Guru‌ suggest and recreate the offending behaviour. It is rare, but something could have gotten mixed up in the code file.

SquareHeart

Ha! found the problem - f***en Tables!...TABLES!

• I'd found this problem this morning - It wasn't reading any table behaviours if I'd used a string to find the row or column. WTF! converting all my table behaviours to get a variable by an int now makes it work (side-note I discovered hidden in my tank movement group some extra behaviours (cheeky otherwise) just now.

• Well now..when did this happen? when did the 'read values out of a table by using the named row or column' suddenly not work?

GSAnimator

@SquareHeart said:
Ha! found the problem - f***en Tables!...TABLES!

• Well now..when did this happen? when did the 'read values out of a table by using the named row or column' suddenly not work?

Congrats on you found it This happens since 0.11.0.14 but it's fixed in the newest RC 0.12.x

Zhong.

SquareHeart

Thanks everyone for your time, I appreciate it.