The workarounds are due to the way XDK/Cocoon/etc. builds, not due to how Cordova builds. No workaround are necessary if you export to Cordova (no need to use the workarounds required for XDK) and compile locally.

It takes around 10 minutes to install the programs I listed. All of them have publicly accessible documentation. If you're too lazy to figure it out - and there's little to figure out, because the entire build process can be documented on a single page, and executed with the 2 or 3 listed commands, and you only have to dig in deeper if you want to customize builds - that's on you.

Sounds interesting...if I understand correctly, by running the build that way you'll obtain anyway an HTML wrapped apk, as for per XDK etc, but more reliable and solid (NOT more performing), without plugins problems etc and in less time, due to "direct" delivery of C2/C3 code to Cordova. Correct?

Sorry for the trivial question (I'm not a technician, as you can see...)

It would also be nice to have the ability to search through the project files and their contents. And search through all the events of the entire project.

+1

>

> > I'm not going to keep making the same points about native engines, I wrote a whole blog about it already.

> >

> > You should probably come up with a different name to talk about exporters - I equate "native exporters" with "native engines". I think you mean built-in exporters or something like that?

> >

>

> Yes, sorry for the terminology. As a Designer I speak a different language Built in exporter Is probably more in line what people mean when they talk about native export here.... Completely agree with the case against native, as I've read the blog post several time trying to wrap my hand around it. I could care less what codebase is used if performance is similar.

>

> So let me rephrase that.... How big of an hassle is it to have a "built in exporter" for mobile development? As a designer I'm jost looking for workflow improvements, less hiccups, and hassle.

>

> Optimal workflow... Create game. Hit export, upload to Store...

>

> Current workflow... Create game, hit export, import to 3rd party wrapper, build, get plugins working, .... it's not working... try again.... contact support... if you're lucky. Upload to store.

>

> I'm only looking for workflow improvements. How you guys solves it it's up to you. I trust you completely... native or non native, i could care less, as long as my game is downloadable from app store without having to use XDK and such.

>

Couldn't have put it better!

I think what the majority of sensible users are asking for is a built in exporter and wrapper all in one, that then spits out an apk/ipa.

This will definitely cushion the blow of subscription fee disappointment and convince users that the fee is worth it.

If they can do this then I'm definitely sold!

+1

I'm posting here just to ask for a native scirra compiler/exporter for mobile

Hi hmmg,

really a fabulous plug, and in my game project runs smooth & fast. But I have a problem with fullscreen

previewing the game on my PC...)

In more detail: my project preview starts in a window, but after the first touch runs in fullscreen as it receives a "Request Fullscreen". However, by calling Layout Transition 2.1 in one of the following layouts, it comes back to window format ... Any advice? thx in advance!

From Intel developer zone:

Intel XDK 2893 download

Submitted by SWATI S. (Intel) on Thu, 03/31/2016 - 11:52

Hello Developers,

Due to few issues in version 3088 of Intel XDK (which we are already working to fix), we got request to make the older version available. Although we highly encourage you to use the latest version of Intel XDK (3088), we are making the older version 2893 available for developers who really cannot work with the new version. The installation binaries are attached to this post.

Intel XDK team

Why? my idea was to have - with a minimum effort - objects able to grant cover to those hiding behind it *and* reachable/damageable by heavier fire.

Anyway I understand your point.

You're right if the game is a "not-so-realistic" platformer. But if (as in my case) the game is "realistic", the answer is yes - since I can perfectly see the wall, I want the possibility to elige it as my target, and perhaps smash it with a cannonball...

Of course I understand these are just my needs, and for dozens of developers they are different... this is ok, but again (and for the last time ) the manual does not mewntion at alla the targets properties, and one may assume that ANY type of object is ekligible at target.

Ciao

Very kind of you, thank you so much. So was necessary to write a couple lines of code, to run every tick, to have the Behavior perform in a logical way in this case.

Problem solved. Thanks again.

Ok, anyway, no problem, really - I try to explain my needs, maybe someone can help (see my example capx):

1. My player must have a clear LOS to every object he is actually spotting (i.e. to any vehicle of the first row), as happens in the real world. To achieve this, no object can be Solid or defined as “Obstacle” by events. Strange, but... ok.

2. Objects hiding behind the “big cats” in the first row must be out of player’s LOS, as they are covered (think of infantry hiding behind tanks). Again, nothing strange here, this happens in real world too. But if the green tanks are neither Solid nor defined as Obstacles they are (correctly) “transparent” to player’s LOS.

It's perfectly possible there is a simple workaround, but at the moment I’m not able to see it….

Sorry, I mis-explained, I intended for "sometimes" that the object may change its status switching Solid on or off, the times he switches off is visible and the times he switches on it's no longer.

So, an object may (but only sometimes) block the LOS to itself...? sound quite odd to me...