NicholasMDS Sounds like your not getting any ajax data back. If your running your capx in preview mode and not running from the same the server the AJAX file is located on, then your server will by default ignore the ajax request. Its a security function of php to prevent outside connections from accessing any data you don't want them to. On your AJAX file you need to add a PHP header call to allow access from out side connections.

<?php 

header('Access-Control-Allow-Origin: *');

?>[/code:wjqqpfrg]

How ever you need to do more reading on this subject as this line above will open up your server to all outside requests. Its dangerous to leave it in place as is but for testing this should fix your problem

It sounds like you want to hijack a condition on the event sheet to execute your plugin code as well as the action that was specified in the event sheet? If that's the case then the easiest solution is to just create an ACE action item for your plugin and then in the event sheet add it to the actions you call when a condition is triggered.

Your only other option is to override the ACE condition its self so when the condition is triggered its your code that executes. I have done this myself with regard to the Multiplayer plugin but it was much easier because the plugin used internal functions that triggered its own conditions so instead of overriding the ACE condition i just had to override the internal function and decide to either trigger my condition or the default one.

In your case you might try something like this to override the original.

cr.plugins_.SOMEPLUGIN.prototype.cnds.CONDITIONAME = function(){
       //Copy all original code that is suppose to execute and then add you own
}
[/code:ujtxo7g3]

You will how ever need to override it during the instantiation of your plugin and not add it as a direct function because the this needs to be overridden after the original plugin has been interpreted.

If I read your statement correctly then I think your using the On Error incorrectly? The On Error is triggered when ever the Ajax Request fails. (This almost never happens as long as the server is up). It should always complete and return what ever you echo back to the screen. You will need in the On Complete action to compare the Ajax.LastData (You should print this to screen in a text box for testing) to the 2 possible outcomes whether the name is valid or if it has already been used. As to why both the On Complete and On Error are triggering is bit of a mystery but that's moot considering your using the On Error incorrectly anyway.

If your running your capx in preview mode and not running from the same the server the AJAX file (postIn.php) is located on, then your server will by default ignore the ajax request. Its a security function of php to prevent outside connections from accessing any data you don't want them to. On your AJAX file you need to add a header call to allow access from out side connections.

<?php header('Access-Control-Allow-Origin: *'); ?>[/code:28h0ra1m]

How ever you need to do more reading on this subject as this line above will open up your server to all outside requests. Its dangerous to leave it in place as is but for testing this should fix your problem

leomachado666

Is your window (viewable area) located on the very edge of the layout when you attempt to shake? When you shake the window attempts to move a few pixels in all directions. If your window is located directly on the edge of the layout then there are no available pixels to show and it will prevent the window from shaking.

Here made you a quick example. When I set scroll enabled to the blue sprite the window moves to the center of the layout becuase thats where the prite is. this leaves room on all sides of the layout for the window to shake. Click the blue sprite to shake.

[attachment=0:2db08nix][/attachment:2db08nix]

blackhornet - Really nice plugin!... takes the guess work out of it. He will still need a larger layout but wont have to worry about scrolling to edge now.

multiplayer server appears to working fine for me. You might have a firewall issue

leomachado666 So the window is what the user sees. Everything beyond it on the layout is out of view... for it to shake the window needs to have viewable area on the Layout on all sides. so inrease your layout size to something larger than the window size. Then make sure your window/view port never gets to close to the edge of the layout. this way when you want the window/viewport to shake there is avaiable layout for it to show on all sides.

Sorry this crood mock up but it will help to visualize it.

[attachment=0:g3m92phw][/attachment:g3m92phw]

Your window is what shakes. It needs available space on all sides to move.

A few thinigs a learned about screen shake. I assume you know about the shake action available for a sprite that has the behavior scroll added to it. If not then that's where you find it .. how ever things i found are that the screen will not shake if the viewport is to close to the edge of the layout. Took me a few times to understand why but then i figured (face-palmed more like it) the screen cant possibly show me and area that does not exists which is what would happen if the screen wanted to shake but the viewport is right up to the edge of the layout. You will need your layout to be bigger but prevent the viewport from scrolling to the edge leaving just enough room that if you shake the screen the viewport has some wiggle room on the layout.

3rd'ed

The reason this happens for me is when ever i close C2 while having something in the search text. If i clear the search before i save and close then its remembered correctly what is collapsed and what isn't.

vitormb Since i don't want mail telling me im wrong let me start with I'm not an expert and don't know what best practices are and I assume others reading this may have more knowledge about this but since no one answered ill give my 2 cents.

Assuming your hosting your own server and as it looks by your statement you have one and you also authenticate a user before they can play (IE username and password required to play) then once they login you have PHP generate a key/token that is required for every request from that user for this session and send it back to C2 in the Ajax response after they login.

Your user table can store this token after they login.

Example Table Columns:

name: jhondoe

token: abc123 (generate this randomly..doesn't matter what it is... but it changes every time they login)

C2 recieves the "abc123" token and sends it back with every request.

You future C2 ajax requests would look like this

savescore.php?name=jhondoe&score=999&token=abc123

When PHP get this request it first validates the token belongs to the user by looking up in the table. If it matches then you at least know this request came from the user you expected it to and their session is valid. Every Ajax request they send from that point on needs to have their user name and that token to be a valid request for that user. Else the requests are just ignored. All requests are now tied to the user and this solves one problem where a user can't hack any body else's properties (unless they somehow figure-out someone else's password).

Now to prevent them from hacking there own account PHP needs to validate the request came from the correct C2 session. This way you know the request came from C2 and not another browser window (IE Hacking). There are many ways to do this and NONE of them are full proof but they will make it much more complicated for a would be hacker to try and game the system (hopefully so much they give up trying). So same as for the user you need to generate a session token for the C2 client. how ever this one should be an integer since it will be used in an equation for validation.

Table Columns Example

name: jhondoe

token: abc123

c2_token : 111 (generate this randomly..doesn't matter what it is)

C2 receives the "111" token at login, stores it and uses it for the base in its encryption algorithm (this is a simple example so you can expand on making it more difficult if you want later by sending multiple tokens instead of just one).

So now what C2 needs to do is every time is sends an Ajax request it needs generate an encripted key using the token that will then be validated by PHP. To start you will need a dynamic variable. Game ticks is probably the easiest to use since they always change and are simple integers. Imagine if game ticks is currently 45354 at the moment you send the ajax request you take that number and do something with it evolving the "111" token it received. Like 111*45354/2*.2 = 503429.4 To be safe were going to assume a hacker will know in advance about "111" as they could see it being received back to C2 at login. So the real algorithm is what comes after in this case i kept it small (X*2/.2) is your encryption. Someone will have to go digging in your code to find it so the more complicated you make it the harder it will be for someone to find it or figure it out. If your javascript is minified (obfuscated) it should be almost impossible to find.

so now you Ajax request looks like this:

savescore.php?name=jhondoe&score=999&token=abc123&c2_ticks=45354&c2_token=503429.4

(in an ideal environment for unbreakable encryption both PHP and C2 would know ticks at the same time and you wouldn't have to send it but this is impossible for us to so you have to send it along with the c2_token)

PHP will reverse the equation using the 2 known variables (ticks/token) and the predefined algorithm to solve for 503429.4/45354*2/.2 = 111 If this checks out then PHP knows the request came from C2 for this user. No this is not a very good encryption method but it will stop 99% of amateurs and once you see the basics of how it works you can expand on it to make it a complicated as you want. The trick is just to get PHP to know the request came from the right user and came from the right C2 session. Good Luck

If your running your capx in preview mode and not from the same the server the AJAX file is loaded on then your server will by default ignore the ajax request. Its a security function of php to prevent outside connections from accessing any data you don't want them to. On your AJAX file you need to add a header call to allow access from out side connections.

<?php header('Access-Control-Allow-Origin: *'); ?>[/code:1gxtpvwe]

How ever you need to do more reading on this subject as this line above will open up your server to to all outside requests. Its dangerous to leave it in place as is but for testing this should fix your problem