New version of Mono with Unity 4.3 - Any additional details on that?

Did anyone look at the release notes for Unity 4.2?

* Native Client: Mono is now built from our own sources and is no longer subject to the LGPL.

Does that mean the native client (and only the native client) could support the latest mono?

 

No, it means they've branched their own version of Mono from an earlier incarnation (pre LGPL). In terms of this argument I'd say it also means that there is no chance of an update to a newer version of Mono, only of incremental changes that UT decide to make to their own branch as including newer Mono code from the main branch would require them to come under the LGPL.

i.e. if you want new Mono features UT would have to actually code them themselves, reinventing the wheel.

Obviously UT are stuck between a rock and a hard place on this. Being dependent on third party libraries does place you at the mercy of external forces that may not always be sympathetic to your plight. On the one hand the license has changed so that it's not a viable option to update or use any newer code, on the other they're dependent on Mono for Unity at this point and they have a userbase growing antsy about getting an updated version. UT must feel this is the only way forward, and they must feel confident that their version of Mono is sufficient to work with and that they have the technical know how to continue to improve upon it in house as otherwise I don't see why they'd add that in the release notes.

At this point the UT version of Mono could go in any direction, it might completely divert from the main branch and get more tailored for the job in hand and eventually end up more like another BOO, a very custom and distinct set of languages, or they might try to implement all of the newer .NET features to bring it up to date. But either way that makes it sounds like they're going it alone on this.

 

Wish M$ would port the VS to osX to publish to iOS/osX. It might be easier in the long run than porting Office to the Mac every 2 years.

 

Oh no, for this reason alone you should abandon mono for good! </sarcasm>

But seriously, are we ever gonna receive new mono/support for latest .net features/libs? Would be nice for someone from ut to resoond to this as this IS a serious issue.

One would think that unity with the advertised gazillion users should make enough money to fork license deal with xamarin for a new mono. Don't be greedy!

 

I think jonas means that *everyone* would be required to comply with the license. This is not an ideal situation. Furthermore for any of the larger clients that might be paying UT to have access to some of the Unity source code, it could potentially put undue burden on them. That's what I read.

 

Thus, as we find out, it is not a question of just the money.

Its the additional pesky conditions that stand in the way of the deal. Given what we know now, I don't fault Unity for saying "Thanks, but no thanks" to the folks at Xamarin for now.

 

I feel like some people don’t understand how the LGPL works. It’s a semi-infectious copy left license and it’s free!

If you don’t want to be bound by the LGPL then Xamarin's will sell you for $$$ a custom commercial license.

 

Anyone reading this thread is likely experiencing the same epiphany I had a while ago. That its futile crusading for a Mono update to solve gc issues, better to direct that effort towards encouraging Unity in implementing gc per-frame capping and removing allocations from the scripting API, and looking at whether we really need all the post-.NET 2.0 improvements we desire.

Sure, Unity risks becoming antiquated long term by not adopting the latest .NET features, and that's a risk UT have to face as a company. But as developers, while it would be nice to have all those productivity benefits that come with newer .NET features, do we really need said features to achieve our goals?

I'm personally comfortable with the .NET coverage we have, and support effort directed towards performance and visual improvements ( since rendering is over half of our per frame time ) as well as iterating on core features that need overhauling. How do others feel about the current .NET set of features? Are you significantly hindered? If so, how?

 

Do you really even need unity to achieve your goals seems like a silly question.:roll:

1: I needed a newer version of .net then 2.0 for Math.NET Numerics. I needed one of Math.NET Numerics obscure probability distributions for realistic randomized wind speed.
2: await would make multithreading easier. I do a lot of multithreading in my code. Because you get a nice free speed up.
3: GC also would help.

I would like to think unity will get a new mono within 18 months by the time of unity 5.0

 

To clarify, the question is do we as developers ( as a broad community ) truly need features other than those currently available? By holding such debate there is always the chance that useful trends might become known, and those can in some cases help in decision making ( GC being one obvious long-established trend that lead to UT looking at alternatives ). For example, if Math functions crop up repeatedly, then UT might consider providing something similar. If however the majority say they are happy with the feature set, that would support an argument that an update of Mono wasn't required.

 

Which I agree is a good question, to which the answer so far for me has been "no".

Edit: To make that more concise... the additional tools would indeed be helpful, but when it comes to asking whether I can still do what I need with Unity, the answer is generally still "yes", and the vast majority of the time the impact as compared to having a newer .NET version is pretty low.

 

So if you don’t care about any new features why are you even here discussing this?

When 5.0 comes out I would gladly pay a 50 dollar mono tax.

Because licensing is primarily about $$$ and unity already has someone who works on their fork of mono. The question is not about development time really. It’s about how much is the end unity user willing to pay for it.

Or unity can use the LGPL on PC and Mac where it really matters and keep the rest on 2.6 forever

 

I don't think it's possible for me to care more than I do:
http://forum.unity3d.com/threads/14...ons-and-Third-Party-Assets-in-the-Asset-Store

TL;DR: 15 months of campaigning for a mono update, realization of the commercial challenge faced by UT, followed by acceptance of that reality and a shift from staunch critic towards advocacy. That experience lead me to question the importance of my request for a Mono update.

 

Ya you where foolish for wanting a Mono update so early before SGen is even full developed. SGen still needs more dev time I think.

 

My apologies. I stand corrected

I got confused between the LGPL license and the commercial license

 

I think it's a bit worrying that all our queries about this issue seems to land on deaf ears. All other questions about upcoming or present features are relatively well answered, but when it comes to updating mono, ut seems to ignore them.

Would be a bit reassuring to even know that if at some point in the future this will happen... Unity for a developer is a long time investment, and I don't want to invest in old tech.

 

Well, if the answer we are looking for depends on some negotiations then no one can answer before the end of that process, right?

 

That's presuming there is even some sort of negotiations on going. And what about these would be negotitations failing, do we stay forver still with this mono? There could be a lot of more answers than "yes its coming at some point". Even answer "we are ditching mono/.net altogether" would be more satisfying than silence.

We practiaclly know nothing of this (correct me if im wrong).

 

No information from Unity is the only thing they can do. I assume that Unity is talking to Xamarin. If Unity announces anything, they would very likely weaken their position.

 

Correct.

In order to have (maintain) some leverage in the negotiations, Unity needs to either remain silent (as to not show their hands) or if pressed to provide some insight to the community, behave as if they are confident they can provide the set of features and improvements we need whether or not they move forward on a new license deal.

As far as the community is concerned, we just have to wait until Unity is ready to make some official announcement.

 

Valid and a good point, thank You. Now if we knew for certain that they are negotiating with Xamarin

 

I'm using the Xamarin version and it's faster compared to the current monodevelop version embedded into Unity, i switched to it a month ago and it works flawlessly, the only need to let it work is to install the alpha plugins for unity inside the alpha repository.

 

This is why you go with a JVM based solution - Scala or Groovy ftw !

 

re: jvm

believe me you dont want java


re: mono develop

wow this is great monodevelop is being updated


re: mono runtime

and while they didnt update the monoruntime it even sounds like they branched monoruntime so perhaps they can resolve or alleviate some of the issues

i think its here

https://github.com/Unity-Technologies/mono

so is this the version of mono that unity uses, will be using?

is it the branch? or just original stale version?

is the whole source code out so someone could build it and try it with latest unity?

if so i can get it and build it and replace the mono in unity 4.2 and try it...

i guess its this one for 4.2

https://github.com/Unity-Technologies/mono/tree/unity-4.2

or is it this one
https://github.com/Unity-Technologies/mono/tree/unity-4.2-staging

if so perhaps someone / some group would tackle some of the issues

i do believe i have a of amd codeanalyst (nice free profiler)
http://developer.amd.com/tools-and-...d-tools/amd-codeanalyst-performance-analyzer/

and very sleepy
http://www.codersnotes.com/sleepy/

installed on this box...

plus microsoft visual studio profiler...

and i also happen to have handy a copy of benchmark suites

The Computer Language Benchmarks Game
http://benchmarksgame.alioth.debian.org/

The Great Win32 Computer Language Shootout
http://dada.perl.it/shootout/

i wonder what we will find...

 

I am upset with the mono runtime.

It is buggy, missing fixes and compatiblity for basic C# things like generic interfaces, and it does not provide meaningful error messages or stack trace when you trip over a bug or limitation.

I have been a paying Xamarin customer for 1.5 years now (and they are top notch) and shipped 3 apps, but I have not bought a Unity license yet (though I have bought some assets, and been to a conference), because I still have yet to get my existing C# codebase working on iOS without crashing with no stacktrace (which makes it time consuming to find problems.) I would have paid $4000+ if it meant avoiding all the nightmares I now know I'd have.

I have run into various bugs inside mono, old bugs that seem to have been fixed in the newer versions of mono. I have contacted the original mono developer who understandably didn't want to help. I learned about the JIT code in the bowels of mono that ironically still runs in AOT mode, and I learned what an IMT is. I learned what trampolines are. I learned that mono developers use g_log C function for assert failures at line 406 or whatever of mini-trampolines.c, since that's the only clue I had showing up on my iPad. Another clue was CLR objects were mysteriously turning into strings, causing bizarre runtime errors.

I learned how to read, write, and rewrite MSIL (fun, but not productive.) I wrote an open source project to analyze my code for AOT problems, warn on some and try to fix some, by using Cecil to modify my compiled DLLs. (https://github.com/jaredthirsk/AOT-Compatlyzer)

I may be close to getting all my stuff working, but I can't go on like this anymore. Death by a thousand cuts-- I'm only bleeding slightly now, (560+ #ifdefs related to AOT, so only 560 cuts), but I don't know if there are another thousand, and I don't have time to figure it out anymore. I don't really want to have to replace each and every foreach in my code, for crying out loud (1300+ of them). (http://forum.unity3d.com/threads/168019-quot-System-String-doesn-t-implement-interface-System-Collections-IEnumerator-quot-crash).

Today I ran my code on PC for the first time in a while and the editor hard-crashed because of lack of covariance support on generic interfaces. (No stack trace for that either, but fortunately, I remembered it was a problem.) So I put in some more #if's back in to instead have the half-baked strong typing, plus casts.

I suppose I am a bit of a risk taker, and I feel I got burned by thinking I could bring my C# code to Unity and use it, and expect to have mono keep up with the official mono more closely than it has. It goes with the territory, I suppose. Double down too many times and you eventually lose everything. It may mean my dream of launching a startup fails. That's life and I accept the risks.

I just want to be sure I add my voice in support of getting an updated mono runtime.

Also consider that saner folk than me have probably tried and given up and aren't still here to voice their opinion.

Also, perhaps potential newcomers should be warned that they aren't getting real C# here, even moreso than the AOT-related caveats that are already out there the last time I checked. On top of the AOT restrictions that were at least partially documented the last time I checked (and Xamarin has removed some restrictions that Unity is still stuck with), there are AOT and C# related bugs in Unity that crash with no stack trace.

And as for newer .NET features, C# is really cool and appealing, but if you strip enough away, it starts to stink like it does for people who are stuck with .NET 1.1, or NETCF -- some crippled version, which is a turn-off and a disappointment. (People may like async/await and I would appreciate .NET 4 compatibility, better GC, and I would definitely like the improved AOT support for generics.)

I'm not sure what's going to happen for me next. I already pay Xamarin for stuff that works -- maybe I will flip out and make the jump to cheesey casual 2D iOS games using some game engine that runs on Xamarin's software and be happy with a simpler life. Maybe I will rewrite my codebase from scratch, testing it on iOS all the time to make sure I didn't break something. Maybe I will go back to the PC graphics engine I was using and stick to PC. Maybe I will finish my whiz-bang AOT analysis tool and automate fixes and warnings for everyone struggling with the same issues, and I will be the toast of the town. Maybe I will be forced to get a job at Starbucks and realize that my true calling in life is to serve espresso. If I totally lose it and switch to Java, somebody shoot me please. It makes me kinda mad that I'm paying Xamarin piles of money for their stuff that I use once in a while, yet their licensing is holding up what I'd rather be doing with Unity.

LGPL open source 1, closed iOS platform 1, me 0. (I'm not sure if I'm more upset at Steve Jobs or RMS or UT or myself.)

 

Under the heading "Better scripting":

Is this maybe possibly a hint about upgrading Mono at some point within our lifetimes? Hopefully?

 

I have been using the Mono with Unity 4.3 for the first time today and although i do like the new look and feel of it there are lots of bugs. Here are a few nasty ones that others must be experiencing like me...

1. It seems to like to stay on top of other windows. This is not nice since when i'm flipping between the browser and the mono develop in Unity 4.2 it was naturally easier than having to keep pressing the minimise button each time. Annoying (any way to change that default behavior?)

2. Mono looks like it crashes when it pops up the save dialog window, but since mono IDE is on top of the save dialog it gives the impression the Mono has crashed. The save dialog should be on top of Mono window so you can see it. Annoying!

3. The behavior of (Point 2) ment that the code i had written for the last hour became lost since i had to reopen unity and Mono had not saved these changes.

4. If opening up two Unity projects like you do in a networking dev environment, and clicking on different scripts from either project, the Mono IDE gets confused and starts showing scripts in the tab line from both projects whic is ultta confusing. I preferred the older Mono in Unity 4.2 which always reopened Mono IDE with only a refresh of that Unity instance projects scripts.

5. When pressing the Debug button in Unity Mono 4.3 its been crashing as well.


I thought the beta version was meant to pick up all these fundamental bugs? I'm going to have to go back to the old Unity version 4.2 until these critical Mono bugs are solved.

What a shame i can't wait to use 4.3 properly !!!


Please can others try these points rigorously on their projects and provide feedback here

GXMark

 

@Gxmark - I am not seeing that behavior. Monodevelop will go to the front/back just as I expect. When opening a save dialog (or any other dialog), the dialog is on top just like I expect. I am on a Mac, using Mavericks. Someone also commented on the debug crashing issue with a workaround on another thread, though I have not tried that yet:

http://forum.unity3d.com/threads/210329-Unity-4-3-Tips-amp-Workarounds

Jaimi

 

I'm running on a windows 7 machine and its happening to me on that OS.

 

An excellent question which I can happily answer "no". I would much prefer to be able to use the features we already have. I don't mind having to be sensible about object pooling but I should be able to write "foreach" and "RaycastHit.rigidbody" without worrying about the garbage collector.

 

A little off topic but it'd be interesting to see some kind of integration of Unity with Xamarin.Android/iOS - the ability to launch/interface with a Unity game from within a Xamarin app - Or use the Xamarin API from within Unity (including launching GUI screens).

 

Just to be clear, these all seem to be MonoDevelop (IDE) bugs, not bugs with Mono (the runtime) itself.

It sucks that MonoDevelop is buggy. Aside from the debugging issues, I'd suggest giving another IDE a go if you want to stick to Unity 4.3.

 

Developers don't really "need" anything, but only in the same sense that we don't really need Unity. Of course I could just go back to C++ and OGRE, but that's a huge pain.

Besides the extra language features of C#, every ounce of performance matters for anyone building CPU/memory-intensive simulation games (which generally includes the billions of Minecraft clones that people attempt to make). New versions of Mono make a big big difference in that respect.

 

Don't know about you guys but I'm digging the new script editor... now auto-completion works all the time!!

 

What version of NET does this new Mono 4.3 uses?

 

Any way to change the theme from mind destroying white to something darker? Oblivion is fine for the text editor but I haven't seen a way to change everything else.

 

There's no new version of Mono. People need to stop confusing Mono with MonoDevelop. It's like Java/Javascript except worse....

--Eric

 

It's not just the language features, it's in total a little ... well.. scary to consider Unity is using nearly 10 year old tech, even if they are forking and upgrading themselves slightly. officially .NET 2.0 is supported which is nearly 10 years old. The API is lacking, MEF, EF, async/await, a lot of stuff in general that would not only be very very useful for game developers but could also be used to modernize the Unity API itself, is just missing.

And quite frankly I think sooner or later people are going to re-thing investing in development with Unity when they realize Unity is stuck technology wise. The graphics and physics engine is not everything. The scripting engine is still a very core feature of every game engine, and that part seems to be totally tech frozen and incredibly outdated and there's currently no indication that this is even a major concern of the Unity team. And that bothers me a lot.
I don't mind so incredibly much having to work around some of the missing stuff (even though I sure could use a lot of it already and feel held back). But it really scares me that this doesn't even seem to bother Unity much, no statements being made about this being even a problem, when I consider it the biggest issue with Unity in total.

The question for me is: If I'm investing in developing with Unity, am I investing into the growing and expanding .NET/Mono world, or am I investing into a slowly dying fork of a company that cannot or will not aquire a license to guarantee evolving together with everyone else in that world.

I once left the gaming business already because I was sick of writing C++ against stone age compilers (c++ 11? yeah right...) and 20 year old tech when the rest of the industry was leaving me and studios like the one I was working in decades behind.

My question is, am I facing the same here now or is Unity doing everything they can to make sure they keep up to date with current industry trends. DirectX11 support is one thing, having a scripting engine, a runtime and compiler that are next to a decade old is another. Currently I consider Unity to be a very open and great platform, but I don't know whether it is growing and alive anymore where the development is concerned. mechanim and all that stuff is great for art content and all. But if Unity is leaving their code-developers behind in the dust... I dunno. that just doesn't feel very good. So I hope we're going to hear something about this soon.

 

@KeldorKatarn
I agree with you, C sharp is going to evolve even more and we will be behind (we already are).

I still don't get the problem for the license by reading: http://xamarin.com/licensing

For PC/Mac shouldn't be an issue, or am I missing anything? Is it to do with the Android/iOS license? What if I only ship for PC/Mac?

Or the issue is to do with the fact that Unity (as product) is not shipped as LGPLv2?

 

no offense, MS being MS and all, but vs 2012 combined with unityvs == win.

now if we could just bring the version of mono that UT uses, kicking and screaming into the 21st century, that'd be cool.

tuples anyone?

question: unity pro is 1500$, right? so i'm not understanding the big deal to offload part of the license fee to the customers? OR make the scripting pluggable in a way that if I wanted, I could get ahold of xamarin and sort out my own license with them.

shrug.

not sure what the pro user count is, but for kicks let's say it's 5000 folks (surely out of 2million users http://unity3d.com/company/public-relations/news/unity-technologies-doubles-community-two-million-developers, that number is reasonable?). At 50$ there's 250k$ towards licensing right there.. Now if it's about royalty free issues, then yeah, I can understand as I don't want to have to pay UT *and* xamarin if something I put out somehow takes off, BUT depending on the cost and how well I might be doing, it might be the lesser of evils..

again. shrug.

ultimately as a dev, I hate having the latest version of anything on my system (.net 4.5 for example) and not being able to use the features that I've come to rely on. I mean, I open my project and it 'feels' like c#, but not so much..

 

+1

+1

Especially now that MS opened the PCLs for all platform, immutable collections, Rx, all those nice libraries just waiting to be used. After finishing this project I'll jump to monogame/delta engine/wave engine/custom whatever if the situation hasn't changed in Unity. I'll lose excellent editor and extensions but having crippled programming environment is too much of a buzz kill for me. And I still plan keeping my promise, new Mono in Unity, I buy pro even if I don't publish anything, just for support.

The newest info was that UT is doing "something internally". So I guess we will have to live without a runtime that has bunch of specialists dedicated just for that feature and with a history (xamarin) and use some - I'm guessing - monstrosity akin to what UnityScript is to JavaScript but only what .NET/Mono is to this internal runtime.

Sorry if that seemed a bit harsh but hey life is eh?

And what comes to newest MonoDevelop, it's kind of fun actually. About 50% times it won't open, it just shows the splash screen and hangs there. If I kill it and reopen it, it sometimes opens!

If I use debug in the MonoDevelop, Unity won't close after that, it hangs if I try to exit.

As a bonus, we also get the most exciting refactor feature on the planet, let me introduce it :

... member def code ...
private Camera camera;
... initializer ...
if (camera == null) throw new UnityException("Camera required");
... more code ...
renderer.material = material;

Now I move the cursor to the camera part and press F2 (Refactor -> Rename) and see what happens (note I have not typed ANYTHING YET)

... member def code ...
private Camera camera;
... initializer ...
if (camera == null) throw new UnityExcepticameramera required");
... more code ...
renderer.materialcameraerial;

Cool aye? Had to readjust my eyeballs for this WTF moment...

 

Ok here I have to be completely frank. If all this is being held back because the license issues for mobile cannot be resolved then I'm a bit pissed, since I personally don't give a crap about mobile. Yes I know a lot of the Unity developer base came from indies developing for mobile. But... alot are now also targetting the big platforms and desktop. And I'm sorry when I develop for PC/Mac/Linux I don't want to be crippled because some damn Phone doesn't work out.

And I also agree with other people here. I don't care all that much about all these wonderful features here if that means I have to live in .NET 2.0 world for the rest of my Unity developer life. No way. I don't depend on the multiple platform support that much since I don't target most of them. And that means I care less about how many platforms I can target but rather about how well I can target the few ones I want to target. And with .NET 2.0 I'd say I can target them pretty badly where code is concerned.

The entire Unity API feels outdated, not fresh, in some places really really bad. The async API is crap, the support for modern patterns like GUI databinding, decoupling of the elements, Dependency Injection, Unit Testing... all that is very very very hard to do. That could be changed over time though, but only if the API is being build on top of a robust, modern and living and breather runtime.

I feel Unity is wasting a heck of a lot of developer time internally to fork the runtime instead of just buing it and upgrading their own codebase and API instead.

Unity became this big because it was incredibly easy to use, both editor and code wise. If Unity keeps missing the bus when it comes to Mono support, that will fade away since developers will more and more have to spend time with finding out how to work around mono limitations instead of focusing on their game being able to use all C# and library features they are used to. At that point developing won't be easy anymore but become a chore and people will move elsewhere.

 

Whether is there a filed suggestion that we can support with our voices to resolve this issue?
I was searching and found some.
* Licenses to support open source projects
* Make it dual-licensed GPL and proprietary
* Unity3D Integration

Should it be searched elsewhere?

 

I wish GPL typed licenses would vanish off the face of the earth. They have done nothing but harm and having nothing to do with being "Open". They're a cancer to software. The problem's we're having here with Mono being LGPL and similar issues with other libraries under that license is the best proof of that.

 

^ This. For years, my team developed for the Delta3D open source game engine. As an LGPL Open source project, we were intimately aware of GPL vs LGPL issues. I trust Unity will find a workable license arrangement for the updated Mono ... eventually.

Gigi

 

Just wanted to let someone responsible for decisions know that I really, really dislike the new MonoDevelop. I had to turn autocomplete entirely off because it kept autocompleting nearly every other word I typed to stuff I didn't want, and often to things that didn't even contain the word I was using, even when I turned the "aggressively autocomplete" option off. What's worse is that it freezes frequently (as in multiple times every line) for seconds at a time when typing or scrolling.

Is there a simple way to downgrade my version of MonoDevelop? This is bordering on unusable for me.

 

Resolving license issues in an open source project can be tricky. Sometimes, each contributor owns the copyright to everything they've done, so you need the permission of everyone who' sever submitted code to change the license. It can become a real nuisance.

They can be frustrating, but right now there's little that can be done about it. Go find another game engine if reality bothers you.

Eh, I wouldn't expect anything too soon.

 

Ok so what "version" does unity 4.3 use? I mean I need to know what .Net version compatibility there is.

 

.NET 2.0 + LINQ and SOME stuff out of .NET 3.5, but not everything.