Official Unity 2019.1 Is Now Available

ok thanks, I will do it

 

Like it seem to be hard for you to check an 1:30 video : https://forum.unity.com/threads/edi...field-is-broken-with-unity-2019-1-0f2.665479/

It look that you try to defend the 2019.1 version of unity, but do you have tried to work with this version with a real project?.

Just with the bug listed above, you can't work on any project according that you can't have access to the input field on your script !

Free for you to come see other bug's here https://forum.unity.com/threads/share-your-unity-2019-1-0f2-experience.670816/

Maybe you will be able to show me that this version can be used, but i can't move forward with this "public" release.

Also , keep in mind that some problems has been reported in March and still not fixed on this "Public" release !

Some people said also "why you do not wait after 2019.2 or 2019.3 cycle before updating? the real question must be why Unity do not fixe issues reported 2 months before the release no?

Have a good day.

 

I'm not trying to do anything and I currently use 2019.1.1f1 in a real project. It remains that you didn't need to make a video to state your point.

If you want anyone to try and reproduce your problem, post your script; I'm ready. Also, did you open your script in VS and recompile it before noticing the problem?

The other question being: "do you really need to upgrade an advanced project to a new version of Unity?"

 

This is not true, many of us are working with 2019.1. Not everyone use duplicate component scripts with 50 member values on a single game object. My scripts sometimes contain 10 maybe 15 but then it becomes messy. If you break up your script to smaller pieces, it will work just fine in the mean time. Or you can have your giant monster-scripts and wait for Unity until fix the problem. You have choice.

 

Again, you replay without checking my content.

If you check my post here https://forum.unity.com/threads/edi...field-is-broken-with-unity-2019-1-0f2.665479/ , you will see that this post contain a case number, that mean that i have already reported it the 21 April !

It's an editor problem, not a script problem ...... They know it already .... Unity answer :

"""Thanks for submitting this issue. We've identified it as a duplicate of an already existing issue, therefore this case will be marked and closed as such. Unfortunately, there isn't an issue tracker entry for the original case, so I cannot provide you with a link containing more information.

This bug should be fixed in 2019.2 version of Unity."""

Unity 2019.2 that will be released in July ???? Really ???? what a joke ....

Yes and for two reason :

First : I publish WebGL game and the "Broken" Multithreading feature become available starting 2019.1, so i have to move forward to give at my players best performances.

Secondly : Unity push everybody to move forward by deprecating old system and i do not have the time to wait after an LTS patch that will take a year to be released.

 

Okay, complaining is irrelevant then, since you got an official answer and already know that the problem could be fixed in 2019.2.

Why don't you try 2019.2 alpha and make sure the problem is gone?

 

I'm happy for you that it's not a blocker for your project but most of time, a big project contain big scripts with multiple values. It's an UI/Design problem on Unity side and it can be avoided with proper test.

But they are rushing as always.

I'm making these post because 95% of the problems that we are talking now has been reported 1 or 2 months before the release of the official version, this i why it's not acceptable for me.

It's like you are making an FPS game in beta stage, an user make a report and tell you that the rifle is not working but you push the official release without fixing it. How you can play an FPS game without rifle?

So how i can work on my project :
-Without been able to edit the input of my script? (https://forum.unity.com/threads/edi...field-is-broken-with-unity-2019-1-0f2.665479/)

-Without having the playerpref working with WebGL (https://forum.unity.com/threads/playerprefs-in-2019-1.665254/)

-With an UI broken when you play it with a script (https://forum.unity.com/threads/sizedelta-broken-on-unity-2019-1-0f2.663268/) ?

And i repeat, most of these problems has been reported 1 as 2 months before the official release.

 

Because Alpha is Alpha, maybe some bug will be fixed but new one will be created, so there is no reason to use Alpha version unless for reporting bug. But like i do not work for free, i will not lose time on this.

 

The most reliable and efficient way to get a bug fixed is to submit a bug-report as described in the official "how to report a bug" guideline.

If you don't submit a proper bug-report, it might be a long time until someone else reports them or until Unity Technologies find them.

Posting Unity bugs in the forum does not lead to a resolution in most cases. You're really just wasting your own time "reporting" issues in the forum, rather than submitting a bug-report.

Further than that, some issues might be specific to your project only. If you don't submit a report, you lock your self out from newer Unity releases. This applies to all versions, not just alpha/beta versions.

It often takes several months for Unity Technologies before a bug gets fixed, that's true. However, during beta phases, beta specific issues are often fixed faster.

That's why I found it important, if I have a non-trivial project, to always have a copy of it running in the latest beta version. This allows me to report its issues way in advance before I actually switch to that new version.

 

It has been done by me and other people too.

We do and we are still waiting too long.

You right, it's why we make report and we are talking about bug reproduced by the staff already.

Talking about these bug here can inform other people how they can lose time by waiting something to be fixed and can also help the Unity staff to know that sometime they go wrong (yes, yes, it's not because the Unity staff do something that they are absolutely right ! they can go wrong sometime) .

So for you , it's normal that we have to wait 2,3 or even 4 months for a bug to be fixed when it was reported during beta stage?

I do the same and i only release my game when i'm sure that no bug is present, but remember that it's an official release.

So now, imagine someone new coming for making a small 2D game with WebGL and sprite with the last Unity version.

He can't !!! Because the playerprefs is broken with WebGL, the UI (sprite) is broken when you access to it by script and you can't edit your script if you have too much input value in it.

And i just talk about 3 bug found according my project, you just have to browse on the editor part of the forum to see the rest.

 

Yeah, I agree with you that it should work in Unity, but also as a software developer I think it's a major design flaw in your software/game design. It's inefficient to look through all of your parameters. No experienced and sane developer would do such a thing.

Nope. ONE user reports that a stack of riffles don't work for HIM. You really need to start to think about this problem as it is: juggling with time and advantages. They could delay the 2019.1 so you can have your bug fixed in it, but then they would delay for everyone else who does not care the giant monstrosity-parameter list. They chose to ship and fix the problem later. Probably because the majority of the developers would never and don't have this kind of property-mass in their scripts. Overall, it's a win, we can work while you're waiting for your fix and we aren't destined to wait with you in the mean time. Since you're refusing to refactor your script, which is your decision.

It's normal for me, depends on where the bug is. If it's core C++ Unity, it takes extra long to fix (for example, serialization problems - like yours seems like it), because it touches everything, they need to fix it carefully, because it's slow to fix if they screw up. And basically it affects every platform, every build, etc. I don't think it's surprising that it takes time, especially if they want to run all the tests on it and they want to merge it to most "live" developed version.
Smaller bugs, especially if they are on the C# side, or packages, this time is significantly shorter.

Sometimes it's impossible to fix some bugs because of some legacy things on the C++ side, which at some point will be deprecated and fixed. This is why we still have bugs from many years ago. In the software development world it's not that surprising and certainly not unexpected.

Your impatience although understandable, but unfortunately it's also not helping anyone or anything. And it's not helping either if you spam every single thread with this situation.

 

Did you ever report this? I was hoping it would be fixed by 2019.1.1

 

Why must I open a prefab to change it's name? Example:

1. I have a prefab instance on the scene,
2. I change its name and override the original prefab: the new name doesn't apply,
3. I select the prefab in the project view, change the name there: doesn't work either,
4. I open the prefab, change the name and there the changes holds.

Why is such a trivial operation so complicated to achieve?

 

Maybe ask this in the dedicated Prefab forum, rather than in the 2019.1 announcement thread?
https://forum.unity.com/forums/prefabs.158/

 

It's was a general statement, not a real question. The real question is "why making things so complicated when they could be so simple?".

Now that I know how to proceed, I don't really care.

 

I ended up having the same problem. My fix was to add an assembly definition reference for Unity.Entities to my asmdef. Note, that I didn't have to have this previously. It stopped working recently. I forget what version changes I did.

 

I did report it, I'm pretty sure they are working on it.
The issue is being tracked here https://issuetracker.unity3d.com/is...using-post-process-layer-and-multiple-cameras

Cheers

 

Unfortunately we found that the workaround fix didn't stick in some cases. I may have been when we added scenes or changed cams... I'm not sure exactly why as I didn't have more time to investigate. We have decided to wait until 2019.1.2 now. Thanks again for the attempt - definitely appreciated.

 

Thank you for the update. I'm sorry it didn't work for you.

 

I have the same problem, I created a new project, I didn't import any thing from the Package Manager, the header is still saying that I am using preview packages.

 

Thanks are you able to provide more info on how I can do this?

Screenshot of error:

Just started fresh project and tried Entities V 0.0.12 preview .31 but still failed. Looks like VS having trouble finding other stuff too though.

Any ideas? ¯\_(ツ)_/¯

 

Are you sure preview packages are not installed by default? In the "Advanced" drop down menu, select "show preview packages".

I just remade your Test with 2019.1.1f1 and VS 2019, installed Entities preview 31 0.0.12 and created the same script you did: no problem.

​

 

Just take a look at references to your project in VS, check the library path. If required, you can fix the path yourself by editing csproj file.

Potentially the entities package was not downloaded, or you have an old reference in your project file.

 

Hi,
I got rid of the PREVIEW PACKAGES IN USE header. In the Package Manager, I click "Advanced" and then "Reset Packages to defaults". After that, the header went away. There were some preview packages in the list, but Package Manager didn't show that they were preview packages after I selected "Show preview packages". I think maybe there are some packages that are sill in preview, but Unity forgets to flag them as preview packages.

 

Thank you sir! VS 2019 fixed it!

 

2019.1.2 doesn't show in the hub

 

Just wait a bit.

 

Anyone know what the version of the Android SDK and NDK is downloaded in the HUB? It keeps failing on my end so I want to just download it manually.

 

The best and most important Comment on this post so far. THIS ^

 

I found a scenario where IL2CPP and Mono behaviour diverge in 2019.1.2, but probably going back a lot further. Specifically, Mathf.Approximately looks like it works a bit differently. In practice, this made the difference between locking up my game every once in a blue moon versus always working correctly (as this was used in a while loop). Might be a bit tricky to make a good reproduction project, but I'll give it a shot in the coming days. In any case, I'm mentioning it here in case for whatever reason I'm unable to get to it since it seems like a pretty important thing.

 

But how differently? If I want to build a test case for this what should I look for? Since this is a pretty important thing, I think we have a couple of people who would try to test it out if your claim is true and possible root cause.

 

Specifically, lerping from a float A to a float B while !Mathf.Approximately(A,B) would sometimes never complete. From what I can tell, this has a tendency to be the case when b is near 0. Fortunately though, I've succeeded in making a reproduction project this morning and am uploading it now.

 

The fix in 2019.1.2 looks good - our app is now behaving as expected so we can release. Thanks!

 

got pink shader on particle in hdr tested on 2019.1 and 2019.2
any help please

 

When are you going to update the new editor UI ?

 

I am getting this Issue in Latest Version of Unity
I have only less and greater than contitions in Animator

 

HI there,
I"M LOST too o_0 ok seriously, I have 2019.1.3f1, which I thought was current, tho creating a new project which was recommended for downoading unitys giant Book of the Dead asset, I find I'm seeing errors like this:

Assets/_LocalPackages/botd.com.unity.postprocessing/PostProcessing/Editor/Utils/PostProcessShaderIncludePath.cs(10,10): error CS0619: `UnityEditor.ShaderIncludePathAttribute' is obsolete: `[ShaderIncludePath] attribute is no longer supported. Your shader library must be under the Assets folder or in a package. To include shader headers directly from a package, use #include "Packages/<package name>/<path to your header file>"'

There are more, I think 2 more, but maybe that one is enough to assist.

Also and more importantly maybe, I see on download page, there is only 2019.1 at the top of the list as seen here, released 4/2019, so where did I get my current version ?

what is the 'f' (final ?)

Should I therefore not be using the 'f' version and change to 2019.1 ? Also, from HUB, 2019.1 isnt even listed, are we expected therefore to downlod this newest one from download page and select it from 'locate' ?

TY
so confused o_0

 

I"ve seen that too, and wonder what its meant to be altering.I thought maybe I"d done something wrong given I"m not adept per se yet, in use of all things unity3d.

Usually and preferrably we'd want true, false, running or walking or idle blah...what is this greater/lesser anyway >?

 

Book of the Dead is mentioned "submitted using Unity 2018.2.0." and is probably fully compatible only with this version or the later versions of 2018.

If you want to use it with 2019.1.3f1 (the current final version), you'll have to fix all the problems you get by yourself. This is part of the learning process.

 

Fair enough, but why can't unity keep these valuable ( to beginners at least and prob. others) assets primetime ?

I"m not sure I can fix the errors, my skill level may not be up to this, and I sure can't afford to buy anything given my income range.

Now I have no idea what to even do, should I dump BOD asset in exchange for 2018 , what else may I lose if I do that ?

Confused- again ( frustrated maybe more like it)

 

Buying what?

What you can do is installing 2018.2.0 and then install Book of the Dead to study it, but it you are entirely new to Unity what do you think you're going to learn from it?

There are many ways to learn here and you do not need to pay for them:

• https://learn.unity.com/tutorials
  
• https://learn.unity.com/projects
• https://learn.unity.com/courses

 

If I misspoke sorry, but its not about learning anything, I'm comfortable overall in my knowledge zone.
I wanted to use the assets in my project, are you saying there are no usable assets in bod ? Sure looked like there was.

If I need tutorials, that are free, I know where to find them, but ty just the same I appreciate it.

Also which do I use 2091.1.3f1 or 2019.1 - Is the 'f' literally final version and therefore desirable ?

Not a raw beginner, anymore.

 

You can ask for help here: https://forum.unity.com/threads/book-of-the-dead-environment.536902/

 

Ok ty

 

Is a float a true or false condition or something else,,just wondering bc I see true or false for some items in graph- can't look at working on fixing my unity version given book of dead is causing me major grief- I didn't notice version when I got the free asset on store- its ok nice admin here gave me url for that purpose

ty

 

iOS this method UnityInitApplicationNoGraphics（const *appPathName）. and UnityInitScripting this method always use [NSBundle mainBundle] . not use UnityInitApplicationNoGraphics（xxx) this path.

 

@LeonhardP I have a problem with 2019.1.5f1: it sometimes remains open in the task manager after quitting.

Happens randomly, not worth reporting then, but I think the team needs to know. If you could transmit the message.

 

Posting in the void?

I just installed 2019.1.6f1. All the 2019 versions have the same problem; I waited and waited thinking that somebody would fix it but it didn't happen. So, I'm now trying to draw somebody's attention to it.

It's a small problem but it matters to me. I'm used to resizing my main game view so that it fits tight the resolution I have chosen for my game. Ever since 2019 got out, doing this leaves a dark line at the top of the view. On the mage below, the same dark line should appear at the bottom of the view; as you can see, it doesn't.

​