Well yeah, you never used the debugger because it doesn't exist.

The creation of one, which would include many things such as variable inspection during the runtime, could also offer the possibility to display collision polygons (or even other nice stuff such as displaying movement vectors, revealing invisible objects and editing objects' variables).

But I also agree that an option to display collision polygons in the editor be nice.

This looks like a subfeature of the "debugger". It was an option in the poll a while ago.

It could be done, but it would help reverse-engineers because then C2 has to include a full list of all object names. Currently it obfuscates all object names to make it harder to understand the exported project. So are you sure you want it when it makes reverse-engineer's lives easier?

hashmap the names, make the compiler ensure all existing names produce unique hashes.

you can use a fast one-way hashing that's not cryptographically safe (you could even use one of those ultra-fast XOR hashes, since the compiler will be doing the collision checking)

Wow, if it's running things twice, it's definitely a bug! Otherwise, what's the point? We'd just copy the events and switch around the conditions!

Wouldn't scraping reviews be a better approach?

"Jesus Christ", can you please do your research before you post something like this?

The only sources I could find of the incident are christian propaganda sites. There is no reputable news source noticing the event, the article jumps to conclusions (shiny clothes, wounded hands, helps people = must be Jesus), doesn't cite sources and asks you to "share"

Even snopes disproves it (hey, you're the one who told me to "google it" - it was on the first page).

• What were the girl's names?
• What's the muslin man's name?
• Who found the kids?
• What's "egyptian national tv"'s name?
• Which muslim woman news anchor?
• Why can't a child make up a story like this?
• When will the man be executed?
• Hell, when did this news come out?

Come on, this is widely known netiquette, it doesn't even need to be stated as a forum rule. Also, the bigoted and biased nature of the article, which portrays muslims as barbaric people and Jesus Christ as the supreme savior does no one a favor.

This is grounds for post deletion (or even worse, in some forums). The only reason I am responding instead of reporting is because I am not certain it constitutes "hateful rhetoric", since the bigotry is somewhat veiled.

Quoting Hoax Slayer, "In a world troubled by faith-based violence and misunderstanding, false stories such as this can only add to existing divisions and circulating them will serve no good purpose."

Unless you're talking about hiring, I can't make any sense of the "USA only" policy either. A lot of people in this forum either are from other countries or work with people from other countries.

If you intend to limit your market to the US alone, excluding everyone else (artists, designers, testers, localization people, marketers), you'll likely find very few people for your venture, even if you do find enough programmers.

I am certain you have valid reasons (I can think of a couple), but I'd like to know what they are so that we're better prepared for future opportunities.

Edit: Also, you're aware that spambots lurk these forums harvesting e-mails, right?

Hmm, having thought on this some more I think I'm persuaded by the "keep it simple" argument.

Initially I'll release it as a logic-only "last event did not run". We'll see how things pan out there.

Yes, but it won't be a simple condition, right? That way lies madness.

> ... Besides, online multiplayer for HTML5 isn't even a thing that exists...

BrowserQuest

I misspoke. I meant realtime multiplayer. You can see there is a HUGE delay even in the promo video, and you may notice the game is quite short. Even that Rawkets game, which was kind of realtime, is never online anymore. Websockets are not viable for multiplayer, IMO.

Are the performance benefits negated by the "compiling to javascript" part?

The greatest problem with ECMA Harmony is one that has plagued (and will continue to plague) the computer world for generations, and that is Backwards Compatibility. I see dart as way to do away with the old.

That said, the greatest challenge would be to ensure it gets picked up fast, and it won't be done through developer adoption, but through cooperation with other vendors, and I don't see mozilla and microsoft rushing to adopt Dart, even if it's blazing fast and has a writeMyProgramForMe() function.

The review linked above does point out some very interesting points, especially about trying to fork the web community being unhealthy, though I agree with google's assessment that javascript has fundamental flaws that are unlikely to ever be fixed (especially if the ECMA team decides to keep backward compatibility, as seems to be the current mindset).

I mean, learning dart now would put one in a VERY advantageous position if it were ever to gain momentum, but if no one but chrome adopts it, it will remain forever a javascript translator, akin to coffeescript, which would just be sad, so I'd appreciate if someone could point me to a discussion on those topics (as I'm sure someone thought about this already).

Well yes, it makes no sense to change to dart at this point, especially if other browsers decide against it.

Do you think this language has any future? If it remains a "chrome only" thing, it will obviously die a la "activeX" or vbscript.

As far as my test goes, "inverted for" makes the application crash (firebug error,grey screen in browser) and "inverted every tick" just doesn't execute (logicaly).

Sounds like a bug - both events need the "not invertible" flag. Will we have a "not elseable" flag? <img src="smileys/smiley36.gif" border="0" align="middle" />

Personally, I'd prefer if else were not a condition per se, but a special case - a condition "mode" if you will, similar to how inverting is not a "invert this condition" condition or how a sub-event is not a "treat this as a sub event" condition. Because else acts on the previous condition, it follows that it should be special, not a simple condition (because it is not contained to its line).

IMHO, treating it as an ordinary condition is a mistake, hence the confusion. Set some time aside to think of an appropriate interface for it - we also need one for OR. Remember that this decision will "stick", and it won't be easy to go back and change it.