mrexcessive's Forum Posts

  • IntelRobert

    Thank you for the explanation of the difference... I'll consider which to target next game not this time, but worth thinking to reduce size for simple things I make

  • codah

    IntelRobert

    Thank you... yes you're right that is a trap, but (on this occasion) it wasn't that problem I think probably I just copied the wrong .zip file across *slaps forehead*

    One strange thing with the XDK production route is that the APK files are approximately 20Mb each, but the HTML5 version is total of about 2Mb. That feels like a lot of cruft to me ? Is there some way to easily strip out things unused from APK files ?

  • IntelRobert

    Working through rebuild, it seems to be necessary to update minor version number, prior to running build, to persuade GooglePlay dashboard to accept the new APKs

    Update: changing the version code on the Project/Build Settings/Crosswalk for Android page does _not_ seem to fix it. Still rejected by GooglePlay for having same version number...

    On examination the Crosswalk build seems to be failing to take the updated version numbers into account (the APK coming out has same version number as previous, despite uploading all the source again during build)

    Any ideas ? Will continue to work backwards towards Construct2...

    Further Update:

    XDK build process is broken, I think... It runs, but just FAILS to transfer the updated version number from Projects/Build Settings as described above. IntelRobert please advise how to force XDK to update the version number in the output .apk files

    My apologies if this is somehow obvious - I've searched around the web a bit and other people seem to be reporting same problem with XDK

    Final(!) Update:

    Worked after restart XDK. Suspect problem was me not the s/w. Definitely messy getting GooglePlay to accept updated apks though. Put both x86 and arm versions.

    Thank you for your time and help.

  • IntelRobert

    Thank you. Wildo.

  • Tekniko it's out of our hands because the XDK needs to be updated. IntelRobert says it will happen after Crosswalk do their own update... so Cordova->Crosswalk delay, then Crosswalk->XDK delay then XDK->us doing rebuilds. Hopefully GooglePlay will hold off from removing things until after that whole chain of rebuilds is complete.

  • IntelRobert thank you. Hopefully googleplay will hold off from store removals until time to rebuild right down the chain.

  • russpuppy alvarop anyway out of our control - which is very frustrating! I miss developing for a single platform sometimes... all the intervening opaque stuff that happens...

  • Same message for net.mrexcessive.flickmath - don't think we can fix, needs Intel to resolve.

    (for clarity, I built the apks with XDK... so whoever produces the XDK needs to fix ?)

  • Have the same issue, received today:

    { note I am building APKs using Intel XDK }

    This is a notification that your net.mrexcessive.flickmath, is built on a version of Apache Cordova that contains security vulnerabilities. This includes a high severity cross-application scripting (XAS) vulnerability. Under certain circumstances, vulnerable apps could be remotely exploited to steal sensitive information, such as user login credentials.

    You should upgrade to Apache Cordova 3.5.1 or higher as soon as possible. For more information about the vulnerabilities, and for guidance on upgrading Apache Cordova, please see http://cordova.apache.org/announcements ... d-351.html.

    Please note, applications with vulnerabilities that expose users to risk of compromise may be considered “dangerous products” and subject to removal from Google Play.

    Regards,

    Google Play Team

  • Well there were going to be dancing squirrels, but it's been a busy week.

    http://web2.mrexcessive.net/NutRace/

    [attachment=0:39pnqwgl]Level2small.png[/attachment:39pnqwgl]

  • Thank you. LinkMan I'll do a multiple layers experiment... mrcgkh I'll try out once I get latest Construct2, I don't normally get the betas.

  • Linkman thank you... that's worth trying. It will produce unnecessarily messy code if changing a load though, also will constrain the two things to happen close in time. I'd prefer to be able to set Zorder explicitly - from your reply I take it that isn't possible ?

    Would there be any problems with the many layers approach (I'm now thinking of doubling tile dimensions and having only 20 layers...

    Your thoughts appreciated.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Hi. I am displaying an isometric tilemap... with the (0,0) tile (on the grid) mapped top centre. This means that the required Z-order for any particular tile representing a grid location is given by Z=x+y... So each 'diagonal on the grid, horizontal on the screen' row will have tiles with the same Zorder value - they cannot overlap so that is fine and normal for iso.

    If necessary then I could generate unique Zorder values across the 'width' using (x+y)*100 + x or something similar.... anyway...

    If I replace a tile somewhere then I could just set the Zorder for the newly created tile as I know what value I want to give it.... but Construct2 does not seem to let me do that ?

    Is there any way to avoid having to loop over the entire grid everytime I replace a single tile - the visible grid is 20x20, so this a non-trivial nested pair.

    I was expecting to find a settable property: Family.Zorder = <value> and be able to just set it myself! Please advise how I can do this.

    One possible alternative approach is I could create 40 layers specifically for the iso tiles - but would this be hugely inefficient when the layers are drawn ?

    Cheers

  • Yer... Well I did search around and this seemed to be the most relevant... didn't notice it was for Classic... Apologies! Will repost on a new thread as you suggest... thank you.

  • Hmmm... replying (without an answer) to my own post. The Layers are supposed to be very efficient... As I have 40 distinct tiling Zorders, would it be reasonable and/or sensible (!) to create 40 layers for the Zorders of iso tiles and then set the layer number programmatically, which does seem to be possible.

    Or perhaps that will have some unpleasant side-effect such as greatly increasing number of draw calls ?