2019.3 entered the final stages of beta testing

Lambdas are bad for performance (garbage collection). But in the current ECS version they use Lambdas and use custom Lambda compiling to create Jobs.

 

Unity's FunctionPointer class in ECS is pretty damn sweet (once you get past the boilerplate). I just wish there was a way to check if it was valid.

 

Seems like that's not going to happen, at least it didn't within my predicted time-frame. How could I be so wrong with that?!

 

Well I don't know if much faster, but I can understand they'll be faster. The ability to shoot yourself in the foot is indeed greater with C++ but it's not that much greater. Boilerplate code is always annoying but the whole .h and .cpp thing I always preferred over having function definitions within the class.

Quite honestly I can't really put my finger to what I dislike about UE4... the UE4 C++ code feels horrible, the macros (which should really be replaced with constexprs by now), the naming, everything... if you contrast it with, say, Qt, which is a mostly C++ framework for application development with beautiful documentation and great naming conventions that make a lot of sense you really see that it's not C++, it's Epic. So I really doubt adding an extra language will fix it, it'll just be more of the same.

 

True. Currently, I live for the day that Unity to port the Editor to .NetCore. I'll be the best thing, the last thing and the only thing I'll die for.

 

I can tell you an example from my own experience. I'm an artist, who always wanted to make games. But I just couldn't find a programmer willing to work with me on my own ideas in my small town (and really, why would anyone do so? Everyone has their own ideas). So I bought a book about learning programming in C++ but I just couldn't understand anything.

Then one day, I was looking at some Unity js examples and suddenly got it! From then on, it was easy to just learn scripting through examples on the internet. After only one year, I was able to make my first game. Then I easily switched to C# and made a second one, and a third. All of them failed but then I made the fourth and it was a success. For me as an artist, it was a major dream come true!

I think that Unity primarily got such a large user base because it was really easy to learn how to use for non-technical folks. It was a perfect match for indies who are somewhere between art and tech. That might also be a reason why there are a lot of bad and amateurish games made in Unity, but so there are a lot of bad and amateurish books and music because everyone can write a book or make music now. That's what I think democratization of game design means.

 

The macros are a necessary evil due to C++'s lack of reflection, among other reasons, since the code in UE4 needs to interface with a scripting layer and support "automagic" serialization. I'm not sure constexprs have the codegen capabilities needed to generate that much boilerplate code, but I would love to be corrected on that. For example, in CryEngine you need to create a whole bunch of extra classes, functions and interface implementations to expose a C++ type to their Lua scripting layer.

Thing is, even with all of its warts, C++ is a "first-class citizen" on most platforms, while C# is not. Porting and maintaining a whole .NET runtime for a whole bunch of platforms is no joke (especially closed platforms like consoles), and it adds a gigantic, mostly opaque layer between your code and the OS, while C++ "just works".

Microsoft open sourced .NET, but getting it working on the likes of PS4 and Switch still takes considerable engineering effort, and any CLR upgrades/changes on Unity need to be ported to IL2CPP (which is basically a proprietary runtime).

 

Others have already mentioned very valid reasons to which I fully subscribe, but the reason I'm staying on – for now – is really the investment I've made in creating subsystems and tools in C# which would require a lot of effort to convert to C++. I've worked in C++ before, so the language is not a problem. However, the time required would be substantial. Also, I would have to find replacements for middleware like Vegetation Studio Pro and EasyRoads3D and adapt my custom tools to them. Thus it's more likely that I'll switch after my current project is finished.

The real problem is that with the state Unity currently is in and has been in for a long time, it's getting difficult to gauge whether the project can be completed in Unity at all, given its instability and constant slowdown. And working with a large project in the Editor is a massive pain, despite using a very fast computer with 12 cores and 64 GB RAM. So I might have to bite the bullet anyway, as Unreal scales much better.

The differences of opinion in this forum reflect more than anything else, I think, the various kinds of projects undertaken. Teams who do small mobile applications suffer less than those who do larger projects for desktop and consoles.

 

I get what you're saying, I agree with those issues, but I really really don't think C++ is the problem with UE4, I think the UE4 API is the problem with UE4. And I don't think adding another scripting language will help a lot (or at all) here.

 

Oh! Cool, okay, I really don't get that because I actually got to C# after being quite familiar with C++. I never really found C# to be that much easier by comparison, I simply always felt Unity examples were that much better written and, again, UE4 horrible scripting API. Just out of curiosity, how do you feel about MSDN C# examples? Are they easier than the C++ ones?

While I do understand why you're considering moving to UE4 (I guess even if you don't have trust issues with the current engine provider you should always be aware of alternatives as well as the cost of jumping ship) I really can't see the api becoming any cleaner or easier to use just because they'll add a new language to it. Porting a Unity project to Unreal will always require a complete rewrite and the workflow is always going to be massively different. Everything from the api to the lack of a scene view and the ease with which you can write run-in-editor code in Unity, I really don't know. I understand your concerns but as for me, I'm not prepared to jump ship just yet.

 

Yeah good point, serialization will require reflection, I guess.

Hmmm, isn't IL2CPP pretty much a transpiler? It's as you said, C++ just works, and Unity takes advantage of that by translating intermediate language to C++ and then compiles it to binary with a native compiler.

 

I often struggle with MSDN examples as well, I can understand them better than the C++ ones but I think it's because of familiarity with C#. With Unity examples I actually look for a way to do something in game design, and learn some common programming stuff and methods along the way. While if just browsing stuff at MSDN, I would often think "OK, but why and when would I want to use this?". MSDN examples seem more appropriate for programming database related software and similar stuff. In Unity, most of the time I deal with Vectors and geometry that I can visualize, not complicated databases. The only time I had to work with lots of data was when I was programming a leaderboard and making it work with both Steam and PSN servers. It was boring as hell Also, the language in MSDN assumes I already know a lot of programming terms as if I went to an appropriate school, which I didn't, I'm an architect actually. So, I know this is blasphemy , that I should have gone to programming school and should know proper terms and basic stuff, but amazingly it works for me this way so far.

Yes, I agree. I didn't mean to port my current project but move to Unreal with my next one from scratch. That won't happen in a few more years for sure.

 

Right, but it'll still require a lot of relearning, even if they do add C#. The problem is, unfortunately, that old adage - you can program COBOL in any language, so while I do love the way UE4 works I wouldn't hold my breath for them to add C# support, and if and when they do my money is on the API being not too far from what they have now in C++.

I didn't go to programming school either, I did an engineering degree, but I did start out learning programming with C++ (which is hard, but really does make you understand a lot) and a couple of years ago, to plug up my knowledge gaps I took a good few online courses though, I found those helped immensely

 

The transpiled code still needs a "IL2CPP version" of the .NET Framework to work, however. The converted IL2CPP code needs things like lists, managed arrays, dictionaries, garbage collection, memory management, type reflection, and much, much more, and everything must behave as closely to a standard .NET framework implementation as possible to keep things from breaking. You can actually go into the Unity install folder and you'll find bits of their C++ framework there.

 

It's all good, people make mistakes. 2019.3 probably shouldn't haven been in the releases section and I probably shouldn't have upgraded to it. (I did have a 2019.2 backup and tested before sticking with the upgrade.)

The upgrade from 2019.2 to 2019.3 went smoothly with no visible breakage, it performed well in testing and the new UI was an improvement, it was only with more eyes on it that it's stability issues became apparent.

I was driven to update to 2019.3 in the hopes that bugs in 2019.2 would be fixed. 2019.3 felt like them stepping back and improving the core, which is MUCH needed.

I think this statement from farther up summarizes the crux of the issue, not just with 2019.3 but updates in general:
"We don't want "new and exciting" at any cost. We want stability and dependability."

From what I'll admit is a mostly outsider's perspective (I've used unity for 8+ years but I don't try to keep up with the latest happenings minus reading release notes). It feels like they are biting off too many things at once, sacrificing stability and usability now to get to their end goal as quickly as possible. (which has turned into a PR nightmare)
Then they also have a tendency get a new feature 90% done and then move on to the next thing before it ever really feels production ready, so hopefully all this stuff they are working on today doesn't just die off in a few years from being not quite good enough to actually use like UNET.

 

Anyone else getting an editor crash every time you try to connect the visual studio debugger?

Unity 2019.3.0f5

Edit:
And apparently the bug report window doesn't work either.

 

Are you aware that UE4 has blueprints? They're specifically designed to aid the development by non-techy guys. I don't know how complex your games were but considering you had no prior knowledge of coding, I can't imagine that blueprints would not be able to give you the complexity you required.

Do you mind sharing the title you published on PC and consoles? you got me curious

Happens to me on 2019.2.18. Not every time but at least once a day. Great experience isn't ?

 

As I see it, the bigger problem with UE4 is the royalty - "..5% royalty on that amount after the first $3,000 per product per calendar quarter". That's saying the royalty payments start at $1000 earning per month per product. Whereas Unity gives Free version for "Revenue or funding less than $100K in the last 12 months". Financially, Unity is the clear winner. So the casual approach is a bit expected, they don't give the best because they don't earn that much, they know the software is crappy and that's why they give it for free!

 

Yeah, I know, but it seems very limiting and I never tried it. Now after knowing how to script, whenever I go back to 3D modeling I hate it how much I have to click around the screen in order to accomplish anything. Coding is great, it seems faster and you can do really anything.

Yes, simple games of course. But still I can't imagine some parts done with node-based coding (probably a wrong impression).


I just hope Unity will rethink their strategy and prioritize stability and certainty, but I also understand that, as being a company, their utmost priority is profit, so who knows what happens next

 

Wondering when is this expected to get out of Beta.
January is almost done now...

Or we go straight to 2020.1 ?

 

Around last week in January,first week in February.

 

When It's Ready™

And don't expect 2020.1 to release until sometime between April and June.

 

I've only recently given the 2019.3 candidate release a spin and I've run into something pretty annoying:
Previously I could put GameObjects as children into another GameObject with a Grid component, and those things would then snap at HALF grid intervals. The way it works now is I seem to either get no snapping, or the default 1 unit snapping. Snapping to half intervals is important for positioning things which are and odd number of units wide or tall.

Am I perhaps missing some new way I can get half unit snapping?

 

Cant you change them to 0.5??

 

What bugs me also, loading the package and loading SRP project, takes long time. This should be also addressed because it could get worse.

 

Is there some way to do that? If I change the Grid of their parent to be a 1/2 unit grid, that does not affect how they snap, and I couldn't find any Unity preferences for snap intervals.

 

I cant seem to successfully build anything with URP

Edit->Grid and snap settings

 

That seems to be bugged in that changing the snap in those settings to .5 does nothing, but changing my Grid Size to .5 does the trick. I'm not sure what other, if any, side effects changing the grid size may have though so it's a little worrying, but at least I can move the items around correctly now. Thanks!

 

Boom!
https://forum.unity.com/threads/unity-2019-3-is-now-available.817029/

 

WTF

 

is this a joke

 

It made me think that all bugs are solved, then I came here to check and the bugs are still there. Not downloading 2019.3.0f6. For now, 2018.4.16f1 seems the best, as LTS is a sign of reliability.

 

Really ? no way lol

 

Oh boy, time to raise some hell in this thread once again

 

What's the point. Nothing we say here will change anything anyway.

 

I predicted correctly. 2 tech streams are better choice for robust engine.

 

Two tech streams is not a "better choice." Stop pretending it is.

 

It is. Team can focus more on polishing new features for stablility and robustness.
2019.3 took long time with UI changes. They weren't necessary for production. SRP and editor performance should be priority. With 2 tech streams, team can focus priority on core important aspects.

 

Don't upgrade live or in production projects on the first day of release and cry afterwards. From the Blog post:

 

zero tech streams is the best choice

 

Well, this is the sixth final release, it says it right in the version number

 

Or, get this:

They could have pushed it to 2020 instead of taking a steaming loaf on 2019.4, like has been recommended.

 

To clear up a potential misunderstanding above, "two tech streams" likely means "two TECH stream releases instead of three" here instead of having yet another TECH stream beyond the one we have already.

 

They did drop the ball on this one, you don't rush in such a large feature right before you're gearing up for the LTS release, you do these things at the start of a new innovation cycle, i.e., 2020.1.

 

Which is ironic because Unity depends on devs shooting themselves in the foot with "production ready" releases to catch the myriad of bugs that only happen on actual production use cases. At least the bugs that can be repro'd on near empty projects, that is. If it's a random crash that only happens on a 50GB project with tens of thousands of assets, you're SOL.

 

Unity seems to agree with @konsic

 

"production ready" don't mean "stable" ... these days.
My main job is Webdeveloper. I work with the CMS TYPO3, this has a similar release cycle as Unity, with TECH releases and one LTS on the end (but 1.5 years per cycle). I never using Tech-releases for live projects and wait some patches after the LTS release.

 

I'm taking a jab at how Unity basically uses their customers as their CI nowadays. If everybody was cautious and waited for LTS, then LTS would be just as buggy since the way Unity tests things internally is apparently woefully insufficient, based on the kinds of bugs I see reported on the forums and the occasional responses from Unity staff.

 

Another nail in the coffin...

 

That's very disappointing.

I put so much effort into bug-reporting and was always keeping the faith, but I'm really questioning if that was and will be worth my time. If you can't fix issues that were introduced during the beta cycle, what's the point of beta testing anyway.

I'm very sorry for the people at Unity. People who want to deliver a great product, but can't because of reasons. That must be very frustrating.

Spoiler