Closed raichu closed 9 years ago
Azaezel
commented
9 years ago For myself, it would be a conflict of interest to push hard on any particular alternative given that I'm unlikely to make use of one until the current game is complete, so simply as data points:
Python: http://www.garagegames.com/community/resources/view/21370 C#: http://omniengine.net/
crabmusket
commented
9 years ago Relevant opinion and news. Also this issue and this request.
raichu
commented
9 years ago @Azaezel This is more about reaching out more people; indeed, it may not be too much for people who have invested into TorqueScript already in their project.
What you point out are some independent/community efforts. As I mentioned in my post, for this to take on, it should be official and ship with Torque3D. Not but least, the Python-related link is not a proper language alternative (it's essentially SWIG bindings, for certain API, and you still need TorqueScript) and C#-related project is not Mono, it uses the non-free, Windows-specific MS C# and needless to say, it is exactly the opposite direction of where Torque3D heading (that is, trying to become more cross-platform).
crabmusket
commented
9 years ago Oh, and if you're interested in Python, I'm idly working on a nice wrapper on top of the already-mentioned project. Here's a simple example. It still uses TS under the hood, but you don't actually have to write any yourself.
Though it's still more of a proof of concept than actually useful. I'm not sure I'd actually want to use it at all.
raichu
commented
9 years ago @eightyeight I'm personally not a Python fan (or any language where spaces can change the meaning program or introduce "invisible" bugs), but thanks! I'll look into it.
Does it have any chance of being shipped with Torque3D? Unless it ships with the official distribution, I'm afraid it will more likely remain as a niche project.
crabmusket
commented
9 years ago I've considered PRing the changes Frank made to provide a SWIG binding for the engine. That would allow you to theoretically start to write wrappers in any of the languages SWIG supports. The python interface could then be another module, and other languages could have their own modules.
However I'm not necessarily a fan of this approach, as the system currently stil relies on the console, and it's a case of embedding Torque in another language, rather than embedding another language in Torque.
(EDIT: once you ditch the curly braces you never go back ;). Though I am appreciating Scala's myriad of ways to avoid curlies in places where it makes sense.)
raichu
commented
9 years ago Indeed, like you mentioned, I think the proper way of doing this is: it should be a proper alternative to what TorqueScript is (and of course, it should be official and ship with vanilla Torque3D).
(EDIT: once you ditch the curly braces you never go back ;). Though I am appreciating Scala's myriad of ways to avoid curlies in places where it makes sense.)
I don't have a problem with braces; I use Lua or bash every once in a while. And don't get me wrong, I did 3 projects with Python in the past, I know what it is. The crazy problem with Python is, the semantics and correctness of a program depends on invisible characters. And this doesn't scale either with LOC or number of developers (you can check Google dev's opinions on this, they used to write a lot of Python in the past and bit by this many times). (All of this for the sake of omiting 2 charaters per scope! I prefer the safety braces [or begin/end or whatever] give me over the little convenience of not having them. In fact, I would never exchange safety to convenience.) But anyway, that's just me (like I also can't work with languages without static typing for moderately serious projects, so I've always used C# with Unity), and a bit off topic w.r.t. the issue.
crabmusket
commented
9 years ago It is a little off-topic but it's an interesting discussion to have. I must be an exception, because I've never actually had a whitespace issue in Python that didn't cause a parsing error :/. Also the characters may be invisible, but the effect they have on the text around them isn't.
I don't think I have anything else to say on the TorqueScript issue that hasn't been said elsewhere. I'll say again that Lua is my pick for an embedded language, and the idea of getting rid of TS is definitely on the radar, but it's going to be a long and painful road. Current plan for the SC is to wait until we (hopefully) integrate an ECS into the engine, which will bring about a refactoring of some core code and a dramatic reduction in lots of classes that depend on scripts. So once that's done we can talk a bit more seriously about dealing with TS, because there'll be less DefineEngineMethods to rewrite.
raichu
commented
9 years ago Especially given the recent boost LuaJIT gets these days, it's looking better and better. Having a language with static typing becomes more and more important for larger projects though, so Mono or something similar would be great to have.
Cool, I'll definitely visit back Torque3D time to time to check the status for future projects! Until then, I'll be sticking with Unity though.
crabmusket
commented
9 years ago Just had a chat with @LuisAntonRebollo last night about integrating LuaJIT... but yeah, sticking with Unity at the moment seems like a perfectly good choice. Best of luck with your projects!
raichu
commented
9 years ago It's exciting to hear. I'll stay tuned!
Thanks!
Winterleaf
commented
9 years ago @ raichu
Right now, Omni is about 75 percent mono compatible. I've been slowly using #Define's in the C# code to be able to switch between C# and mono. Like I said a lot of the binding is mono compatible. The only reason I haven't finished it is because I don't know Linux and I have no one to help me test it.
Vince
raichu
commented
9 years ago @Winterleaf
I would love to help testing and porting your 100% MIT licensed patches to Torque3D once you complete moving away from .NET to Mono, get rid of .NET C# and provide a cross-platform way of building the project (otherwise I won't be able to test it under Linux, right? both make and mono work under windows, so this is doable).
But before anything, my question is, what exactly are your plans with Omni? (Edit: it turned out that they don't have rosy plans, see below)
This issue is about bringing official X support (where X can be C# or Lua or something else) to MIT licensed Torque3D. Are you eventually planning on submitting a pull request to the main repo to get Mono (of course without anti-cross-platform/Windows-specific code as well as exe/msi/dll files and Visual Studio-only build system --as I mentioned above, this is the opposite of where Torque3D is headed) support merged? Or is Omni going to continue as a (Windows-oriented) fork?
I can't also help but note that OmniEngine.Net doesn't seem to be merging changes from Torque3D; it would appear that the projects are diverging. Also, commits in your repo so far are essentially license and doc changes, and the Torque3D git history is actually gone! (this would ordinally mean you have no intention of cooperating with the original Torque3D repo).
Edit: I just noticed you have your custom license, which refers to your fork as WinterLeaf Entertainment LLC OMNI "Community Edition", and it's quite a restrictive license:
Licensee may not: create any derivative works of OMNI Engine, including but not limited to translations, localizations, or game making software other than Games; redistribute, encumber, sell, rent, lease, sublicense, or otherwise transfer rights to OMNI "Community Edition"; or remove or alter any trademark, logo, copyright or other proprietary notices, legends, symbols or labels in OMNI Engine; or use the Software to develop or distribute any software that competes with the Software without WinterLeaf Entertainment's prior written consent; or use the Software for any illegal purpose.
All in all, so far you have presented a quite hostile attitude towards the FOSS spirit of Torque3D IMO (remember, Torque3D is a game engine, people want to build optinally-proprietary games with it. That is why it's MIT licensed.). You took Troque3D and rebranded it as Omni, added your license that only works for you, all thanks to MIT license. Good for you that GarageGames didn't make a restrictive license like you did, eh? Think about where you would be now otherwise.
I also don't like the language you use here, which is the only mention of Torque3D!:
Now, it has to be admitted that this originally based on the T3D engine.
The choice of words speaks volumes to me.
Please be honest, and speak the whole truth, don't act like a weasel or a scam artist. And if you are going to do business, be professional.
More of this can be found in their "Legal Mumbo Jumbo" page with 0 mentions to Torque3D:
The OMNI Engine (Source Code) is a variant of the BSD 4-clause license. The reason we decided on this was twofold. First, WinterLeaf Entertainment did not want other to be able to re-brand OMNI and sell it as their own engsine. Secondly, since the engine is free we wanted to make sure our name got out via the splash screens and such in games written with OMNI. (A “Supporter” license allows you to omit these.)
But you are re-branding Torque3D as if your own engine and selling it as your own engine! So you don't want other "geniouses" like yourself to appear? "Supporter” license. Nice spin. Just for $100 from OMNI Store! Quite a variant, indeed.
If the users come up with something that is a nice additive that’s more…. Situational specific…. That can be added to our resource page or put into the OMNI Store.
There are options here, and we are willing to work with you. If you wish to port the OMNI Framework to another language (Python, V8, Java, etc.) please contact us. We will consider any serious inquiry and decide at that time if we wish to open the source code for the Omni Toolkit.
Whoa. Right, don't even mention that Omni is Torque3D with C#, so that if someone else want to add another language to Torque3D, it should go to your $$$ OMNI Store $$$ where you get $$$%, not Torque3D. Nice. Way to pay your respects to Torque3D.
About your whole Omni business. Thanks, but no thanks. I would rather wait for Torque3D. Be it Mono or Lua or something else, it will be MIT licensed.
I really hope your project won't get any FOSS community support at all, because your fork has an hostile license and it would hurt Torque3D community if anything. And with such an attitude, I can't recommend you to expect people cooperating with/contributing to your "community-edition" project for free anyway.
In fact, given all your disrespect towards Torque3D developers and your weasel words and shady business tactics, I wish to see your project and company wither and die soon.
crabmusket
commented
9 years ago I feel these comments are quickly diverging from their original purpose. Any further discussion about OMNI can be taken up in private or in their own repository. Any discussion about scripting languages for T3D can be done on forums or IRC until we have actionable issues.
I do want to note that members of WLE are known as prolific contributors to the open-source Torque community. Your characterisation of them does seem unfair to me, but I'm leaving your comments as you're entitled to your opinion. WLE has contacted me asking to post their response, but I don't want to let the discussion continue.
Thank you and good day.
I think this deserves an issue.
Shipping a well-known, fully-fledged language with Torque3D, as an official and complete alternative to TorqueScript would hugely help for people starting out with Torque3D.
I do understand (and know) the sweet temptation of creating your own language and seeing it get used, but pushing it onto people who don't actually want to use your baby language is not good (current situation is "if you want Torque3D, you have no choice but to use TorqueScript", so in a way, this is forceful.).
I'm not going to discuss how TorqueScript is as a programming langauge (from what I have seen so far, I'm afraid I can't say it is a good language). It is a huge put off for several reasons:
I don't want to point to a particular language, there are various very popular (in gamedev world), well-known language with fast enough implementation and compatible license.
Possible such languages are
And maybe some others. There are some "niche" languages (such as squirrel) used by a few projects and some few people know about them (fewer actually know the language itself), but they're either not wide-spread/well-known or don't have a performant implementation with a compatible license.
Please consider this issue seriously. This has a very serious and direct effect on Torque3D's popularity.
A note about Mono and LGPL: Mono is licensed under and not GPL, which means even for closed-source projects, you only need to provide object files, not the source code, or just use dynamic linking; it is very well doable with PC/Linux/Mac/Android. And as of version 8 iOS, you can bundle dynamic libraries as well.
A similar situation happens when you try to ship programs using Qt (a library licensed under LGPL), and here is their official explanation on the issue: http://qt-project.org/wiki/Licensing-talk-about-mobile-platforms
(Note that this was written prior to iOS 8, whence dynlibs are allowed).
If for some reason one needs to link Mono statically nevertheless (are there such platforms? PSVita maybe?), then the developer can manually license it from Xamarin. Not that such platforms are supported by Torque3D as of today anyway.