NW0.13.alpha5 Testing Report **Alpha6 Works!!**

— - ha - you're right, but only if you use Scirra's nw.js v13 installation. The one from github works just fine for me...

Edit - "just fine" does not include full screen or kiosk mode. All looks like a rather rushed introduction of an alpha nw.js to the c2 output schedule IMO.

The one from github 0.13.0 alpha 5 doesn't work for me at all. Only Scirra's version does.

It's a good sign there though, performance up, no memory leak.. just a few bugs to sort out.

That's rather disheartening, —! I would much prefer we all had the same bad experience than each a different version of incompatibility :/.

That's rather disheartening, —! I would much prefer we all had the same bad experience than each a different version of incompatibility :/.

Yeah, that's predicts some possible future issues.

megatronx - I agree - and I fear it's the beginning of a new 6 month cycle of "they're fixing it".

megatronx - I agree - and I fear it's the beginning of a new 6 month cycle of "they're fixing it".

If writing to external file is working in this release, then it could be a possibility for workaround, and could or even then should be implemented by scirra, if only temporarily.

The option to write to an external file in NW.js has always existed — I was ignorant to the simple method of using the already available features, and I guessed from the discussion that not many others here had tried it. We see storage plugin so assume that it's the only way to store data - when it's not, in this case. Browsers can't access the files but NW.js can... The plus side is it's already supported by scirra; the down side is it's arguably less secure because it's easy for an average user to find the files and then edit them (I think it would be wise to check that your data has not been tampered with when using this or local storage because neither are secure).

The option to write to an external file in NW.js has always existed — I was ignorant to the simple method of using the already available features, and I guessed from the discussion that not many others here had tried it. We see storage plugin so assume that it's the only way to store data - when it's not, in this case. Browsers can't access the files but NW.js can... The plus side is it's already supported by scirra; the down side is it's arguably less secure because it's easy for an average user to find the files and then edit them (I think it would be wise to check that your data has not been tampered with when using this or local storage because neither are secure).

I also want for everything to work tip top, but sometimes we all need t improvise, and unfortunately in the digital realm improvisation is contained to a narrow framework.

I'm glad I decided to create my own save/load in my current project by writing/reading file instead of relying on the built-in method.

I'm glad I decided to create my own save/load in my current project by writing/reading file instead of relying on the built-in method.

Test it for 0.13 alpha 5, see if it works.

The only difference between using the default save/load to the custom file write/read is that you have better control of what data is saved, but the file still needs to be stored somewhere.

This is where the bugs are crippling. The new NW.Js ignores your set data path, it sets its own temporary folder so your file isn't there to be retrieved in the next play session.

I had a Nexus 5 mobile from Google. An Android update broke my mic/earpiece function, the phone would only work to make calls with headphones. This was an official Google product which they charged a lot of $ for and they screwed it up badly. I have NO faith that Google knows what they are doing.

This is why reliance on them to get Chromium right, for C2 and later C3 to function well, is a mistake.

Edit: Can't seem to test with the C2 NWjs object (for file control) for the new 0.13.alpha5, project exported with that object fail to start and just hangs, but without the object its fine.

—

I have tested and my custom setup does work but strings have become an issue. Dictonary is not functioning properly for me, As that is how store my labels/titles for the save game slots.

MelVin,

!

Are you able to make a bug report - I'm guessing the problem is loading a dictionary as JSON from a saved file?

Colludium

I'm just testing it again. I think I might have got it working. Exporting now to test it

Colludium

Exporting breaks my game. it just hangs at a blackscreen. So I can't export withh NW.js wth this version.

But everything is working, with the exception of "fullscreen on start of layout" when testing using NW.js Preview though. Once I over wrote/Re-saved, the custom saved games seem to work. That's including the the labels/tiitles for the save game slots. So I think dictonary is working correctly.

I tried testing the earlier version of my custom saved games only capx. The exported version does not load as well. But does seem to be working without issue on preview. Trying to figure out why it will not export properly now.

MelVin

That's what we found right away, cannot export with NWjs object, game wont start, blackscreens.

So anything that uses that object is a no-go until this bug is fixed. I'm writing a custom save/load using arrays & JSON write/read with NWjs file access, this goes into a set path, output into text files so that it may avoid future save issues. But we'll need the bugs fixed first with the current alpha5 and C2.

—

thanks for telling me, you've saved me a lot of waisted time. it's awesome that you're doing a custom save games, I based mine on andreas R 's template, with this I was able to adjust mine and get it to work. I would love to see something done by someone else, compare what I've done, see were I can improve mine cause I feel I'm still learning. If I can help let me know.