Monkey V70 now up! [MONKEY NEWS]
Monkey Forums/Monkey Programming/Monkey V70 now up! [MONKEY NEWS]
| ||
| Hi, Monkey V70 is now available. This is my first attempt at creating a release from the Github 'master' branch (which I'm yet to 'tag' as such) so I've uploaded it to the experimental section for now. Slowly getting my head around github, but there's a lot to learn! Souped up win8 VB performance; fixed several win8 bugs. Moved all input related constants to mojo.keycodes module. Put all native code imports inside #If target/lang conditional blocks. Added some BLAH_IMPLEMENTED checking to extern class decls in brl. Added InsertBefore, InsertAfter, InsertBeforeEach and InsertAfterEach methods to List. Semi major Android target change: moved Activity suspend/resume handling code from onSuspend/onResume to onWindowFocusChanged( boolean ). |
| ||
| X-/ |
| ||
| For the Android change, how imperative is it that we update our old apps and build them with this release? Is running the old way with OnSuspend/OnResume bad? |
| ||
| Is running the old way with OnSuspend/OnResume bad? Mark's talking about the native onSuspend and onResume methods in the Activity class. He's changed it so that the Mojo versions are now triggered by onWindowFocusChanged instead. You can still use the Mojo OnSuspend/OnResume. |
| ||
| Thanks Mark! |
| ||
| Awesome! Thanks. |
| ||
| booya! Thanks and nice one for implementing some of the missing list methods :D |
| ||
| http://www.monkeycoder.co.nz/Community/posts.php?topic=4904#53694 Did anyone else have problems with user data changes between versions or was this guy's problem isolated? I still have yet to test a post v66 build. |
| ||
| The SharedPreferences reference key used in SaveState was changed post-v66 from "gxtkAppState" to ".monkeystate". Compatibility could be re-established by changing the code to check for both. |
| ||
| insertafter looks useful thanks P.S. is there a way of disabling the thingy that doesnt translate 'unreachable code' cos I think the algorithm that searches for unreachable code has a bug with methods |
| ||
| > The SharedPreferences reference key used in SaveState was changed post-v66 from "gxtkAppState" to ".monkeystate". Compatibility could be re-established by changing the code to check for both. Gah! Can't believe I did that... I've added a check for the old prefs if the new ones don't exist, but if they've already run the game once that wont help, as there will be 2 sets of prefs there. Any ideas? |
| ||
| The only generic solution I can think of is to provide a temp/patch API for the app to load old or new so the app dev can choose which is preferable to keep then save it to the new key and delete the old one. |
| ||
| In LoadState check for "gxtkAppState". If found, create ".monkeystate", copy data associated with "gxtkAppState" into ".monkeystate", flag "gxtkAppState for removal and commit() changes. Then regardless of whether "gxtkAppState" was found or not, get & return ".monkeystate" In SaveState save state to ".monkeystate' Other than testing to make sure the create-copy-remove-commit all at once works as expected, this should restore the users preferences. |
| ||
| That would just prefer the old state to the new. There's no way to know if the old state is the one it would be best to keep at the Monkey level. If your customer is annoyed by losing their old state you can bet they'll be even more annoyed if you later restore that state and they've progressed further on the new one. |
| ||
| Well, my assumption is a patch will be released quickly, both for Monkey and for any affected apps, meaning any progress made by users (or rather re-made since they will have re-started from zero) will be minimal. And, yes, while users may be a bit annoyed at the back-and-forth, it will be negated by their pleasure at having all their previous progress back. :) |
| ||
| V67 came out last year so there's no knowing that the progress on the new state would be "minimal". |
| ||
| P.S. is there a way of disabling the thingy that doesnt translate 'unreachable code' cos I think the algorithm that searches for unreachable code has a bug with methods Enable reflection, this forces Monkey to compile everything. |
| ||
| @muddy_shoes: Ah ... I understand now. I was thinking in the timeframe of the post referenced, which is from only a few days ago. But your right: Apps could potentially be reverted to a state many months old ... Yikes! |
| ||
| Ok, LoadState fixed in v70b, and I've added a LoadState_V66b kludge for people wanting to access old state - see: http://www.monkeycoder.co.nz/Community/posts.php?topic=4936 |
| ||
| Probably the take-home lesson is not to release anything compiled with the latest Monkey version a day after it goes up! |
| ||
| This problem was introduced three major versions ago so waiting wouldn't have helped much. The lesson should be to test an upgrade release including retrieval of an existing save. Only ever testing clean installs is a big cause of "worked for me" bugs. |
| ||
| The WP8 performance is great now and my app runs smooth, just need the EnableKeyboard to work so I can try and release it. Thanks. |
| ||
| > The WP8 performance is great now and my app runs smooth, just need the EnableKeyboard to work so I can try and release it. I've had a look around, but can't find *any* clues on how to enable the virtual keyboard on Windows Phone 8. I assume it works with GUI (XAML?) apps, but I have no idea yet how to do it programatically in a C++/DirectX app, or if that's even possible. I'll keep looking but, in general, I don't think depending on Monkey to ALWAYS be able to activate/provide a virtual keyboard is a good approach (it already can't on XNA), and I probably never should have added EnableKeyboard in the first place! The time I've spent hacking this into shape might have been better spent on a 'dodgy-but-functional-and-works-everywhere' mojo module instead. |
| ||
| Mark, rip the EnableKeyboard code from monkey and provide it to the community. We've got some great monkeycode brains here who can run with it full sprint... If this is even feasible/reasonable. |
| ||
| This is the samples I have been trying to get into my Monkey project: http://code.msdn.microsoft.com/windowsapps/Touch-keyboard-sample-43532fda http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj247546(v=vs.105).aspx |
| ||
| Can't decypher the win8 sample as yet, but the winphone 8 sample is very useful, and I now have the keyboard showing! |
| ||
| Yay!, I know creating our own keyboards is the best way to go in the long run, but it makes life easier using the system keyboard, thanks for looking at this. |
| ||
| Any progress on multitouch for Win8 desktops? |
| ||
| I published two apps to the Windows Phone 8 Store and they failed as I need to get the app to respond to the phones back button, any idea if you will be able to add support for the back button? I have tried JOY_BACK and KEY_ESCAPE... Thanks. |
| ||
| Try KEY_BACK. |
| ||
| Thanks, I have tried KEY_BACK it seems that the back button just quits the app and is not captured by Monkey. |
| ||
| @Mark: Can we have a #GAMENAME variable that sets the app's game name so for example its no longer called 'MonkeyGame' but whatever we set the GAMENAME to. For example: #GAMENAME="EdzUps Game" Would yield EdzUps_Game.html for html5 and a icon on Android called 'EdzUps Game' this would make it much easier than editting the manifests every time. |
| ||
for android it is already integrated. Add this to your monkey code for the displayed name and for a unique GooglePlay name:#ANDROID_APP_LABEL="My Game" #ANDROID_APP_PACKAGE="com.mycompany.mygame" |
| ||
for glfw: #GLFW_WINDOW_TITLE="Monkey Game" |
| ||
| App name/package/whatever can be *very* hard to programatically change, esp. once the project is created. I think what is required for this (and other similar problematic 'setup' options) is an initial 'create project' phase that happens the first time .build dir is created. This'll happen, but not overnight. |
| ||
I would love to see versionCode and versionName for Android:#ANDROID_VERSION_CODE="1" #ANDROID_VERSION_NAME="1.0" http://www.monkeycoder.co.nz/Community/posts.php?topic=4010#42971 |
| ||
| @mark: brilliant news can't wait :-) |
| ||
I just tried building on my Mac for the first time in months but get this error from Ted:Monkey Runtime Error : Invalid module path for module:/Users/siread/Dropbox/my programming/MonkeyPro70b/modules/diddy/arrays.monkey What's up? |
| ||
| Is it coz there is a space in the path? Or coz the path is wrong? |
| ||
| Looks like it's the space. Was never a problem before. How annoying. |
| ||
| can you put quotes around the path does that fix it? |
| ||
| I'm not specifically typing the path, monkey is just building the app and finding all the necessary mods. And I've just made the mistake of renaming my entire programming folder which is in dropbox. Dropbox now needs to upload 10 gigs over my crappy broadband connection, then the whole lot then needs to be downloaded all over again on 2 other pcs! A serious design flaw in dropbox, that one. :( |
| ||
| And I've just made the mistake of renaming my entire programming folder which is in dropbox. Dropbox now needs to upload 10 gigs over my crappy broadband connection, then the whole lot then needs to be downloaded all over again on 2 other pcs! A serious design flaw in dropbox, that one. :( Whaaaat? So it doesn't just upload and propagate the name change on the folder, it actually treats the name change as a completely new folder and re-uploads the entire contents? That can't be right!? PS. DropBox n00b lol :P |
| ||
| Actually, no, that can't be right as it has finished doing it's upload thing. It did take a couple of hours though, so god know what takes it so long. Anyway, sorry for derailing the thread. I'll shut up now. :P |
   |