📜 ⬆️ ⬇️

Unity3D tips and tricks 2


After the incredible success of the first part (22 people liked and had as many as 9 comments, 3 of which are mine) - the author (I) decided to write a continuation of the story about exciting adventures in the world of Unity3d.

I tried to pick up fresh chips.

1. Easy Buttons

Hint meaning (briefly): You can add a call to any method from the editor as 1 line. When you select an object in the editor, a button appears with the name of the method; when you click on it, the method is executed.
')
Download, throw in the project, add in the code:

image

We see in the editor:

image

After clicking - the result of the execution:

image

It is very convenient to test effects or quickly trigger events that, according to the logic of the game, have a long wait. Saves time.

The code can be downloaded here .

2. Conditional Hide

Meaning: you can easily hide unnecessary fields. For example, your object only when using homing need to set the parameters of the radius and so on. In other cases, they need to hide (or zadisablit). It is very easy to do.

image

[Header("Auto Aim")] public bool EnableAutoAim = false; [ConditionalHide("EnableAutoAim", true)] public float Range = 0.0f; [ConditionalHide("EnableAutoAim", true)] public bool AimAtClosestTarget = true; [ConditionalHide("EnableAutoAim", true)] public DemoClass ExampleDataClass = new DemoClass(); [ConditionalHide("EnableAutoAim", true)] public AnimationCurve AimOffsetCurve = new AnimationCurve(); 

Now the fields will be shown only if the EnableAutoAim condition is met. You can also not hide, but simply disable fields, as well as use 2 conditions.

Thanks to this guy , you can also download the source code of the attribute.

Stuck very convenient, simplifies the editing process.

Note that the first and second hints work differently (the first overlaps the CustomEditor for all objects, which is not very good in some cases, the second is the CustomPropertyDrawer for its attribute).

3. Screenshots for different permissions with one button

The standard Unity tools for screenshots are pretty dull - it just makes a screenshot of the current resolution. But after all, you need a bunch of screenshots, for different resolutions, different aspect ratios (16: 9, 4: 3, some more), also from some iPad pro with a higher resolution. A fresh example - a couple of weeks ago - it was necessary to:

3.5 Inch (iPhone 4): 640 x 960 px
4 Inch (iPhone 5): 640 x 1136 px
4.7 Inch (iPhone 6): 750 x 1334 px
5.5 Inch (iPhone 6 Plus): 1242 x 2208 px
iPad (9.7 + 7.9 Inch): 2048 x 1536 px
iPad Pro (12.9 Inch): 2732 x 2048

Under the hand of such a zoo, devices usually do not exist. The exit is a simple script - where the texture is created, the camera (or cameras) is rendered there, and saved.

You can take it here . And here is an example of how to remake a lot of cameras.

Now you own the skill of creating screenshots with one button.

4. Submitting LogError to Performance Reporting

Prehistory: there used to be Parse.com service, if an error occurred in the game (not Exception, but something small — for example, there is no sprite for the weapon, or something else), then Debug.LogError () was called in the code. It was intercepted, sent to Parse.com, entered into the database there, if there were a lot of errors - the script would immediately start a bug report so that we would pay attention. But ⊂ (° ʖ̯ °) ⊃ from Facebook bought parse and closed it, breaking off a bunch of people. The program has nowhere to send stories about the troubles that have occurred with it.

There are all sorts of solutions (to send such things to the statistics, to use something else) - but for bike lovers I propose such a solution - send to Performance Reporting (especially since this is the most logical place to watch what errors are in the program).

So, in Unity there is Performance Reporting - but only Exceptions get there. LogError misses. If you create Exception instead of LogError, then yes, the error will be sent and we will see it in Performance Reporting, but the further execution of the script will stop. And there can be especially nothing criminal and you can safely carry it on. If you create an Exception and catch it yourself, then the script does not spill (you catch it), but nothing will be sent to Performance Reporting, and we will not know about it. The solution I propose is to pick up on LogError, when an error is received, create an exception in another class (let it happen), then the error will be sent to Performance Reporting. Actually code:

Code
 using System; using System.Collections; using System.Collections.Generic; using UnityEngine; public class ErrorHandler : MonoBehaviour { public string output = ""; public string stack = ""; void Awake() { DontDestroyOnLoad(gameObject); } void OnEnable() { Application.logMessageReceived += HandleLog; } void OnDisable() { Application.logMessageReceived -= HandleLog; } void HandleLog(string logString, string stackTrace, LogType type) { if (type == LogType.Error) { output = logString; stack = stackTrace; Invoke("ThrowException", 0f); } } public void ThrowException() { throw new Exception(output + "\n" + stack); } } 

Yes, the code is far from ideal and hastily done as a replacement for the Parsi, it seems to cope with its duties. The fact that, with a bunch of errors in a row, theoretically, it might not work quite right - I understand, but in practice this has not happened yet.

On the boot scene, make an object, hang this script on it. He will mark the object so that it is not deleted when loading the scenes, and subscribes to Debug. Upon receipt, the LogError script will create an exception that Unity will send to Performance Reporting. Where you find out about him.

Thanks to those who read to the end. I hope something from the above is useful.

Source: https://habr.com/ru/post/327304/


All Articles