Thanks again Fengist for the extra information.

I will try out what you said and see how I go.

One other question: Does the CORS exception work the same from a desktop version (nw.js) of a construct project? I know you mentioned that it was probably possible. I'm just asking for better clarification because my game will be a desktop game.

Well, I can't say for certain but I can tell you this:

When I run the editor as an app it uses the construct.net as it's website. Since I work mostly on HTML5 exports, I can't really answer that. Once thing you can do to experiment is to take the $http_origin = $_SERVER['HTTP_ORIGIN'] and save that to a file on the server every time the php script is run. That should tell you what the scripts see as the origin.

If this doesn't work then you're options are going to be a good bit more limited. You're going to have to work with websockets to exchange data. I've played around with one called Fleck which is written in C# and I have gotten C3 to exchange data with a Fleck server. There are a number of other websocket frameworks out there to play with. I've briefly looked into using the C3 multiplayer plugin to exchange data but it has one huge drawback, the server is just another client, and it has to be the first client in a 'room' for every other client to log into it.

But, websockets come with a whole new level of programming and security.

Hi,

I'm developing a full-fledged website to support my game. Including all kinds of views from login/registration, leaderboards, chat, etc. Basically, the game itself is just a component on a page.

I would prefer to integrate deeply the game into the overall webpage. By this I mean, to have the login and all the details listed before handled by a proper web framework and have Construct to run only the game (it's a board game, like chess). How would you integrate such a setup with a Construct3 game?

I'm working on a browser based game using Construct as the engine. Yea, I know that sounds strange but it's true. I've created full fledged php sites that do what you're looking to do, handle registrations, logins, email validation, session tracking, etc. I thought long and hard about this before making this decision but, here's what I chose and why:

The website will handle any forums, or discussions, things of this nature. Things that aren't linked to the game. The only thing specifically game-related it will handle is email verification (click the link in your e-mail). That page will be pure HTML.

Construct is going to handle the login and even the account creation. All of that is going to be handled by passing the events to a collection of php scripts via Ajax with JSON responses coming back to the client. By doing this, I'm first ensuring that any login attempt comes from the game itself (Ajax does this nicely with CORS.) I'm also guaranteeing that any account creation comes from the game itself. Unless someone seriously hacks the C3 code, this means I won't need captcha's to make sure they're human.

Plus, now that I've figured out this plugin:

construct.net/en/make-games/addons/190/html-element

I can use html elements to generate the login screen and still have sprites flying around, making for a much more enticing login.

And with this plugin:

construct.net/en/make-games/addons/166/inject-css

I can actually see how the stylesheet looks without having to upload the game to the server.

PLUS: I've used the html plugin above to load a nice html vertical menu into the client that passes clicks to the C3 engine. 1 element on the layout handling 8 buttons in an unordered list with CSS handling all the cool stuff like mouse-over events and colors. Creating that same menu in construct and trying to keep all the buttons where I wanted them would have taken hours and dozens of events.

So, while I could do my game the way you plan, I've looked at the advantages and disadvantages of both and I see no reason now not to put the HTML inside the client and reduce the server load to just handling php data manipulation.

And you just gave me a great idea thinking about your decision. Since I can now use real HTML5 inside the game, I can generate news and events in HTML and have those passed to the game as well and even have sprites flying around them if I choose.

I've always had issues with the viewport/screen width. The only way I've come up with that somewhat solves the issue for me is this:

Create a function in a an event sheet that you can add to other event sheets. Call it: "ResizeLayout"

In that function call a: System - set canvas size

Set the canvas size to:

Width: Browser.ExecJS("window.innerWidth")

Height:Browser.ExecJS("window.innerHeight")

In the same event sheet create an event: Browser - On resized

have it's event set to: function: Call "ResizeLayout"

In the System - start of layout

On all of my event sheets (the ones that have a layout) I also have it call that ResizeLayout function.

If you use a mouse click to select and cancel the full screen browser, run that function after you request or cancel the full screen.

I've used it with several full screen modes and it even works with the mode set to off.

Or at least it does for me.

Now, here's the downside to this. When your layout loads or when the screen gets resized your objects on the layout may not place correctly. I solve this by manually setting the position of every on-screen object after that function is called in the On start of layout.

Here's an example of placing an element at the screen center:

x = viewportleft(0)+(viewportwidth(0)/2)-(element.width/2)

y = viewporttop(0)+(viewportheight(0)/2)-(element.height/2)

That's assuming the element anchor is in the top left.

This may not be the 'proper' way and it may or may not work for your game. Most of my objects are static but... hope this at least gives you some ideas.

As this is very complicated for me, I am willing to speak on a different platform like Discord to make it easier if you have the time?

That chunk of code that I posted is set up to recognize 2 servers. Either your website or the the C3 app/web editor. Put that code in front of any php file you plan to use.

While I do upload my game periodically to test it, mostly I'm running from the C3 editor. That allows the ajax to access the php files on my web server.

You'll note that it's only set up to accept Ajax posts:

header('Access-Control-Allow-Methods: "POST"');

If you want to use the Ajax get, you'll need to add it: , GET

There are other things the Ajax plugin can do but I don't use them. They may use other methods. You can find a list here: developer.mozilla.org/en-US/docs/Web/HTTP/Methods

As for discord, I do have it but I rarely get on. Sorry, but annoys the utter crap out of me with all the bloops, dings and other pointless noises.

If you already know a bit about JS then PHP will come pretty easy. Just get netbeans ide which has great code completion and google anything you don't understand. There's gobs of references, examples and resources for php.

I also looked at your other thread about sending an email. One thing you really need to add in to your events is an Ajax on "tag" error. That event will only tell you if an error occurred but it won't tell you what the error is. There, you need to look in the error list in the browser console.

Edit: WackyToaster - The email guide I linked explains to export to html5 project. Is this required? Can't I just export it to nw.js and then request the URL for the c2mail.php file?

I seriously doubt that the email tutorial you posted is going to work. The main reason why is a lack of CORS headers. You have to tell the PHP script who is allowed to make the Ajax requests.

header('Access-Control-Allow-Methods: "POST"'); $http_origin = $_SERVER['HTTP_ORIGIN']; if ($http_origin == "https://preview.construct.net" || $http_origin == "https://www.myserver.com") { header("Access-Control-Allow-Origin: $http_origin"); }

In that example, the PHP gets the URL of the server making the requests. It then looks to see if it's one of the two that are allowed. If so, it then sends a header back saying, 'yes, you're allowed to talk to me' and the script runs.

Without that header you're likely to get an Ajax error and the only way to really know what the error is is to look in the browser's console.

Now, you can still probably do this with nw.js. But, that php file will have to be on your server and you'll have to replace myserver.com with your server's url.

While Construct is (for the most part) a codeless environment, that doesn't preclude knowing some code. If you're going to want to change the way Construct works and acts, you'll need to know javascript. If you're wanting to interact with a server (like storing and retrieving user names, passwords, emails in a database and such) you'll be using Ajax requests. For that, PHP is probably the easiest language to learn and is reasonably fast. If you're going to need to interact with a server and you want speed, learning a higher level language like C# and playing with websockets is the way to go.

For what you're wanting to do, PHP is going to be easiest way and here's why.

When Ajax works with a server, it uses something called CORS - Cross Origin Resource Sharing.

Basically, this means you can limit where all of the requests are coming from. If the request isn't on a list of allowed servers, an error is shot back. I seriously doubt if Git will allow Ajax requests directly from the C3 client.

My approach to this would be to have C3 call a PHP script on my server. Then, have the PHP script use the Git API, interact with it to do whatever I needed and then, send a response back to the C3 client.

Just my 2 cents.

Ok, this is a bit complicated but here goes.

I have two layouts with event sheets, Login and Create Account. Attached to both of these is just an event sheet, Ajax Handler. If I try to change an element on either layout from Ajax handler, it has no problem. I can make text invisible or change it's colors, etc. HOWEVER, if, in the Ajax Handler I tell it to go to either of those layouts, the Ajax Handler is no longer able to affect the layout it switches to.

For example:

If I'm in the Create Account layout and in the Ajax Handler I tell it to play a fade on a Create Account layout, it works.

If I'm in the Login layout and tell the Ajax Handler to play a fade on a Login layout text, that works.

If I'm in the Create Account layout, tell it to switch to the Login layout and play a fade on the Login layout, it doesn't work.

Ok, so your ability to write tutorials and document things is pretty much right on par with any developer, including myself.

However, once I figured it out... Wow dood! Just Wow.

You should always check the browser console first. In this case it logs a warning telling you that requests from a HTTPS to HTTP page are blocked for security reasons (mixed content warning). That would have saved you all the trouble sifting through logs and all.

You should absolutely run your server on HTTPS. Many web platform features no longer work on HTTP, so you may also find some features stop working when you publish your project to an insecure server.

Yep, just realized that was the problem the whole time. Guess it's time to visit Let's Encrypt huh?

Thanks.