Anyone know how to get the height of the individual divs?

Since the construct object doesn't automatically size itself to the HTML content.

Ashley is right- you need to use the Socket.IO Construct 2 plugin to connect to a Socket.IO server. - I've never used that Websocket plugin *shrugs*

I recommend this one : scirra.com/forum/socketio-mod_topic63284.html

I'm also going to try learning the Javascript Plugin SDK to try updating (recreating) the PubNub Plugin. (Pubnub => pubnub.com/)

Good Luck with your Game.

My Socket.IO Settings

io.enable('browser client minification');  // send minified client
io.enable('browser client etag');          // apply etag caching logic based on version number
io.enable('browser client gzip');          // gzip the file
io.set('log level', 3);                    // ---0 = Errors --- 1 = Warn --- 2 = Info --- 3 = Debug---
io.disable('destroy upgrade');

io.set('transports', [
    'websocket'
// // WARNING // // USE ONLY WEBSOCKETS WHEN USING SSL (WSS) SECURE // // WARNING // // USE ONLY WEBSOCKETS WHEN USING SSL (WSS) SECURE // // 
 // , 'flashsocket'
 // , 'htmlfile'
 // , 'xhr-polling'
 // , 'jsonp-polling'
]);

<3

This sounds like how the textbox should be by default.

I suppose so. Which makes me wonder why previewing makes it think you're not using Socket.IO.

Add

io.disable('destroy upgrade');

[io is related to the "require('socket.io')" statement]

I am also doing some work with Websocket-related things at the moment. So far, a lot of it is rather irrelevant to Construct 2 minus the plugin you choose to use.

Websockets are exactly what they are- a websocket. This means that a lot of the extra features are just purely not present.

Socket.IO brings in extra functionality. It uses websockets but also has things like rooms(channels) and fallback policies*. A reason to not use Websockets is that if you don't need that functionality or you want to custom add what you want.

*Fallback policies are presented when a client fails to utilize websockets. This can allow non-websocket accepting browsers and mobile devices to still have a websocket-like connection.

Note: Preview mode when using Socket.IO seems to always use a non-websocket mode.

Can we get an example of each color scheme in question?

Edit: Nevermind, I have construct 2 installed on this PC ;) sec

Edit2: Nothing seemed to change even after restarting like it says *shrugs* Anyway~ pick a good one =]

Significant things are significant. So take your time.

<3 Np. I think we were pretty much over anyway, haha.

— MySQL statements.

— Two hours seems a bit much but alright. Also, remember to escape the variables before they go into the database. It's also a good idea to configure firewall settings to avoid user access to ports outside of the ones they are supposed to access.

Good Luck!

—

I'm not too educated in this matter but I spent several days trying to figure out a solution to something I learned. I wanted to make a tutorial at some point but I didn't want to mislead if there was something I missed. Therefore, feel free to look deeper into the things I mention- if you have concerns. I wont be sharing code at this moment. I also wont be writing those tutorial pages (yet anyway). I'm just going to give you way more than you asked for in one post. It will perhaps come in handy for you or anyone who searches this in the future- and so here we go.

I'll start off by saying this. If you're doing operations on the client-side a person who wants to attack knows exactly what you're doing. Never depend on the client-side. Never trust the client-side. It can be manipulated. So the best way is to always design away from a client dependency.

Now. I don't recommend sending passwords in plain text on the basis that it's the most frowned upon thing. A single encryption on the client-side should be fine. Do not mix encryption unnecessarily. It will weaken your encryption when you're not careful.

You're going to want to get an SSL Certificate. These can be moderately difficult to understand at first. I'd go way more in-depth but this post would be giant. You can get a cheap SSL for around $10 a year. RapidSSL, Comodo, TrustSSL(GeoTrust), DigiSign, Verisign. You'd primarily want one of these, and for this- preferably the cheapest.

It will latch onto ONE domain (example.com) and the immediate subdirectories (example.com/*). It will not latch onto, (*.example.com) or any of those subdirectories (*.example.com/*).

Wildcard SSL exists and covers the domain, subdomains and all subdirectories (*.exampledomain.com/*) but they're a lot more expensive ($100+). I don't think you'll need Wildcard or an EV SSL, so don't be too concerned with those.

SSL is great. It helps give an extra layer of confidence to your members. The most important part here is that it will encrypt information that transfers over the line. It will also help indicate if something seems tampered. Although this is a huge plus, it comes with some drawbacks. Things that come from non-SSL connections will sometimes get blocked by your browser. You can also encounter things such as Cross-Domain and Cross-Origin more frequently. However, it's all part of the development process and it feels good once it's done.

Note: exampledomain.com IS NOT secure. You have to use https:// and you can use exampledomain.com as the port is not what is important.

So, with all this you should be able to get the data from the client to the server. The important part now is storage. SHA and MD5 are very fast encryption methods. This sounds good on paper but is horrid against crackers.

There is a fancy way of offloading a particular cracking to a graphics card. SHA/MD5 being run through multiple machine's graphics cards can hit up to millions of attempts every second. A lunch break could become disastrous for many people.

Now, this would most likely only be the most determined of people out there. You'd have to paint a huge target on your back to piss them off. Maybe you could *shrugs*. There is a possible protection from this.

There is a method called PBKDF2 which will run a SHA512(or 256, not sure which) over and over to the extent that you specify. The more times the better. It connects something called a Unique SALT value to the password and re-rusn the encryption thousands, ten thousands and hundred thousands of times making it require more resources to hack.

Another newer method is called SCRYPT. This hasn't been tested too much so it's not openly recommended. However, this method takes an increased amount of resources. This would essentially mean it is very difficult to crack these values. This of course depends on the settings you specify.

You can find PHP libraries of PBKDF2 and SCRYPT. You can find NODEJS libraries that can help do this in Javascript alongside Socket.IO.

Now I told you it would be easy to understand. Well- at the core of it- it is. The true issue is that PBKDF2 and SCRYPT can skyrocket the CPU usage and RAM usage very easily depending on the settings you choose. Keeping them lower, you might be fine. However, if a lot of logins have to be processed at one time- things get very complicated.

I'd recommend trying them on low settings and going with that. I wont be sharing my code any time soon (as I'm still using and developing it) but this is some idea of security. It's tough. I just hope I could clear something up for you.

I wont go into details but also look into something called Cloudflare.

Note: Make sure to understand what they do with SSL because if you buy a certificate it wont work with their Free nor the $20 plan.