ChrisAlgoo

Great news, he didn't seem to want to work on a situation at the time. but I guess nearing completing he has realized that a alternative than browser parser was required.

Saves me some work :)

It might be a better demo if you had a sample URL we could use :)

> I am talking about resuse of code between projects. Yes, it can be done with importing a whole project and copy/paste between event sheets but this is far from an elegant solution. A more modular system is in the works so it is only a matter of time... you could just copy-paste functions

That doesn't include objects that they are linked too. So if the Function refers to a sprite it won't copy. Of course you can copy a sprite, but the job get's bigger and bigger.

Where as a proper module export will create a plugin like object that can be easily shared and used by many. Including if the share module is updated.

ChrisAlgoo

No, you won't be able to use CAAT. That's entirely different structures of animation and setup.

I know where your coming from. However, I did some research into this myself on the the technical level and found some nifty things.

Spriter for C2 uses DOMParser, which is just modifies the xml string into a window document. The Window Document is still mostly a string. Spriter uses browser based xml parser functions to go through the string to get the relavant information. SpC2 uses only about 3 functions to do the job and only does it once to load the object.

Since it is only string based parsing it will be doable to create an alternative set of loose ends for CJS so that Spriter will work in CJS.

I have a plan, but won't be working on it until the end of the month. I'll make a post in the Spriter thread when I have more on it. But even though CJS and Spriter won't do anything about it. doesn't mean we are completly lost :)

Ludei was saying that last month :|

— Thndr

I have to agree with Thndr here. back when I first heard about Photon for JS I tried it out. The tool set was very in adequate. Photon Cloud aside, Photon JS couldn't even make full use of Photon at all.

It was bizaar reading Photon replies to Velotjet on their own forums. "not enough interest so we aren't focusing on js". Sorta a dumbfounding concept. Oh well. Not much can be done about it now. Just time to move on.

Thanks for the encouragement. I will update as news comes in. Right now we are only tinkering some of the design to java script. We are working on solidifying the inter client/server/node messaging before getting the game features going.

well if you using physics. make sure your not using pin behaviour. use joints in the physics.

be sure to reduce the weight, friction of the tail pieces and any other values.

I created a tail for a game once, and that took a large number of adjustements. but the results work out fairly nicley. though if there was too much momentum the dragon would get smacked by it's own tail and pushed around :D

Not to trivialize the conversion, but I think Construct2 is just about perfect as is and some of these suggestions would add a layer of complexity and unreliability that would really compromise the features that make C2 so attractive. The pipeline has been quite smooth and we get incredible features (like 3D sound, etc.) made easy and on a regular basis.

I would not change a thing about the current development model.

You probably wouldn't even notice inline scripting. So it's the same matter. Why not, it doesn't need to be used, and will have no impact on developers who don't want to use it.

that was an amazing story of Klei, I had no idea they were a local game company for me :D

Drop Canvas link didn't work for me :(

I hope some one takes this contract :) I think it would be well worth it for some :)

breackzin

We are currently looking at Redis for a model of storing data on the server side. However you have a good point. An easy way to identify what data should be easily stored is a good idea. We will look into that. As an initial thought maybe we can use C2 Dictionary as a model of storage.

We are not using socket.io, we are currently working with raw websocket. Go language does not support socket.io. :( socket.io however is mostly a wrapper of transports to have all the transports look like websocket. It's a nifty piece of tech :)

We will be making tutorials once we have the first development release to share.

newt I understand your pain. I have lost posts too :D

Well BubbleBath.exe is a raw message handler that forwards messages to clients or nodes and then back and forth. At that level there is no need for authentication. However and often any game with persistent player data requires protection and access by security. So I am actually keen on considering how this can be provided to the C2 developer.

Now this is just an initial thought that been floating around. BubbleBath won't handle authentication. Often Facebook, google login, twitter and all these other sites tend to use proxy logins. A request is made by the client side to login. This is linked directly to to the authentication site and not through visiting site. This validates a cookie for the site to access limited data from FB/Google/Twitter...

Now I have thought about this already because I wanted to possibly integrate Clay.io. We shouldn't get the user password, instead we need a proxy pass that the client sends to bubblebath to use.

The other alternative is that we can look into providing a local user account system. In this model we would build this in C2 so that developers could customize an authentication system.