Ok, so I noticed if I pull the Browser.URL while using NW.js it is using a chrome extension to act as the server and node.js server. The issue I've run into is that it seems is uses a random string. For example below are two "URLs" from two different projects I've built:

chrome-extension://akpjmbmhnbdcbojfbgjfipojpkjbnccc/index.html

chrome-extension://lojkaogdfgldklcmkcjijhonemjbldbk/index.html

My question is: That random string is important to the authorization chain I'm using with my Twitch integrated games... Is this string specific to each project, or will it change due to changing something in the project. I know it hasn't changed when I've changed the version, but it did change if I changed the name of the project. Does anyone know if it changes based off any other factors?

The reason I ask, I have to set a return URL in the Twitch APP settings for my app to call, and it has to match 100% or else authentication fails. There's the double issue of the fact that the URL needs to start the game again. I need to make sure this doesn't change so I can set the return URL on the Twitch side and not worry that the whole thing will break when I compile and ship new versions.

tumira Out of curiosity (and out of hope that you can answer quicker than I can grep and figure it out on my own) what did you do to stop the shakiness of the iFrame, and do you think it would fix the seeming similiar issue with the div plugin? If so, I don't mind manually changing my runtime if you would kindly let me know how you solved the issue.

Well, the easiest way I could find was to edit the AJAX object itself to force use credentials on. When I have time to put the work into it, I'll clone the AJAX object and add an edittime toggle for it, but in the mean time this works.

Mulling if I should make this an actual feature request, or if I'm the only one who will even likely use this.

send with credentials, or am I going to have to write a custom Ajax plugin? When sending a request via Ajax, the current browser's cookies do not get sent which is important for an interface I'm currently writing.

Gonna have to go with the crowd on multiple event sheets. Also, use groups and disable pieces of code that are not needed at the moment to get the best performance out of your creation.

Pitty. Was hoping either someone would know or a developer would comment. I am going to rewrite the whole thing anyway, but this is something that I would like to have the working knowledge to fill in gaps.

What exactly determines the order when using For Each Key with a dictionary object? It's not chronological or key based as far as I can tell.

Currently using a dictionary to store the chat text coming from the server in my MMO with the server's chat message ID as the key to prevent accidentally duplicating lines in the chat display.

I had thought that it was either chronological or based off the key since the chat dictionary starts with a "system" message with index 0, and all the messages that the server sends come through with non-zero indexes. When I populate my text object with the information returned from the For Each Key event, they are in the exact order the server sent them, with the system message at the top. So far, so good.

For record keeping and to cut down on information passed from the server to the client the client stores the last message ID it received, and uses that to prompt the server to check for any messages that have a higher ID so that only fresh messages are sent on a chat update.

I have recently added a system alert type message when the server recognizes I've uploaded a new version of the client. When the condition is right, it increments the LastChatID by .01 (giving a potential 100 messages without risk of duplicating the next ChatID's key), then inserts a new chat message using the same method I use to insert the first system message and the new incoming chat messages.

At first glance, it works exactly as planned...the system message shows up at the bottom of the scrolling chat when it's received. However, the next time it grabs fresh chat messages, instead of the System message being between what was the previous last chat message and the new chat messages, it is instead pushed to the bottom of the text object. This means that even though it chronologically was not the last added to the dictionary nor is it's key the highest number (or string...tried both ways. And the string "100.001" evaluates to more than "100" and less than "101" in javascript and C2...I even verified this.) that system message still is the last key returned during the for each key loop.

I'm stumped as to exactly how the order is determined. It's not a major issue at the moment, since the system message can only be generated once when I upload a new client, but I have plans for more system messages to be injected as things need to be brought to the player's attention. Fairly soon, they will have a full screen of nothing but system messages and have to keep scrolling up to see the chat or refresh their browser.

I'm loath to use a full array for this, since it's overkill for the minimal information I store and would take a considerable rewrite of the chat handling routine.

Terrafirmacraft (http://www.terrafirmacraft.com) is a total conversion mod for the wildly popular game Minecraft (http://www.minecraft.net - although if you haven't heard of this, do you even play games, bro?)

One of the aspects of the game is mixing various ores to create stronger alloys. Later in the game, you get a crucible that allows you to see the percentages of ore/metal that you currently have so you can see if you need to add more of a specific metal to create what you're looking for.

Before you get to the crucible stage, however, you have to put ores blindly into a vessel and throw it in a pit kiln and hope your math is accurate. That's where my Terrafirmacraft Alloy Calculator comes in to save new players and those who are bad at math.

The interface is similar to the UI seen in game, so it's instantly familiar to players, and it allows you to mix and match ore in a vessel and see what their outcome will be.

http://infinitepossibilitygames.com/TFCAlloyCalc/

C-7 it will depend on two factors: Scale and Scaling of the game. If his overall scale is relatively small, say a couple dozen npcs with a couple dozen quests then the effect of keeping the code server side would be minimal. If that game never expanded beyond that point then there's a very good case for putting all the code and data for the quests client side.

However, if he has several hundred npcs and several hundred quests then it's probably better to put that info server side which is way more efficient at doing this job plus the lack of a need to send every thing to the client.

And, if he plans on constantly adding new content, then server side is a better option...you simply add new entries to the database rather than compiling and pushing a new client every time you add a new dialog tree/quest.

onion That's exactly what I'm using C2 for with our MMO UWE. Our past two versions have used plain HTML and XHTML/AJAX as a frontend to our user while the php code handles all the match and training data for the wrestlers. C2 is just a massive leap forward as it allows us to make the user experience up to the level of a download game rather than limited to a browser experience while all the grunt work of the game is done server side.

We do unattended training, so it's only logical for us to keep processes server side. I can see a MMO where most of the logic can be in the client, but again the problem you run into there is security. It's a lot easier to hack the game (which is a major issue for multiplayer games) if the game logic is on the client side.

The other possibility I'd use, onion: since you're using MySQL on the back end...when a PC talks to an NPC, you send a query back to your php with the NPC's id. Your php can look up a table with the players' id and the NPC's id to figure out if/when your've talked to them and what step a quest might be on (could hold the quest in another table...you can make as many db queries as you need). It could figure out what the NPC should say and return a the text along with a list of options the player can choose.

Present those to your player and send his response back as another query. Repeat until the conversation is done.

Obviously it would require more knowledge of php/MySQL than C2, but it would have the advantages of:

1) Being more secure. While most people won't monkey with your client code, someone's going to play with it at some point.

2) Keeping your client size smaller. Storing massive amounts of data on potential NPC conversations plus the logic to handle them on the client side will require the client to have to download all that data/logic, where as the server only has to send just the specific responses needed at the time.

3) Possibly more efficient. Most servers can run php logic scripts and db queries way faster than a client's machine can, and MySQL is optimized for this kind of work while the C2 array hasn't quite been around as long. (Not knocking Ashley and the gang, though...it's just that THIS is what MySQL was made for)

Both methods would work, however, so go with what works for you.

Let me know if you run into any issues. I'd be happy to lend help as I can.

Edit the Fly sprite and use the "Rotate 90 degrees clockwise" button at the top (hold shift to make it apply to the whole animation).

C2 considers the "right side" of a sprite to be the front and your fly is pointing upward.