Do you fix warnings?

Like the programming work you do to put food on the table? ¯\_(ツ)_/¯

 

Dude, you aren't getting the warnings because you marked the parent class public, if you switch to internal it will warn with CS0649.

It seems like you wrote a sample using [serializefield] which was a new thing to you, and a private field didn't complain, and suddenly you exploded with joy at the thought of being able to post about it...

I think we're talking from very different levels of competence. You don't seem to understand what I'm talking about in terms of other tools, and it doesn't seem like you really know much about working with Unity. Either you're arguing for the sake of it, or from a lack of competence.

Honestly, you're not even really making a point. You're just saying "not suppressing compiler warnings means bad code" over and over.

Either way I'm done with this one. You can have the last word if you want

 

At the beginning of the project when they are only a few. After a few months and several asset packs later they become too much so I just stop caring. Maybe the devs of those packs will fix them later so there's no point me fixing their code or they won't and an update will just undo my work (if the pack is just art I tend to remove all their code though). Of course, I keep MY code clean.

 

Bingo. Because that's literally all you need.

Code (csharp):

1.  
2. internal class C { public int i; }
3.  

Hey presto, warning CS0649.

Nothing to do with Unity. Nothing to do with [SerializeField]. Nothing to do with exposing private fields to the editor.

(When you make it a private int, the warning becomes CS0169. So you must have a public one.)

This is all just you making your classes internal. Nothing else.

Wait... did I already know this?

I believe you are right.

 

I don't get paid for fixing warning messages from third party projects.. get paid for making something that actually sells.

Now if there was a compiler warning for bracket-less codeblocks I'd be all over that S*** for piss poor code etiquette ie...

Code (CSharp):

1. Omission of braces just because they are not required for single-statement blocks. Like this:
2. if (SomeCondition)
3.     DoSomething();
4.  
5. If you spent enough time staring at code like this
6.  
7. while (SomeCondition)
8.    DoSomething();
9.    DoSomeOtherThing();
10. DoYetAnotherThing();
11.  
12. and wondering "is this a bug or just somebody's sloppy indentation?", then I bet you know what I mean. If you didn't... well, I guess you were just lucky so far. :-)
13.  

being aware of warnings and choosing to suppress the warnings that don't matter to me won't make diddly difference to me, and it won't waste my time fixing a bunch of them from third party assets I happen to use in my project.

 

Yes, if you don't mind using a feature in a way that wasn't intended solely because you decided to be lazy. Just keep in mind that if you mark anything internal it will only be available to that assembly. If I were going to be lazy though I would disable it the way you're supposed to disable individual warnings.

https://msdn.microsoft.com/en-us/library/441722ys.aspx

Code (csharp):

1. #pragma warning disable 0649

 

I'm sorry, but do you not understand that I'm saying this is sloppy code nobody should be writing?

 

Ah. I skipped over the bulk of that "discussion" because it was far too much to read.

 

Oh, trust me, you're not missing much.

 

Would warnings work better if they popped up when you typed the code, ideally with autocorrect?

 

Honestly I'm pretty confused with this post. Do you not understand why people use different visibility levels on classes? Is this like a great reveal of some sort? You sound pretty pleased with yourself.

Honestly, I think you're either a borderline troll or you really have no clue.

 

^ The correct way to do things. Unless still working on a script, the only allowable number of warnings, is zero.

 

Well, I get paid for something that works, and the less time spent the better, so to me fixing my warnings means potentially less time spent later dealing with problems. Actually I very rarely generate warnings in my code except when I've done something wrong, so it's not like I have to spend much time fixing things, it just flows naturally.

 

None of these would generate warnings, though:

Code (CSharp):

1. internal class C
2. {
3.     [SerializeField] public int i;
4. }

Code (CSharp):

1. internal class C
2. {
3.     public int i = 0;
4. }

Code (CSharp):

1. internal class C
2. {
3.     [NonSerialized] public int i;
4. }

 

"the less time spent the better" I can assure you I've spent less time on it

Not sure why you seem to miss the big point that I point out every time .. the point being its not MY code that all those warnings are from... not my code. not my code, not my code, why I choose not to fix those warnings from other authors code has already been stated by myself and others on here with similar reasoning as to why it does not always matter...



not my code

 

I just click on the warning icon on the top right corner of the console pane and let them rot. Kidding, btw, I am having issues because I declared some UI.Texts in the same line like [SerializeField]Text text1,text2,text3; to reference them in the editor and I'm getting those "will always be null" warnings, harmless but I think that I will need to declare them 1 by 1 just because I find warnings annoying as f.

 

Well, it wasn't completely clear to me, since you said you are suppressing some warnings, so that's why I also pointed that I fix my warnings.

My warnings...

My warnings...

 

No. Of course not.

 

not popup, but underlining or highlighting yes. But this would not be unitys problem anyways, and tools like ReSharper already do this, and provide quickfixes as well

 

It's actually a bit more complicated, since different environments will have different warning report settings, etc.

When I compile from visual studio:

Code (csharp):

1. class A {
2.   [SerializeField]
3.   public int B;
4. }
5. ------ Rebuild All started: Project: Assembly-CSharp, Configuration: Debug Any CPU ------
6. ...\Example.cs(11,14): warning CS0649: Field 'A.B' is never assigned to, and will always have its default value 0

This will present a warning in Visual Studio or MonoDevelop, but not from the Unity Console!

Code (csharp):

1. class A {
2.   public int B;
3. }

This guy will trigger a complaint in everywhere, including Unity.

Code (csharp):

1. class A{
2.   private int B;
3. }

No Warning at all! Anywhere! Maybe the compiler generates a const value or something, so it doesn't feel like a warning is worthwhile?

Code (csharp):

1. public class Example {
2.   [SerializeField]
3.   private int B;
4.     private void Print(){
5.         Debug.Log (B);
6.     }
7. }

Mono/VS = Warn. Unity = No Warn

Code (csharp):

1. class Example {
2.   public int B;
3.     private void Print(){
4.         Debug.Log (B);
5.     }
6. }

This will generate a warning everywhere including Unity.

Honestly, warnings are much more arbitrary than we like to think of them as being.

You can obviously go through code and make appropriate tweeks. Sure. But the noise to signal ratio is really bad in the Unity environment.

High quality asset vendors will plop down pragma suppress large classes being exposed to editor. That's a sign that something weird is going on and that there's a problem. TextMeshPro is a good example, obviously, this is a high quality plugin, but he uses pragmas to close warnings all over.

From TextMeshPro:

Code (csharp):

1. #pragma warning disable 0649
2. [SerializeField]
3. private float m_lineLength;

Yep, just pragma disable. 0649 is just annoying as hell in Unity.

Code (csharp):

1. #pragma warning disable 0108
2. public Renderer renderer

^^ yikes - this is intentionally suppressing the fact that this shadows the subclass's method without new.

I honestly have no idea why he isn't using the new keyword here, I've never seen a method intentionally being shadowed without new before.

My guess is that he just became so accustomed to disabling warnings that he just pasted the pragma warning disable here without thinking about it (although honestly, I'm not 100% sure what this will actually do).

This is TextMeshPro, a solid piece of high quality work. Unity is integrating it native.

There's just a lot of friction between Unity and compiler warnings.

 

They will in most good IDEs. Resharper will add various squiggles (like a spell checker) to show different severity or suggestion. I'm not sure if it's available on mac, but I'd bet there is a mac ide that does the same.

 

You seem pretty confused in general. You started out complaining that you get this warning because of [SerializeField], and now you're acting like you knew it's because the class was internal all along.

I am not the one with enough warnings about it to need a special tool that hides them.

I don't care what you think. And calling me names is not going to make you any smarter or any less wrong.

Actually, I still get 169 on the public one and 649 on the nonserialized private, exactly as I would have expected.

But the one where you initialise the variable, yeah, you're right... it doesn't warn that you didn't initialise it. Because you did.

Meanwhile, when you declare the class public, you don't get any of these warnings.

True, and worth mentioning.

Code (csharp):

1. class A{
2.   private int B;
3. }

My gut says it's optimising B out of the class altogether because there are no legal ways it can be accessed. I don't feel like verifying that, so I could be wrong.

EDIT: On reflection, I realised that default access is "internal" so that should pop warning CS0169. I test-built and it indeed does pop 169. I don't know why you didn't get that.

Not really, no. A warning means it looks like you wrote something you didn't actually mean, which could pop up and bite you at some point. In some cases, it's just impossible for something to cause a problem down the line, so you don't get a warning because there's no actual danger to warn you about.

Not both. It is definitely a sign that something weird is going on, but the question is whether you trust the author.

Fundamentally, what the pragma is telling you is "I know that this happens, but I promise it is okay." The question is whether that promise is good enough for you. If it comes from a competent developer you trust, you can nod your head and say "well okay then." If it comes from the summer intern, mmmmmmaybe you look a little closer.

If it's in a project from the asset store, definitely look closer. Any schmuck could have written it. I think I've either thrown away or completely reimplemented something like 80% of the things I got from the asset store that weren't models and artwork. This has, as you might guess, made me pretty gun-shy of anything I have to pay for on there. I don't mind gambling on something free, but when you start asking me to bet $65 and $100 on someone else's code I get a little concerned.

If I remember correctly... and it has been like, fifteen years... the C# language didn't used to use "new" in that context. You used "override" to extend a base or virtual method, and nothing to hide it outright. This was consistent with how C++ worked, so it wasn't considered a problem, but the standard evolved. I'm not sure exactly when it evolved, though. The practice remains legal for hysterical raisins.

I am. It has the same behaviour as explicitly stating "new."

See, no, there's not. Unity doesn't make these warnings happen. Developers make them happen. And it's the developer's job to look at that warning and decide whether he needs to do things differently, which is almost always the case, or just disable the warning.

Consider the lack of "new" on that declaration above. The warning says "are you sure this is what you wanted?" and there are two functionally equivalent ways to say "yes." You can add "new" to the declaration, or you can disable the warning. Me, personally, I would add "new" to the declaration. But there's nothing wrong with just disabling the warning, which is purely informational anyway. "This will do exactly what you want." Yeah, I know, shut up. It works the same either way.

But that friction didn't come from Unity. It came from the developer. If he had written "new" in the first place, he would have gotten no warning. There is absolutely nothing in Unity that made him write the code like he did.

Now, I would agree that the average Unity developer has got a lot of friction when it comes to warnings, because he doesn't know or care how to write good code. He just wants to hack something together that works. And I get that, I really do, but once you hack together something that works you throw it away and write something elegant. You can't write a good solution unless you already know what a working solution looks like. But that initial working solution is a mess.

 

I'm not responding to you. I'm responding to a public conversation about a topic I think is interesting. Your involvement in that conversation is peripheral, and I don't care.

Besides, you already quit the conversation once.

 

Did you reproduce the examples correctly? CS0169 would be for a private variable, and in the example is public. I'd also expect the NonSerialized (which is public, not private) one to give a warning, but it doesn't really for me, what are the details of your setup?

And that is the joke!

 

For the record I deleted my previous (more inflammatory) post.

He may not be seeing these messages because the conditions differ between most compilers and unity's compiler (or at least the versions I'm running).

It's not uncommon to see differences between the conditions for warnings reported through different compilers/environments/commandline args.

As a final note - as a useful point outside of argument. Again, if you have access to a good tool like resharper, this stuff is just all configurable.

It will cover standard compiler warnings


But it also has features for tons of other stuff.



You can just change the severity of whatever conditions you want to whatever you want.

If you believe that preventing "not set and always has default value" is really important, set it to "error" so that it jumps out at you. Set it to "suggestion" if you don't consider it important but you want a little squiggle under it to help you double check.

Warnings are tools to help you write better code, if they aren't doing their job for whatever reason, there are other tools that can do way more.

 

You're right, just copy/pasted and got 649. I must have misspoken, sorry about that.

Well, this weekend, I installed Unity 5.6 with VS2017. I didn't do any real reconfiguration; I like using vanilla configs, because they don't need to be synchronised. I just install the program and use it. If I go to some other machine with a weird config, I reset to defaults with one button and hey presto I know where everything is. I also spent many, many years in QA needing to find and reproduce bugs on fresh installs.

True. I'm using Visual Studio for all of these, and not bouncing back to Unity to see what it says. Basically my reasoning is that if I have to write code to make the warning or error pop, I probably have to write code to make it go away, so I should probably stay in the place where I write code. So when I'm in Unity, I don't really get warnings and errors on compile very often.

I just don't see the value in it. I understand the value of "write code that does not generate a warning." I do not understand the value of "write code that generates warnings, but turn them off so you don't see them." I grok the occasional need to write code that generates a warning, because there is no other way to write it, and set a pragma to turn that warning off. But when the compiler thinks your code looks dodgy, it's usually right, and if you can't make it not look dodgy... well, speaking for myself, that usually means I've got a design problem.

The same thing is true on Unity not acting like I expect. I'd find it very convenient if I could just drop a ParticleSystem on a button and hook the Play() method to the OnClick, but the UI is constantly resizing and moving around and the particle system doesn't. My gut says there is some way for me to script that particle system with the button so it moves when the UI does, but I don't know how, so I've pulled the ParticleSystem and replaced it with an animated sprite. (Which I recorded from the ParticleSystem.)

The key is that instead of putting a kludgy hack into a shipping project, I have pulled the pony and dropped back to something I understand. I can make this happen without warnings, workarounds, or guesswork. The chance of a bug being reported on the animated sprite is virtually zero. The chance of one being reported on some dodgy ParticleSystem hack is really, really high.

It would be easy for me to say Unity is the dodgy one on this, but I know the real problem is that I don't understand the ParticleSystem well enough to make it do what I want. Maybe it can't, but that's just a fact of engineering - if you drop a Maserati engine in a Yugo, you're gonna have a bad time, but you'll have just as bad a time if you drop a Yugo engine in a Maserati. Some things just don't go together.

There's a certain arrogance and self-importance involved when you automatically assume the problem is in the world. I have found that the problem is almost always me, and not the world. Crossing a Yugo and a Maserati doesn't work, but you can't blame the Yugo and you can't blame the Maserati. You sort of have to blame the idiot who wants to cross them.

 

That's it then: Unity won't trigger those warnings, while VS will.

 

The problem here is that I'm not "automatically assuming". I've had a considerable amount of experience with Unity and C# in many other domains as comparison. I think that a lot of the problem here is that you're looking from a very different context, being fairly new to Unity for example. Here's some of my reasoning and context, for reference sake.

It's actually super easy to write code that never produces warnings if you use a modern IDE. You're assuming that the problem I'm talking about is even about writing code. It's not. If you use a good IDE, most warnings border on being auto-corrected.

The problem revolves around third party code, Unity platform updates, Plugins. Managing third party updates and plugins is a real and meaningful issue. Overly simplistic responses "if a plugin has warnings its bad!" - doesn't provide meaningful solutions.

Adding more warning suppression is a bad answer. The fact that so much Unity code requires #pragma indicates a problem. I've never seen a domain where warnings were so common that they required frequent disables. Modifying 3rd party source (even just to add #pragma) is problematic because it increases the burden of updating.

You can measure the friction between Unity and Compiler Warnings.
- Step 1: Count the usage of #pragma disable.
- Step 2: Look at the number of users who have a problem.
- Step 3: Look at stuff like this thread. The fact that there is even a discussion on the subject.

The code itself isn't really the problem, the problem is time. In an ideal world, you can lavish attention on every aspect of a project and every line of code. In practice, time is what actually matters. Depending on your workload, bugs, problems, and imperfections in code all exist. We, as developers, are constantly performing triage. Our ability to be effective is deeply tied to our ability to prioritize.

Prioritizing real problems means less wasted time. It's important to save time for other crap, like arguing with people on the internet about compilation warnings. You know, the really important stuff.

 

That's not about you personally.

Imagine that you have, or indeed anyone at all has, a report that something is wrong. You have tried to do something and it does not work. A tool you use is telling you about it.

The single most common reason is that you did something wrong, and even if it is not, chances are very good that whatever the reason is... you can't change it. You will need to do something yourself that fixes the problem.

Covering it up so you don't see it is not a fix. Covering it up so nobody sees it might be. But ideally, you remove the problem entirely instead of covering it up.

Agreed! And therefore:

Why do you use code from people who can't or won't do something super easy?

Not as bad as leaving customer-facing warnings in your code.

That's not a meaningful measurement. Compiler warnings are themselves a measure of friction between what you wrote and what is conventional. If you're doing anything difficult, you may stray rather far from what is conventional, and that may actually be the best way to do it.

Another primary reason you might suppress rather than address.

Customer confidence and support is a real problem. Warnings reduce confidence, and if you have enough of them, they will begin to generate support tickets and bad reviews.

 

See, this is part of your misconception.

The vast majority of the problems with warnings come from versioning mismatches and freezing updates.
I have an old version of an API that makes checks for Blackberry support. This was deprecated a year or so ago. If I upgrade the API then the warning would probably go away, but upgrading isn't worth it since I heavily customized the source. This kind of thing is a real problem.

Unity themselves led the community in not caring much about warnings.
For years, Standard Assets carried tons of warnings. That practice continues, UnityStandardAssets.CinematicEffects still produces some in the first post beta release. 0649 again.

0649 in general is really annoying, since often, assigning a default value is actually an efficiency loss if the field is guaranteed assignment through unity serialization, since the default value is just automatically moved to garbage.

^^ this just speaks to a lack of exposure. There are so many useful, solid works that have warnings, stuff like UnityStandardAssets.CinematicEffects to say the least. FinalIK still has some, RTP, etc. Many asset vendors are extremely lax in their 'example' projects, most likely to keep them as minimal and simple as possible. FinalIK and RTP are examples of very long term projects, they've gone through years and years of battle testing.


I do agree with you though that asset vendors should remove all warnings, just paste a pragma disable in the header of every file if you want. A lot of them have started just bundling dlls instead of source, which sucks, but that also prevents compilation warnings

• If you are selling code to programmers, then yes, warnings are critical. Presentation counts.

• If you are selling games to players, then focus your attention where it matters.

 

Yeah I see what @frosted is saying. And @cdarklock too.

Generally, I think it is best to resolve warnings with proper updates because they could cause strange behavior to show up at some (often seemingly random) point in time and can be difficult to track down.

However, here in Unity it is very much an amateur hour. And I don't mean that in a way of knocking the good people who create assets, sometimes very impressive assets at that, just saying in my experience it is the rule not the exception that whenever I add an asset from the store my once warning-free project now has warnings and worse even some null references all over.

By amateur hour I mean many of the people creating these assets have probably 1/10th the development experience and skill that you have @cdarklock. People buy them because overall the developers did a great job addressing the problems at hand (i.e. on the Unity game dev side). That doesn't mean they delivered a pristine solution of a professional level you are used to from your career.

Compared to what we are used to professionally (which we have all seen plenty of broken code there as well) it is an amateur hour. That is what i mean. But I want to emphasize... they still deserve respect for actually doing it and perhaps even more so for tackling some projects of a complexity beyond their skills (at least initially). If the people with more experience were providing solutions they wouldn't have had to.

 

I'm mildly obsessive-compulsive. If I didn't fix the warnings, they would drive me crazy. I ALWAYS fix the warnings. I don't consider any project to be complete unless I have a nice, clean console with no red or yellow showing up.

My obsession has actually reached to the point of extending to multiple different versions of Unity. The Asset I'm currently working on is being tested and revised across at least 5 different releases of unity, starting with version 4.3. There are no warnings, in any of those Unity versions. There were, but then I corrected them.

Warnings don't break your software, but they highlight weaknesses that could become major bugs down the line. Better to stamp them out now, rather than have them crop back up and bite you in the butt in the future.

 

It is not a misconception to believe that your shipping product should be maintained in a state of zero warnings during development. It is a standard. If you have lower standards, that is fine, but that doesn't mean I need to lower mine.

You are allowed to have lower standards than me. That's why we're both saying what we think in this thread: so other people, who are not either of us, can decide for themselves where they're going to sit in terms of which warnings they will fix and when. You're not going to change your mind, I'm not going to change mine, and that's totally relaxed and groovy with love, peace, and chicken grease all around.

If you freeze your code, then you are not updating it, and you do not have to worry about fixing the warnings yourself. Nothing is going to wipe out those fixes. Thus, you should make them. It's super easy.

This is just a weird thing to say. I don't let my tools vendors dictate my engineering principles. I dictate the principles of my tools vendors. If their tool doesn't meet my standards, I either fix it or toss it.

Right now, I have nunit warnings I want fixed and it is really annoying that nobody from Unity gives a damn. But since I would rather fix these warnings than dump Unity, I have removed the references to nunit.framework and Unity.TestRunner from the project. (It was super easy.)

I don't think Unity supports anything I'd find useful with that, anyway. I tend to subdivide my problems into small enough pieces that testing them is redundant. Like here's the code that updates my timer status display.

Code (csharp):

1.  
2. void UpdateTimerText()
3. {
4.     System.TimeSpan ts = new System.TimeSpan(0, 0, (int)System.Math.Floor(timerCur - progressBar.value));
5.     timerText.text = ts.ToString();
6. }
7.  

There's literally nothing to test there. It prints the remaining time for the progressBar I'm using as a timer that lasts timerCur seconds. The only thing that can possibly be wrong is if the remaining time is not the length of the timer minus the progressBar's value, which is not a bug that would be in this function - it would be wherever I'm updating those two values. Everything else cannot fail under any normal circumstances. There's no point in unit testing this.

Do you really not understand this?

Here, go look at FirstPersonController.cs and... wtf, Unity, m_LenghtenStep?! Refactoring... you'll see that all the SerializeField attributes are in one block.

As you lock down what the values of these need to be, you should move those values into the code and remove the attribute, because they're only in the editor for convenience while you configure the system. Then they should come out of the editor, so you don't screw them up by mistake. And then the warning goes away. If you follow good engineering principles in your development, that will happen all by itself and you don't have to do anything special.

But the warning tells you that you forgot to do something. It belongs there! You have either not worked out what that value is supposed to be, or you have left that value in the editor instead of moving it to the code, or you have left a final field value exposed to the editor where it can be accidentally overridden. This is what warnings are for.

And if they are there specifically for you to fix them, that's okay. Because you'll fix them. But when you're hiding them and not fixing them because you don't care, that's just horrifying to me.

Yes: delivering bug-free code. Which means clean compiles, at a bare minimum. If the code doesn't make it past the compiler, it certainly shouldn't be making it past you.

I'm actually rather surprised I just needed to explain the concept of warnings existing to be fixed. You don't leave those in your project! What the hell. But it's totally okay for the asset to come out of the box with them. There are patterns of warnings which clearly indicate "I know these are here, but you are the one who has to make them go away, using choices that match your project's needs."

This is mostly because I didn't think enough about the precise nature of the situation to realise that some people might not know this. When you buy a configurable programmer tool or asset, it often can't come with anything approximating a meaningful default in some place or other, and the warning is your alert that something needs to go there. These don't even register as actual warnings to me. And that's my fault, so @frosted - I'm sorry I wasn't clear on that. I should have been.

 

I generally just don't even use the assets. One or two that are very good I do. One still has issues spamming the console but I don't worry about that. It is a creation asset. My time is limited and not going to waste it on fixing issues in someone else's code. Which in many cases would require learning the bulk of someone else's codebase as a prerequisite. It is the way it is. I think most people "just deal with it". Not to mention not all assets include the source to begin with.

But overall the solution I use is just don't use anything other than sound fx, music, graphics. Now yes these often have scripts attached in their demos that have warnings or outright errors but I only want the actual art itself, sound files, etc.

Really @cdarklock if you haven't yet I'd suggest going to the store looking around and downloading a half dozen things and see what you end up with. All I know is that from my experience I expect to see warnings or even errors. Maybe things are better now.

 

I fix them by ticking off the box that displays them in the console at the start of a new project and never turning it back on.

Please hire me Google.

 

Why do Environment trees still add material warnings to the console??

 

If you really think that you can measure quality of code from compiler warnings you're deeply, deeply misguided.

Not everyone needs to resort to dirty hacks when trying to get a button working with some particle effects. The fact that this is too complex a task for you, while you blather on for pages about your vast mastery of Unity workflow borders on insane. As in, like a clinical problem.

 

If you really think that's what I am saying, you're not paying attention.

Using a spritesheet is a dirty hack? Looks to me like it's exactly what you should do when you don't want the overhead of a particle system.

I've only been using Unity for four months. I am no master of Unity workflow. I know very little about Unity specifically.

I have, however, been a professional software developer for twenty-five years. I've largely retired from the actual writing of code, because now I mostly consult and train and do occasional project management, so I picked up Unity because I enjoy writing code and would like to do more of it.

Unity is not special. It is not weird and different and producing friction against the principles of normal software development. It's just being used by people who don't care about those principles, aren't bothering to follow them, and indeed mostly don't even know them.

 

The Dunning–Kruger effect is a cognitive bias in which low-ability individuals suffer from illusory superiority, mistakenly assessing their ability as much higher than it really is. Psychologists David Dunning and Justin Kruger attributed this bias to a metacognitive incapacity, on the part of those with low ability, to recognize their ineptitude and evaluate their competence accurately.

https://en.wikipedia.org/wiki/Dunning–Kruger_effect

 

That's basically a special case of Godwin's law, you know. When you're reduced to claiming Dunning-Kruger, all meaningful discussion has stopped.

 

It stopped a long time ago.

 

I periodically clean up all warnings because usually warnings won't go away and will get to the point where your code begins to break. In short, you can only ignore them for your current version of Unity, sometimes

And warnings in my purchased assets? instantly prevent me from leaving a review. I am not obliged to increase the sales of an asset that doesn't make me happy.

Oh yeah, I don't suppress them, I fix them.

 

So you've been making meaningless posts, then?

 

Yes, I've been reduced to responding to your blather over and over.

 

And whose fault is that?

See, this is the whole thing I'm talking about. The general attitude that when you did a thing, it is someone else's fault you did it and you didn't have a choice.

Yes you did, You could not do it. But you chose to do it, instead, and that was your choice that you made.

If it results in a compiler warning, you should fix it, not suppress or hide it. It doesn't make you a bad person if you don't. It doesn't make me better than you when I do. But there's literally no reason for you to get your panties in a wad over it. You have a choice to make, and you get to make it.

The consequences of your choice are in your project that you have to deal with, so I don't care. The consequences of mine are in my project, so I do care. You don't have to. There's no reason my project or my choices need to matter to you. It's not a competition. Nobody wins and nobody loses. Our projects literally have no involvement with one another.

The only person reducing you to anything is... you. Deciding what you're going to do.

 

I think it's time to go back to working on your game. Also have you played Dawn of War 2? I was surprised to find some metagame elements in it that xcom2 used too.

 

I'll watch some video - anything specific you think is useful?

 

Yeah, there are things like missions that are only available for x number of days and you can grind resources on missions to get more than 1 deployment per day. There are abilities that are boosted by the number of buildings you captured on a certain planet and per mission deployment you can only capture one of the different available buildings, but you'll sometimes come back to the same site to capture the other one. Then there's travel between planets and I think they do a decent job at creating purpose and presenting the threat of the tyranid hive in the metagame representation of the planets. You see these giant swarm clouds descending from space. Overall it feels like a solid place to lift some ideas from for metagame and pacing. I also felt the character ability upgrade system has just the right amount of complexity for this type of game to expand complexity of the core gameplay loop as you progress.
I don't know if it is actually the case because I don't play on a very high difficulty, but the game looks like it might be set up to change the path of the narrative if you lose missions. Even if it isn't it feels clever enough that there is a feeling of how the universe would move on if you fail. Almost doesn't matter if it actually would or if it just loads the last savegame imho.