Construct Translations

What kind of software do you recommend to make it possible to correctly translate Construct in other languages? Or make the translations available as an optional download...

Construct is not fully translatable, so I would wait until better translation support is implemented.

Construct is not fully translatable, so I would wait until better translation support is implemented.

While support may be limited, if the source is open why is it that translation is not fully possible?

Because we haven't written full support for translations yet and there's no UI to change language - as soon as someone fixes that in the source code, translations will be more useful.

I'd like to see an export to different variations of C, including C# for XNA. MMF doesn't have either yet as well, but the one that does that first will get my exclusive attention in the future.

Construct doesn't export source code.

It exports executables.

What advantage does exporting source code rather than built EXEs have? What does that have to do with this thread?

What advantage does exporting source code rather than built EXEs have? What does that have to do with this thread?

Well it depends on what language the source exported in. If it went to a C or C++ or even C# it could be useful to build a base game using construct and the rest or expand on it in one of the languages mentioned.

Onto what that has to do with this thread? Nothing.

What advantage does exporting source code rather than built EXEs have? What does that have to do with this thread?

I see what he's after doing.

He wants a very simple method where all the hard bits are done (behaviors) of creating a complex game (requested in another thread) using minimal effort and to use construct to do it, then to "export" the result as l33t source code, with translated versions for the win, to "import" *chuckles* into XNA or something (he mentions XNA a lot) make some more changes, then "export" the source code back out, and call it his own, then to sell on the internets for profit.

And then Uwe Boll will make a movie of it, but completely different.

I don't actually know, but it's entertaining none the less!

"export" the source code back out

What do you mean by importing source code to XNA then exporting it out again? That doesn't make any sense. Source code is source code.

As for exporting to source code, I really don't see the point. You would never be able to modify the source code to make changes. The insides of the event engine are very complex, and because there are no languages that support event style picking as language features, the generated sourcecode would not be human readable, it'd just be a massive mess, like a really complicated function copied and pasted a thousand times. And what kind of changes would you make? What would the advantages be? There are no advantages to exporting source code. Only disadvantages.

> "export" the source code back out

>

What do you mean by importing source code to XNA then exporting it out again? That doesn't make any sense. Source code is source code.

As for exporting to source code, I really don't see the point. You would never be able to modify the source code to make changes. The insides of the event engine are very complex, and because there are no languages that support event style picking as language features, the generated sourcecode would not be human readable, it'd just be a massive mess, like a really complicated function copied and pasted a thousand times. And what kind of changes would you make? What would the advantages be? There are no advantages to exporting source code. Only disadvantages.

I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.

> "export" the source code back out

>

What do you mean by importing source code to XNA then exporting it out again? That doesn't make any sense. Source code is source code.

I know, hence the quotations and the chuckles

[quote:2wgolwcx]As for exporting to source code, I really don't see the point. You would never be able to modify the source code to make changes. The insides of the event engine are very complex, and because there are no languages that support event style picking as language features, the generated sourcecode would not be human readable, it'd just be a massive mess, like a really complicated function copied and pasted a thousand times. And what kind of changes would you make? What would the advantages be? There are no advantages to exporting source code. Only disadvantages.

I think that's what he's wanting to do with it, yes. There's no other reason I can think of to have the source code (really what would be the point anyway, you can edit your own game in construct, and compile it and have the exe too, I wouldn't see the point in the source code for it as well). So yeah, that's what I think he wants to do. Create something inside construct, then rather than create an executable, he wants to create the source code itself (that when compiled would become the executable) so he can take it over to another program, like you would a jpeg or a text file. You know that can't be done (not in this case anyway), and I know that can't be done.

I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.

So what are these advantages? From what I can gather from your post, you state code is better than events even when not human readable. Why is that? Isn't it better to write custom code in plugins which Construct already supports? I'm not saying events are always superior to code - they're not - but the options are put your code in a plugin, or ponder what to do with tens of thousands of lines of unreadable code. This isn't about code vs. events, it's about Construct generating tonnes of useless source vs. giving you the finished thing. That's not a feature, it's a waste of time to develop, from my point of view!

Don't think this is a personal attack or anything, it's just that this idea about Construct generating source code comes up from time to time. I can't really see any point to it at all, so I'm trying to establish what people think it will enable. Such as:

he wants to create the source code itself ... so he can take it over to another program, like you would a jpeg or a text file.

Remember this is a big ball of mud code which doesn't make sense. What are you actually going to then do in another program with this unintuitive source code? I'm yet to hear any convincing real-world scenarios yet.

> I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

>

> I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

>

> I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.

>

So what are these advantages? From what I can gather from your post, you state code is better than events even when not human readable. Why is that? Isn't it better to write custom code in plugins which Construct already supports? I'm not saying events are always superior to code - they're not - but the options are put your code in a plugin, or ponder what to do with tens of thousands of lines of unreadable code. This isn't about code vs. events, it's about Construct generating tonnes of useless source vs. giving you the finished thing. That's not a feature, it's a waste of time to develop, from my point of view!

Don't think this is a personal attack or anything, it's just that this idea about Construct generating source code comes up from time to time. I can't really see any point to it at all, so I'm trying to establish what people think it will enable. Such as:

> he wants to create the source code itself ... so he can take it over to another program, like you would a jpeg or a text file.

>

Remember this is a big ball of mud code which doesn't make sense. What are you actually going to then do in another program with this unintuitive source code? I'm yet to hear any convincing real-world scenarios yet.

I never said unreadable code would be better, or even needed. I simply said the advantage is having access to that in case something comes up that cannot be fixed or added with events because of the scope needed, which in itself probably will not ever happen but the possibility is always there. I would never use it if it was added for several reasons I am just saying because it is unreadable and a mess does not make exporting source code as you put it "only disadvantages" as that is one single disadvantage among its so many, possibly useless uses. Those uses can still have advantages in extremely rare cases to some people. Not sure why but that cannot be dismissed.

At college I've been around this group that works on "Model Driven" programming. I did cite Construct as an example to them.

"Model Driven" is when you use design software to.... well, design your software. I've always been the coding type, and never liked this approach, but I took a serious look at it in this workgroup.

What I found out is that Model Driven development only works when the model IS the software. That is, there's no in-between model (such as exported code, in this case).

WHY?

Well, if you export the code and then change something there, the modified code no longer conforms to the original model. Things are lost in translation. Semantics are lost when generating the code, code doesn't contain semantics so you can't have them when creating a model from code.

This happens always, everywhere! just try translating text from english to russian and back to english. Things are jumbled, meanings are lost. (Just in case: think of english and russian as two models for expressing human thought).

So I said, and this is my current official stance, Model Driven is only a good idea if there is no way to do these in-between changes. The model becomes the code.

This is my opinion, based on my own experience with tools like Bison, Flex, Antlrv3, Doxygen, PHPDoc, MySql Workbench, Power Designer, etc.