If you're gonna localize Construct to more languages, just make sure to research which languages you need to translate it to. It wouldn't be necessary in any scandinavian country for example, to us translations are hurting us, not helping. We do not need or want translations and the game industry knows this and just gives us pretty much all games in English.

Some insist to translate to Swedish. For reasons unknown, a lot of open source software devs does this and throw horrible translations at us. When we google stuff, Swedish wikipedia articles shows up on top which are often absolute crap. It's very strange in a country where everybody except very young kids and and a few pensioners can speak English.

I was going through the changelog for Construct and noticed 'Is visible' is now false if the object's layer is invisible.

To be honest, this disappointed me, because it's so obviously a bad choice, just like when it was decided that Construct (now classic) should be 1-based.

When I was designing a minimap in MMF2 which turned out to have the same issue, I worked a lot with visibility. Then when the minimap was complete, I added a feature to hide the layer because I didn't want the minimap to be visible all the time. Suddenly, when I display it, everything is messed up. My minimap system didn't work because I couldn't rely on the "is visible" condition. The fix was of course to store the "actual" visibility setting in a value.

According to this flawed logic (the type that makes MMF2 a pain often and makes me want to switch to e.g. Construct), it could as well return Off when the object is outside the window (hey, you can't see it, right?) or when it's simply covered by an other object on top of it.

Thing is, if "is visible" returns False just because the object is in an invisible layer, the whole feature is essentially rendered useless for invisible layers. Things will not work normally when you hide layers and then show them again. Why would you NOT want to have the ability to check an object's own visibility setting unless the layer can be seen? If I'd be interested in knowing if the layer is invisible, I'd check the layer setting itself.

Oh right, that's nice. I didn't consider that it might be portable (it's not that common unfortunately). I haven't actually tried much of C2.

I'm glad to hear about the runtimes.

Point taken, I suppose. I really didn't think people abused products like that.

I wasn't actually planning to modify the editor itself (other than perhaps making a portable build of it so I could run C2 from an USB drive since I tend to move between physical locations so much and don't always want to bring a computer). It just feels a bit more comfortable knowing it's available, given what have happened with tools I used in the past.

I guess I can live with a closed source IDE. As long as exporters are open, I'll definitely consider C2. If the .exe exporter turn out to be closed source, it'll be something else though.

s for the editor, the problem is I don't know how we could open source it and still sell it. never suggested to open source it, hence the comparison to Torque 2D (source included with buy). However, I didn't know that people changed the Construct 1 name, compiled the source and distributed it as their own software. I guess I can understand your choice in that case. Are you sure illegal stolen products get big enough to attract users who would otherwise have purchased the real product though?

think some people expect too much. Worlds gone mad :/'m an MMF2 user and MMF2 have taught me the hard way to never lock my games into a locked dev tool again. I also need better and more powerful tool. Now I'm trying to take every factor into account, and make a choice between Torque 2D (source included when purchased), pygame (open source), monkey (closed source but exports the games as actual c++ code) and Construct 2. I'm not mad for trying to pick the tool that fits me best.

When you purchase Torque 2D, you get a full copy of the source as well. I know a company that uses a modified version of Torque 2D where they added and changed the things they needed. In my case I'm pretty much doomed when something is wrong, and I need to ask someone in the development team to fix or change it.

I'm definitely going to make a switch to something else as soon as my current project is over (it'll take some time so Construct 2 will probably be more ready to be used for game development by then). I've learnt the hard way that not locking my games into a platform I can not modify must be very high on the priority list.

I'm not saying it should be open source of course. Just that it'd be great if registered users gets the source and can modify it for their own needs.

Shouldn't the website be about Ogg Theora vs H.264 too? You'll have the same problem with video as with sound if they don't go for Theora.

Actually, I got to point out that I was aware the things I mention are zero based even in construct because they have to be. What I meant is that since all those things are zero based, it's very inconvenient if other things you might want to link those things together with are 1-based, such as array indexes, tokenized string indexes, object indexes, animation frames, loops, and so on. There's bound to be a lot of -1 and +1 adjustments involved. In MMF2, I heavily rely on arrays and loops, so I think the same is bound to happen with Construct.

Again though, if Construct proves to be good enough in other aspects (and I got to say I'm impressed by many things in it), I can definitely live with that, and the fact that a range can be specified when looping to begin at zero, I'm realizing it's a much smaller problem than I first thought.

Well, I've just tested it for a few minutes, but the event editor seems packed with stuff I've always felt I've needed, it probably more than compensates for that thing, so I guess an apoligy from me is in order. But anyway, I better not bring this topic further into the swamp of off-topicness.

Err, sorry to disappoint, people who know me also know I tend to get upset randomly like this. Thing is, the process of creating my games is a lot about fighting the quirks of MMF2 and the lack of many essential programming options that Construct seems to do a whole lot better. Still, design decisions like tend to cast a dark shadow over how I percieve the product. If a flaw like this was decided early on, my brain tells me there's got to be more. Besides, I'm not checking these forums often, I don't know enough about the product to have insight in if it would have to be done from the start or can be implemented now. All I know is that I'm kind of growing out of MMF2 and although I'm hoping for MMF3 to come and save the day, I'm open for switching to another tool that doesn't get in the way, and doesn't force me to deal with quirks and workarounds all the time. I simply don't want to fight my development tools. I don't expect all products to be made for me, but I guess I overreact when fundamental design rules with one obvious best solution isn't done "right".

I suppose you're right though, perhaps Construct is actually so good that something like this can be ignored, and that I'm just being very unhelpful complaining about things that are already well established. I probably should have tested the program instead of going instant-critic. I added some comment at the top of my website source so you can ensure it's the real nifflas you should be disappointed at. Well, this way you get to know the dark and horrible truth about my personality and tendency to overreact from the start, as many have experienced before you.

Anyway, installed. I'll keep my mounth shut until I've actually tested Construct, and try to be nicer when I open it again.

I'd say 0-based. I'm not even testing Construct before either all mathematics and computer software are made 1-based, or Construct is adjusted to how reality actually work.

4 mod 4 is 0, not 1. Sin, cos and tan centers around zero. A variable defaults to zero (don't tell me variables are also 1 by default in Construct). The value that is returned in place of "aaw, that's unset" is also zero, unless a NULL value is supported. The range of an unsigned byte is 0-255, not 1-256. The top-left position of a screen and object is 0,0, not 1,1. You move an object 0 pixels to not move it anywhere. In every situation when negative numbers are used, it's a pain to have 1 in the middle. I'm just going to be too annoyed over dealing with this that I'd rather stick to what I use now where things are randomly 0 and 1 based (because at least some features are 0-based).