Hazzah!

hopefully I have got rid of that error, and now it exports ok and also minifies ok.

was a lot more involved than I bargained for. Oh and authentication is working with facebook or email/password

myeah so I have done async and pushed the load flag onto a $.Deferred object.

I have wrapped my functions to wait for the loaded promise before using the library. This has the advantage of not pushing the async race conditions downstream to the user. But it is a massive pollutant to my codebase for the sake of not being able to do normal HTML 101 stuff.

I am not particularly happy with this solution. Give use remote-dependancy! It will cause less bugs in the ecosystem in the long run!

EDIT: well those pollutants were nothing compared with trying to evade the closure minification on a 3rd party asyncronously loaded library! lol

EDIT:

deleted

OK I will do async.

I want to add a remote JS library in a <script> tag in the HTML. I added the dependencies like so in the plugin properties:

"dependency": "https://cdn.firebase.com/v0/firebase.js; https://cdn.firebase.com/v0/firebase-simple-login.js"

which somewhat works (the exported HTML is correct) except that C2 installations with debugging turned on complain the dependency cannot be met (locally).

But I do not want to include the JS libraries locally, as that is the mechanism by which you get around same origin policies. It's for *very useful* database-as-a-service integration Firebase. (http://www.scirra.com/forum/plugin-firebase_topic79393.html)

Is there another way I can add my own <script> tags in the HTML. Dynamic loading of external JS is not an option (like how facebook does it), because the plugin needs the API immediately.

Great!

Firebase needs to be an external API so you can get around the same origin policy and actually do database like things. There does not seem to be way of adding remote JS libraries in a nice way but I will ask elsewhere.

I appreciate you giving it a spin and your debugging help a lot.

Oh ok. I think thats because I said the plugin depends on "https://cdn.firebase.com/v0/firebase.js", a remote file, which I did so it would insert

<script src="https://cdn.firebase.com/v0/firebase.js"></script>

in the HTML. I think it expects that file to be in the plugin directory though locally.

I don't have a debug version of C2 so it does not pop that up for me. Ignore it until I find another method for altering the HTML? Does it work in the browser afterwards?

works on mine. Any clues in the javascript console? (CTRL + J)

EDIT: just tested preview on Firefox, Chrome on Linux over network and fine. Does it boot the preview and die on the webpage or does C2 refuse to preview it (the later being a plugin install problem)? ***

*** wait whats the directory the plugin is installed as??? on my machine its "firebase" but that might have got screwed when you cloned from github...

The basic API is now in place. Your Actions are

(set, update, push*, remove) to (String, Number, JSON)

*push is for lists

you can register for real time updates of all event types:-

("value", "child_added", "child_removed", "child_updated", "child_moved")

You associate a tag on registration like AJAX, so then your tagged conditions trigger when data is received from firebase.

You can then use the expressions to get the data and URL references out

(ValString, ValNumber, ValJSON, Ref)

There is a capx demoing this functionality in github. A screen shot of the real-time database demo is at

github.com/tomlarkworthy/construct2_firebase_plugin/blob/master/demo/firebase_ui.png

MISSING FUNCTIONALITY from Firebase API:

error callbacks

transactions

authentication

filter queries

list order priorities

I probably won't implement all the missing parts, but I am quite keen to get my mits on authentication and transactions at some point (not massively urgent though)

The technical details of firebase are at

firebase.com

Firebase is a *very* capable serverless database.

Authentication supports

Facebook

Twitter

Github

Persona

Email & Password

You can set validation rules via a web gui, which firebase checks. So you can prevent certain types of cheating (e.g. you can't buy X unless you have Y cash in the bank). More complex logic won't fit in its validation rules (e.g. the rules of a game of cards), but you can add your own server with different permissions onto the firebase for those cases.

Firebase supports SSL (by default), so data is encrypted on the wire, its also compressed effeciently.

Oh and transaction support, which is a pretty neat technical feat on a real time over-the-web store. The database caches all data locally, so local data writes are fast, and they sync global writes in the background (a bit like dropbox). This avoids slow downs during poor connectivity situations (remember transactions!). Its very smart.

I have no idea if half these features can be mapped to construct 2. But just as a non-server database with validation rules its pretty hand.

Firebase v0.5

contribute github

download plugin only

run LIVE multi-user demo

Real time database-as-a-service integration. Have a real-time database without owning a server!

So far, you can:

• Set String, Numbers, Objects (as JSONs)
• Register for updates of String, Numbers, Objects
• Create (concurrency safe) lists of objects
• Register for list updates

Authenticate users securely using:

• email/password
• Facebook logins

Use the webgui (firebase) to:

-View/edit data

-set read/write access

-add consistency rules to be verified by firebase (stop cheating)

A capx is included in the repo for testing. All communication is encrypted and compressed. Tested on static HTML export, preview and minification. It will NEVER work with Cocoon, but Firebase does provide APIs for native iOS, and Android, so you can possibly get to your data in a complicated post process operation if you want native.

The project is hosted on github so if you need a feature and can add it yourself, add it yourself and send me a pull request! I have tried to comment my code to make it fairly obvious what the design is.

Tom

That's not true. Havok and suchlike decouple their physics from the frame rate and still achieve determinism via a time accumulator (which I linked, but here it is again gafferongames.com/game-physics/fix-your-timestep/).

Basically you only step the physics a fixed amount k, after after dt > k wallclock time has passed. You keep track of the remainder k-dt and use it in future calculations to decide whether to perform a physics step or not.

In summery, you decouple the physics stepping from the rendering thread entirely.

This means several frame renders may occur in series before actually updating positions. To stop jerkiness, you integrate the time remainder with the velocity and last updated positions. i.e. you linearise the motion model and project into the future when demanded by the rendering thread.

This decoupling physics from framerate is a common pattern in game development. But its not obvious unless you have seen it before, see also gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step

In construct 2 a event tick is tied to frame rate. So to decouple physics we have to decide whether to step or not. So we would need functionality to globally enable or disable physics evaluated every tick. Or choose to manually tick the physics ourselves in the event sheet.

you stars. I found a stepping mode in physics which does it!

scirra.com/manual/98/physics

EDIT: hmmm that doesn't quite cut it due to my other timers going off every XXX seconds and interacting with the physics.

I once implemented a time accumulator for a physics engine to properly decouple these things (gafferongames.com/game-physics/fix-your-timestep/)

I wonder if its possible to get that kind of approach into construct 2

EDIT 2:

yeah running my behaviours off of "every tick" with physics stepping on fixed made it deterministic. However my frame rate suffers. I believe, that if you were able to switch physics on and off rapidly and not process interactive behaviours every tick, you could play catchup with the frame rate like a time accumulator. There is no global on and off for physics though so I don't think it is feasible at this point.