So I ask you for a unity version (specified version number) that is tested and won't cause me issues in the future, and at least supports the Third Person Character Control Starter Asset.
Some of the versions I tried:
unity 2021.3.3 takes too much time to build (1 hour minimum) especially mobile build, "Your device is weak", I never had this issue with older versions, same project, same assets, takes less time.
unity 2020 and before, many of the assets I need are not supported.
unity 2019 manually setup android build (please kill me) + won't work at the end.
unity 2021.3.16, newly created URP projects by default are bugged with the issue (Burst Compile Error) and I can't add the URP package to an existing project.
You should check release notes from each build at this site if you think an older version will suit you better, you have pre-releases as well on the hub or website but those might cause you trouble in future since they can change substantially until they are official releases.
Although It is strongly recommended that you install a LTS version due to support, go figure.
Each issue you face its either your fault, and you can solve it with a search on the topic, or its a bug and its either been fixed on a later build, pending resolution (there's plenty) or you could create a bug report.
This is not my place entirely since I only use Unity but I hear Godot is light weight and could fit you better.
Related
Very little has changed in a while for BIRT. Since the project seems still heavily used, it would be interesting to know if there are future plans and if so, what is entailed in those plans. Subsequently, based on the development status: Is BIRT still a safe platform to base development on or is it expected to just be conserved in the current state such that occuring bugs probably won't get fixed?
We decided to use BIRT instead of Jasper 8 years ago.
We are still using 4.2.1 for development and 4.3.0 for production runtime.
I reported several bugs since then and only very few of them got fixed.
Furthermore, I developed some patches to enhance the word emitter output - with no reaction from any one at all.
I also developed a patch to allow kind of a vertical tab (to place something at a fix y position on the page (but not in the page footer). With my previous experience of the community, I did not publish that one.
I can say that while the source code is quite easy to read, it is nevertheless almost impossible to understand what is actually going on, because the functions are extremely deeply nested.
My conclusion with 8 years experience of using BIRT for production:
PROS:
BIRT is very powerful and flexible, you can achieve some very cool results.
The quality of the resulting PDFs.
There are only very few things I miss and cannot work around.
The runtime engine is very stable and fast enough, very few problems.
The community is helpful.
CONS:
From an open-source perspective, it is one of the weakest projects I know of.
New versions tend to introduce more bugs than they fix.
Bugs, ideas and patches from the community seem to be ignored most of the time.
Lack of internal code quality and documentation.
Update Dec 2021:
BIRT is back again!
The open source project is quite busy (see answer by Alexander Fedorov) and every help is welcome.
It looks like there will be a new release soon.
Until then, building BIRT yourself (with Eclipse 2021-09 and Java 11) has become quite easy thanks to the common effort of the community.
Metadata and information about the health of an Eclipse project can be found on projects.eclipse.org:
The Birt project is still alive, but not as active as before:
there has been only one release per year since 2016 and
in the last three months there have been more than 20 commits from 11 contributors.
Like all open source projects, the success of the project depends on participation. Therefore, I encourage everybody to report bugs and propose changes to Birt and other open source projects.
Update: Good news, Eclipse Birt has been rebooted. It is under active development again, there have been more than 100 commits in two and a half months and the release 4.9.0 is scheduled for March 16, 2022.
The Eclipse BIRT project has been restarted recently, and we are working to prepare Eclipse BIRT 4.9 release.
Contributors are very welcome. Here is the brief instruction regarding steps how to join this effort: https://eclipse.github.io/birt-website/docs/community
Latest versions of BIRT are not available in maven.
For example: easeljs-NEXT.js
I sense that the NEXT in caps has meaning, but don't know what.
I've tried searching on Bing, for example "what does NEXT mean in a filename".
Also tried a similar search here in stackoverflow with no result.
CreateJS contributor here.
The "NEXT" naming is the file convention we have chosen for the upcoming/in-progress version of CreateJS libraries. Typically, we commit changes/fixes over a period of time, and then eventually tag a new version that gets put on the CDN and (ideally/eventually) included in an updated version of Adobe Animate.
Due to our testing process, and inter-reliance across libraries (Preload, Sound, Easel, Tween), we are pretty conservative when it comes to making official builds. This is our way of making sure there are easy-to-use, compiled builds in GitHub with the latest features, fixes, and documentation. They aren't "official releases", as they might not play well with other content.
Releases:
easeljs.js (with comments and whitepace, good for testing)
easeljs.min.js (minified)
Upcoming/Latest
easeljs-NEXT.js
easeljs-NEXT.min.js
Prior to version 1.0, we used version names:
easeljs-0.6.2.min.js
easeljs-0.6.2.combined.js (the old testing version, not included on CDN)
You can also find "Combined" scripts on the CDN (and other CDNs) that have all 4 libs included. We didn't build NEXT versions of these, since they would be prone to issues:
1.0.0/createjs.js
1.0.0/createjs.min.js
Again, before 1.0, we used a version, which for combined libs was a release date, since they actual version numbers of the libs didn't all align.
createjs-2015.11.26.min.js
createjs-2015.11.26.combined.js
We are working on improving our release schedule, so there are more official releases than in the past. Hope that provides some insight!
I'm using this on an older laptop which for some reason refuses to update to Service Pack 1 so I can't run the latest version of Unity. Right now I'm running an older version and I've tried almost every 2017 version, they all have this problem. All my materials have a kind of red-green-blue rainbow effect. By switching from version to version I've found this one has the least amount of "rainbowing" but it's still doing it. How do I make the materials load normally? Bear in mind, this is using just the default material so it SHOULDN'T be doing this.
Shader rendering is done on the GPU, and you say that you use an old laptop. My guess would be that you need to update the drivers of your graphic card. If this doesn't work, maybe your card is too old to run these shaders.
Go to Edit -> Graphics Emulation
change Shader Hardware Tier to Tier 1 , i think that would solve your problem.
Historically, one of the taboo constructs in Unity3D was the use of c# foreach block because each iteration of the loop would consume a few bytes of data uncessarily.
Curious if that's still the case on modern releases?
My Googling and (very rudimentary) testing is coming up with non-conclusive results and I'd like to leach off of someone else's knowledge here rather than dive into low-level benchmarking myself. :-)
Has anyone poked at this recently to determine if it's still necessary to avoid foreach in Unity3D?
No, foreach is no longer bad in 'modern' unity but the fix is not yet fully released.
It was first fixed on a special build Unity Patch 5.3.5p8 on early July, which you can get from here. This is a special Edition you must get to receive that fix.
Now, Unity upgraded their compiler to Mono 4.4 on Unity 5.5 beta release which is not yet final release. It fixed the foreach problem. Once this version is released in the coming months, foreach memory allocation will be a thing of the past. You can still download for testing purposes but don't release a game with a beta build.
Scripting: Upgrade C# compiler to Mono 4.4. The new compiler still
targets C# 4 and .Net 3.5, but provides better performance and many
bug fixes.
It is now fixed but the fix is still in beta mode.
Ubuntu is usually a cutting edge distro. But why does it stick to a 2011 version of Eclipse when we are 4 years into 4.x development?
It's not even optional and cannot be installed from the repositories. And it's not 'easy' from a download either. For some reason, the Java SE 7 reference implementation, OpenJDK, is not enough, and you need the Oracle version. Why? This isn't available from the repo's either, and you need some weird untrusted 3rd party repo for that or follow a whole chapter on how to install it yourself.
There were problems three years ago. When Juno 4.2 came out, it had a lot of performance issues. Eclipse Director Mike Milinkovich explains one of the reasons is lack of funding. For the first time in a major release:
"The performance test were turned off because the Eclipse platform team has a serious resource issue."
For that reason, developers released unnamed and unpromoted version 3.8 simultaneously with 4.2 to bridge the gap for this (hopefully) temporary problem, and it's popularity caused a notable trend downwards amongst developers. As one Eclipse b3 developer mentioned:
"I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster"
The 3.8 release is still a popular alternative to the 4.x branch among developers (ask my colleagues or google), I think mainly because of (genuine) trust issues. But the bridge (read: support for 3.8) has closed now that 4.3 is released.
The core problems (funding and developers) have not been fixed though, as seen by Google's gesture of donating money to the Eclipse Foundation in the hopes that other companies will follow suit. Does this mean that 4.3 is still not up to par with the 3.x standards?
This is not a problem with a plugin or a feature for a specific language, this is a problem within the core of the platform itself. (But I'm using WST with Javascript and V8 plugins for PHP and Node development in particular.)
This is not a specific platform problem either. There are similar complaints from Linux, Windows, and OSX users. (But I'm using Linux (Mint 13).)
On the one hand you have people telling the EOL for 3.8 "proves" that 4.3 is fine now. On the other hand (see comments):
"I've moved back to 3.8 due to constant crashes on ubuntu with 4.3"
3.8 is far from problem-free and I wouldn't mind to get a smoother development experience. So I am wondering, why is Eclipse 4 'kept from us' by the people who decide what software versions are 'good for us' (AKA what goes into the official repository)?
lucid (10.04 LTS)
Eclipse 3.5.2-2
precise (12.04 LTS)
Eclipse 3.7.2-1
raring (13.04)
Eclipse 3.8.1-1
saucy (13.10)
Eclipse 3.8.1-4
trusty (14.04 LTS)
Eclipse 3.8.1-5.1
utopic (14.10)
Eclipse 3.8.1-5.1
Update 2014-05-30: I just tried Kepler (again) and it still suffers from UI glitches out of the box. E.g.:
And no, changing the inactive window toolbar background color in preferences does not fix this. (Even if it would, this would be a silly default choice).
I would like to know, from someone who is not positively or negatively biased because of their own highly specialized and tweaked workflow - preferably from someone with experience in the Ubuntu package maintaining process for non-trivial packages - why this decision is made by a team of professionals who know what they are doing for the most widely used Linux distribution out there?
Eclipse Juno was released 2012-06-27. On 2012-07-17 a bug concerning the responsiveness of the UI was reported. Four months later, around 2012-11-14 the first patch was released to the official update-site.
Many users, however, completely missed the release of the patches. I assume the information drowned in the FUD, and other more important news, that was spread around that time. At the end of 2012 I posted an answer on SO. Apparently I was not the only one for whom the patch fixed this performance issue.
On 2013-02-22 Eclipse 4.2.2 was released, which contained the same patch, yet I kept receiving upvotes for my answer on SO until June.
Probably the only known fact among developers is that Eclipse had serious performance issues at some point. However, the knowledge about scope, magnitude and duration of these issues seems to me like a series of common misconceptions.
There was a four months period during which it was a good idea for many Eclipse users to stick with the 3.8 branch. I say "many" because I worked with 4.2.0 and 4.2.1 and it was O.K. for me. Subjectively, switching tabs was about two times slower and the IDE froze maybe once a day for a couple of seconds. For colleagues of mine the problem was much more severe. I assume it depended on your setup and on your workflow, however, I never felt like investigating further because I knew the platform developers were working on the issues, and there was a good fallback, using 3.8.
One year and three Eclpse releases later these serious performance issues are still fixed.
Of course, this doesn't mean that there are no more performance issues. As of now I find 1979 reports in the Eclipse bugzilla with the keyword "performance". This doesn't mean that Eclipse is very buggy, but only that it is very well documented and open. Whether or not you are affected by any of these issues, again, depends on the setup, the plug-ins you are using and your workflow. I am a Java, plug-in and EMF developer. I work with medium to big work spaces (~1M LoC), and Eclipse 4.3.1 is fast enough. The 3.8 release is not an option for me because as Eric said, it won't receive all of the important updates. People will still continue using it in the future. Many of them will also continue using Internet Explorer 5.5.
If you try the 4.x branch and notice any performance issues, please report them, but be specific about your setup.
From the official Wiki page:
Several major performance defects have been addressed in Juno SR2
(4.2.2). Community members have confirmed that these fixes
substantially address the performance problems with editor and view
opening, closing, and switching. These fixes are widely available in
Juno Service Release 2 (February 2013). All defects are also resolved
in the Kepler (June 2013) release stream.
new Features
Your statement "3.8 release was specifically released as a faster and more stable alternative to 4.2" is clearly incorrect; 3.x has gone into its 'end of life' maintenance and was most certainly not released as an alternative to 4.x.
While folks are welcome to continue to use the 3.x stream if it suits their needs please recognize that as the various projects move forward there will be significant divergence in the features available between the two versions...