Oh, this is good to know. I will have to do some research on that. I just include it in the published index.html, and I used an if statement with AJAX calls to get the same info in preview mode.

Thanks Ashley

Much love for StackOverflow. You definitely need to make use of that site.

As for your specific question, you are going to have to modify the index.html file that Construct generates to integrate your js file into the overall page load. Otherwise, it doesn't know where you are asking it to go. By extension, this also means that calling js functions with the Browser object will NOT work in preview mode, since Construct knows nothing about the extra js file or the include that you have included manually in the published version.

We have the same problem. I had to use "CanvasToLayerX/Y" to adjust the static UI pieces to fit the screen. Like this:

[attachment=0:10zbthc5][/attachment:10zbthc5]

You could just have new content as a separate project altogether than just link to it via HTTP.

Pythagorean theorem anyone? a^2 + b^2 = c^2

What do you mean by "connect"?

If I assume that you mean connect information, then via HTTP.

For instance: We made both our website and our game client in Construct, in two separate project files. The website and game client communicate with each other via HTTP GET requests (with a few HTTP GET AJAX request interactions).

You login to our integrated portal on the website, then it records your session and retrieves your player_id from the server. Then when you select a game server, the website passes all of the information that the game client needs to know on startup into the client code via HTML injection. The website passes information, including the player_id, current_timestamp, server_ip, application_name, etc. The game client then uses that information to talk to the correct server.

Yea, I am already neck deep in Rex's grid system. It is the closest thing I could find, and my patchwork solution stands upon his work.

After about a week or searching for a way to do a procedurally generated table, I am left to engineering my own patchwork solution. I cannot say how nice it would be to have an official table object to use.

Some of the basic properties that I would like to see:

* 2-dimensional orthogonal frame of reference

* Automatically resizing cells that adjust to the sprites/text within

* X/Y coordinates for cells

* Sprite or solid color backgrounds for each cell

* Subsidiary Z-layers within each cell (or perhaps just integrated with the overall layout z-layers?)

* Top-left 0,0 reference point (like text objects)

Some more intensive properties that might take more time to get working:

* Cell combination (to make non-square tables)

* Perhaps some dynamic coloring/etc. for borders

I am sure that there are a lot more useful tabular features that I am missing off of the top of my head, but just ask Google Docs and grab some of their feature sets.

You Construct devs have worked some nice magic in the JS realm thus far; so I don't imagine this would be too much of a stretch for you, just a matter of time and money.

Alright, I'll look into it.

Does it allow limited customization of the appearance of the output table?

Look into "Prepared Statements". They exist for various languages and exist to solve the problem of injection.

Okay, so not forcing it to destroy / re-render all of those objects fixed the hang between layouts. However, this created other problems...

The primary problem now is that objects that are procedurally generated "shift" in the position of all of the objects by a factor of around 8x to 10x in position in between layouts.

Thoughts on how to stop it from arbitrarily moving things while not on that layout?

I found a "Persist" behavior. Would that effect more permanency in my objects?