Important function deprecated. What is the new alternative?

So you basically want the worst of all worlds?
What I'm advocating is a way to have meaningful overlap that promote communication, not that artist become programmer and programmer become artist. Programmer art is useful if it's not the end result, it allow the programmer and the artist to communicate "intents" (here is a city, can you do better? or This is the behavior I want, can you make it run more efficiently?). That's why AAA company have huge emphasis on good tools now and outperforming company like naughty dogs hire T shape people, it bring simple solution to complex problem. Like how the details physics in uncharted 4 are basically faked using the same underlying vertex shader manipulation, from chest hair, to cloth, to plants and car deformation, instead of implementing an actual physics system which would have been costly.

 

Usually, artists I work with tell me what they want, and I tell them how hard it'll be for me to make it and about how long it'll take. I'd never want an artist to try to give me code to tell me what they want. That sounds horrid. I'd immediately tear it apart and start from scratch, unless they were the rare equally talented artist + programmer. The one prophesied to bring balance to the force.

 

But that's the point! they aren't giving you code lol they are giving you a sensible example actually working you look at and deconstruct! Which is much simpler that trying to understand their lingo!

And they might even find new way to do thing that might be simpler than for example implementing physics system for hair! Because that's the problem, the wall of expertise can get in the way of having things works. Uncharted 4 has very convincing hair physics, except it's not physics! I worked on a AAA games in 2008 where we got the complex way of doing it, their system could work on old hardware no problem! If they used the typical workflow, they would have ask for hair physics, the programmer would have say, only one character because that's costly, try, succeed or fail to implement because it would have gone on the budget of other part of the game (like in my experience). There they found a way that was so efficient it end up driving all secondary physics in the entire scene. Not that the basics is not new in itself, just the broad generalization with artist led result and cheap cost. Anyway they have a talk about itat gdc (not the vertex stuff, the interaction with artist and programming).

Anyway as a designer, I had to move to programming because I was often told something wasn't possible, no matter how I explained it, only to prove it was possible because the assumption was misplace. Not because the person is dumb, but because there wasn't an overlap therefore miscommunication shut discussion to the lowest hanging fruits.

 

To close this tech vs art parenthesis

 

SceneUtility.GetBuildIndexByScenePath might work for scenes in assetbundles...I haven't played with it.

Or, you could just make a four line script, put it in the scene, and have it play music. I wouldn't call that a "whole mess" of unnecessary code. If you have a script initializing from within the scene anyway, it's a 1 line addition to that script. You just assign the music through drag-n-drop, or you can do it with an int as you're currently doing if you really want to.

Assigning the music explicitly is better than an implicit assumption that a camera's follow script will know from an int which music to play. When programming, being explicit is always better; implicit assumptions are unreliable, and will bite you in the ass sooner rather than later. Later, your build order might change, and you might forget where to go to fix it. Then you have to go and change a bunch of code around to get your music working right again. Or worse, the new version could accidentally get shipped with the wrong music on the wrong scenes.

If the music is assigned from within the scene, you aren't assuming that something unrelated (the build order) will remain the same, and you can change whatever else you like with relative confidence that your music, at least, won't be affected.

 

I don't think you understand the problems with what you're doing, or why there is a variety of better approaches. Seems like you just want to do things how you want to do them, and that's okay, but you can't expect the engine to stay stuck in the past for your convenience.

 

Just because something didn't improve your experience doesn't mean it isn't an improvement.

New computers don't come with d-sub9 serial ports, despite my need for them on a regular basis. The lack isn't necessarily a detriment, and I have a work around... usb->serial adapter.

And sorry your design of playing music is just prone to flaws. It's why it breaks. Program design should accommodate the fact that code you don't control can change on you. ESPECIALLY if your'e a solo programmer. Depending on unrelated data to control other data is a way to hurt yourself in the long run.

This is why certain things 'obsolete' rather than just disappear. It's to allow designers like yourself to be informed of things changing so that you know to stay on older versions that still 'work for you', and prepare for changes.

I agree with @Dameon_, code should be descriptive. You're not saving much efficiency by using this esoteric logic in your code. This isn't some ZX Spectrum with so little memory this very post I'm writing could barely fit in its available memory.

 

I really don't understand why
SceneUtility.GetBuildIndexByScenePath(scene.path)
is not an acceptable alternative to you.

 

Because you are a hardcore programmer, I said similar thing about art in an art thread, got called out rightfully. Specialist can bitch all the day, other people jut want to get thing done as painfully as possible, purism be damned.

 

No, they don't. You're missing the point. You don't need to know the scene path...scene.path is literally a property on an object of type Scene. It's just a roundabout way to get a build index...probably just returns -1 for assetbundle scenes, though. I haven't tried it on an assetbundle scene, so clearly I know nothing and it's not worth trying.

 

A lot of games are large and the OBB loading method is only truly effective for Google Play. This is where AssetBundle plays a huge role but is not supported by using the new method. It also creates a bit of an unstable environment when you are attempting to load things after the scene and have the "scene has been loaded" flag firing before that is actually true. The new method requires that I perform secondary checks for the content of the scene to make sure that this method claiming is was loaded means it is actually complete in terms of accessibility.

 

Wow, deleted your posts bro...

We weren't expecting justification of your question.

Dameon_ offered up legitimate suggestions on how to resolve your problem.

Multiple suggestions....

You just didn't like the suggestions, thinking your way was better (despite it no longer working, and having a need to rework it). And instead of taking the suggestions, and moving on... not even needing to use them. You felt you had to say that no you need suggestions that look similar to how you already do it, and you wanted the forum to offer up a complete solution. You didn't like that Dameon_ said 'I'm not sure if it'll work in your specific use case'... guess what though, it takes all of a few minutes to TEST it, go try it out. You are a dev afterall... or should we have tested it for you?

Forums are for open discussion, criticisms (not you suck criticisms, just general pointers from people with varying experience), and general help. If you can't handle the middle one, you might not belong in a forum.

I hope you do stay, forums with lots of active members are the best, but you appear to have odd expectations of them.

 

So on a related note, how do I know if a none async additive scene has loaded and all of it's awake() and start() methods have been called?
How do I also do this for async additive loading?

 

The functionality on this function is hideously bad. I wanted my levelEditor to load the main game scene as a sub-scene, so I hooked the sceneLoaded event, and waited for load... But nothing is loaded! How is one scene suppose to know when it's okay to interact with a second scene being loaded without running a wait loop?

A wait loop! I mean... come on.

But that's where I am now. Adding a hook to sceneLoaded.. just to run a wait loop to check if the scene is REALLLLLLY loaded.

 

From my understanding, your problem is that sceneLoaded is called when the scene is loaded (as the name indicates), not when the scene has been activated after loading. You may want to look into activeSceneChanged. https://docs.unity3d.com/ScriptReference/SceneManagement.SceneManager-activeSceneChanged.html
Usually, taking a look at the relevant documentation can give you a world of information. It's always good to RTFM when programming.

 

Yes thank you for that completely condescending, patronizing answer; as if I hadn't already read the documentation for the entire sceneManager...and as if the single tautological sentence they wrote up counted as real documentation.

The ACTIVE scene is the LOADING SCREEN scene and it's going to STAY the loading screen scene until the real level has been completely initialized.

Furthermore, activeScene can't possibly be the correct answer, because the Scene DOES become loaded... the wait loop DOES FIX the issue... which means there is a real event occuring -- scene loaded and ready for interaction.. which has _nothing_ to do with the scene being active.

Not to mention the fact that it's possible to have several scenes in memory, all of which are running their code, but only ONE of which is active. This is true in my case because for example, the ManagerScene, LevelEditorScene and LoadingBarScene are all LOADED, but only one is active.

 

I wasn't trying to be patronizing or condescending, I'm sorry if my response came across that way. Also sorry if I misunderstood your problem, I thought that you were having trouble knowing when a scene has been initialized. Now I am extra confused. I'm not sure what you mean by "ready to interact with" except that the scene has been initialized and become active. I was assuming you were doing a traditional setup of a single scene at a time, but you're talking about additive loading, it appears? In that case, yes, the active scene won't have changed.

So if I'm understanding correctly, your problem is that when loading additively, you have to then wait a frame for that scene to be initialized, but have no event to hook into for when initialization is complete and the scene is loaded AND initialized?

 

Every piece of example code that I've seen that works with additive scenes loaded async looks "hacky" when detecting when the scene has loaded and becomes active. The documentation does little to help with this as has no proper full code examples of how to do this in a "clean" manner. There's snippets here and there that don't work as a whole. The new SceneManager which was supposed to fix some issues in some ways has made things work. Unity really need to take a look at this as it's an extremely common issue.

 

Correct me if I'm wrong, but I think the issue here is the order of events. From my experience, the order of events are:

1) Awake() is triggered on game objects
2) Scene Loaded event is triggered
3) Start() is triggered on game objects

AFAIK, this is not clarified anywhere in the documentation. So for example, if you are initializing parts of your game objects in Start(), then you can't expect those game object to be fully initialized when the scene loaded event is triggered. Is this where the confusion is coming from?

 

It's not always possible to correctly read tone in text, but 'RTFM,' which contains an expletive, tends to sound a little sneering. At any rate it seems this issue might actually be fixed in an upcoming release.

https://issuetracker.unity3d.com/is...8.2034907030.1498669230-1088818653.1498498422

The tracker is talking about being able to use SetActiveScene() but I believe the underlying cause is the same. The scene object isnt considered loaded in the event itself. At any rate I'll stick with my coroutine loop till the next version. If my initial search had been more thorough, I wouldn't have come here to gripe.

 

According to the tracker, it was fixed in 5.6.0 which was released a few months ago.

 

I hadn't played with addititive scene loading before, and I can definitely understand why there'd be a desire for an event for this. Here's a 5-line script for that functionality. I don't consider this very "hacky", but that's my own opinion.

Code (csharp):

1.  
2.     public class NewSceneDetector : MonoBehaviour
3.     {
4.         public static event Action<Scene> SceneActiveHandler = (Scene activatedScene) => { };
5.  
6.         private void Update()
7.         {
8.             SceneActiveHandler.Invoke(gameObject.scene);
9.             Destroy(this);
10.         }
11.     }
12.  

 

Odd, I have 5.5 and it claims to be up to date when I select "Check for updates" but sure enough.. I go online and 5.6 is available! I'm going to try getting the new version and seeing if that doesn't just.. resolve the whole thing...

 

Ah, there's the difference. When I was learning coding, RTFM was just a standard suggestion any time the answer was in the documentation, and there was no real negativity associated with the acronym.

It looks like quite possibly your problem was related to the bug you're referencing. The event was getting called a frame early, which explains what you meant by the scene being "really" loaded, and my confusion while trying to reproduce. I'm using 5.6, and the 2017 beta, and that appears to be fixed in both.

 

I would be curious to find out if that solves his problem. I've certainly had my fair share of frustrations with the scene manager, and I think I speak for a lot of people when I say that it's far from perfect. The lack of basic functionality and actual proper documentation is really surprising.

 

It seems this is something of a 'mia culpa.'

The issue does seem to be fixed in 5.6. I had selected "check for updates" in my local 5.5 version of Unity, but it always told me I was up to date.

Now the SceneManager.sceneLoaded event will give a scene object with "isLoaded=true" and its object list can be searched.

So I may have caused a whole lot of trouble for nothing. If the issue persists for you, try switching to 5.6. My call chain is working as expected here.

I admit that when a simple issue plagues me for more than an hour I have a tendency to forum griping; sometimes justified; sometimes not. But I do always read all the documentation I can find.

 

I'm just getting used to using Unity and "scenes" in general. I'm just getting to grips with it and I start using this OnLevelWasLoaded(){}. Now this function is sooo handy, why the f! is it being removed??

I don't see the point of going through the process of adding a delegate to SceneManager or whatever it is I'm supposed to do, when this function already does the simple tasks I'm needing it to do (ie. I just need to set the players position and a few other things on LevelLoaded because I keep the player object alive dont destroy it on scene change. This is because the UI and inventory system for all of what the player is carrying works nice and easy this way and is all child of Player.

I'm sure I could figure out how to use this delegate thing thanks to the many people online who are happy to help. But really, whats the point? Its like one line of code now, as opposed to a whole script

 

It's literally one line of code more than you're used to:
https://docs.unity3d.com/ScriptReference/SceneManagement.SceneManager-sceneLoaded.html

 

ok thanks. But tbf its not one line. You have to add a new method that isnt part of the UnityEngine (ie. OnSceneLoaded) and you have to increment some function with a variable that isnt explained properly in the attached link.

Please help me understand. What is the variable "OnSceneLoaded" in the code:

using UnityEngine;
using UnityEngine.SceneManagement;

public class ExampleCode : MonoBehaviour
{
// called zero
void Awake()
{
Debug.Log("Awake");
}

// called first
void OnEnable()
{
Debug.Log("OnEnable called");
SceneManager.sceneLoaded += OnSceneLoaded;
}

// called second
void OnSceneLoaded(Scene scene, LoadSceneMode mode)
{
Debug.Log("OnSceneLoaded: " + scene.name);
Debug.Log(mode);
}

// called third
void Start()
{
Debug.Log("Start");
}

// called when the game is terminated
void OnDisable()
{
Debug.Log("OnDisable");
SceneManager.sceneLoaded -= OnSceneLoaded;
}
}


And also, why is SceneManager.sceneLoaded being incremented and then having it subtracted in OnDisable? thank for any help

 

You're not incrementing it, exactly. You could say you're adding to the delegate list. OnSceneLoaded is the method name. You add that method to the delegate list of SceneManager.sceneLoaded.
You remove it when it's disabled, because you wouldn't call the method on a disabled game object/script.
You add it in OnEnable so when the engine executes the delegates in its list, your method will be called

Note: As the docs say, you could name OnSceneLoaded anything you want. That's just a name they chose for the example (you'd have to update the method, and where it's added/removed with the new name, of course)*

 

Actually ignore my last comment. it was wierd, the IDE wasnt coming up with the usual helpful suggestions so i got way more confused. But that was only since i'd copied that script. When I went back to my original scripts and started adding it there, all the stuff in IDE worked again.



Thanks for the extended help btw MUCH APPRECIATED PAL!!!

 

That's strange that you don't see it. It's an event. Has a little lightning symbol beside it in visual studio.
It may be possible to not show events in the auto complete - I'm not sure on that. If that were true, you could have maybe disabled it lol. Anyways, it's there for me, just checked
I wasn't too familiar with the old way, but I know you're not the only one (obviously) confused by this. It's pretty easy, once you know to use it. Anyways, you're welcome for the little extra info and hopefully you have it sorted now

 

Yes i must of loaded something wrong in VS i guess. Very wierd . By the way sadly i got a null reference exception: Wonder if you'd be kind enough to see if you can spot the intentional mistake

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.SceneManagement;

public class GameController : MonoBehaviour {
public static GameController instance;

private PickUp waterBottlePickup;
private GameObject fireObject;
private GameObject playerObject;

private float dialogueTimer = 0f;
public float dialogueHideDelay = 3f;
private bool isInteractionTextHider = false;



private void Awake()
{
instance = this;

}

private void OnEnable()
{
SceneManager.sceneLoaded += OnSceneLoaded;
}

void OnSceneLoaded(Scene scene, LoadSceneMode mode)
{
Debug.Log("OnSceneLoaded: " + scene.buildIndex);
Debug.Log(mode);
switch (scene.buildIndex)
{
case 0:
{
playerObject.transform.position = Constants.level1StartPos; /// GOT NULL EXCEPTION HERE ((
break;
}
case 1:
{
playerObject.transform.position = Constants.level2StartPos;
break;
}
}
}

void Start () {
waterBottlePickup = GameObject.FindGameObjectWithTag(Constants.waterTag).GetComponent<PickUp>();
fireObject = GameObject.FindGameObjectWithTag(Constants.fireObjectTag);
playerObject = GameObject.FindGameObjectWithTag(Constants.playerObjectTag);
}

void Update () {
// Here we will go thru every Interactive Object in the game and set which is the correct item for it. There are several overrides of this method depending on if there is conversation involved, or if there
// are two objects that can interact with it.
// Note also, it returns true when "theyTakeItem" which basically means a success and we have to add the success specific code to happen after with the if block:

// this bool can be used by anything that needs a set delay for hiding the Interaction Object Text panel
// (because if we destroy an item, the triggerExit code never gets called
if (isInteractionTextHider)
{
dialogueTimer += Time.deltaTime;
if (dialogueTimer >= dialogueHideDelay)
{
InfoPanelManager.instance.HideInteractionText();
dialogueTimer = 0;
isInteractionTextHider = false;
}
}

// check troll:
if (DialogueHandler.CheckInteractionIncludeConversations(Constants.trollTag, Constants.appleTag, Constants.troll1stDialogue, Constants.troll2ndDialogue, Constants.trollTakeItem, Constants.trollNotWantItem))
{
waterBottlePickup.isPickupAllowed = true;
}

// check fire with water and bread:
if (DialogueHandler.CheckInteractionTwoItemsAllowed(Constants.fireTag, Constants.waterTag, Constants.breadTag, Constants.fireTakeWater, Constants.fireTakeDummyBread, Constants.nothingHappened))
{
Destroy(fireObject);
isInteractionTextHider = true;
}

}

private void OnDisable()
{
SceneManager.sceneLoaded -= OnSceneLoaded;
}
}

 

error it gave me was this and it was all working fine before i tried to add the level start positions:
NullReferenceException: Object reference not set to an instance of an object
GameController.OnSceneLoaded (Scene scene, LoadSceneMode mode) (at Assets/Scripts/GameController.cs:38)
UnityEngine.SceneManagement.SceneManager.Internal_SceneLoaded (Scene scene, LoadSceneMode mode) (at C:/buildslave/unity/build/artifacts/generated/common/runtime/SceneManagerBindings.gen.cs:245)

 

Dont worry LOL im an idiot! I had null because the playerObject wasnt initialized until the Start() function. Cheers again for all the help . I got rid of my silly warning about deprecated code now

 

Glad ya got it solved. I was about to answer when I realized there were a few more of yours posts answering it for yourself. Good stuff.

 

I hate to beat a dead horse, but can I just say how nice it was to do it the old way? It doesn't matter if you're a programmer or not, the old way had less avenues for user error (happens to everybody) and most importantly, was rock-solid without having to have a 3 page thread discussing what gotchas it had!

I have no problem with Unity adding nice new delegates for things, but this is one of those cases where most users would much prefer the 'magic' of the old method, or at least for the old method to still be an option for ease of use. Even as a programmer myself, I much prefer 'magic' when I know it works 100% of the time and has (virtually) no downsides!

 

I wouldn't say "most" users, I'd say "some" users who don't understand delegates because they haven't properly learned the language they're working with. Also, to be fair, most of the posts in this thread aren't discussing "gotchas", it's people complaining about change. It's a super simple concept, and a way simple change to make. There aren't a million gotchas, it's an event delegate, a basic component of the C# language. Should every event be accompanied by a magic method for convenience and "ease of use"?

 

If they're not easily discoverable in the namespace I say replacing them is for the best. Up with the technocracy, down with the magic-users.

 

That's because some of us entirely given up using and understanding the stuff and use entirely different workflow than having to deal with this obscur things that introduce error before I even start writing code. I have been programming for 10 years and I'm still not leet haxor for anyone, I'm just not a programmer, I have other skills though. It's just wasting my time.

Speak for yourself, I don't have tour brain and you wouldn't agree to a transplant either.

 

My game is MP and everything is based off events, and yes, I do understand delegates, but guess what - I don't have to waste time writing boilerplate code each time I want to call a function after an event, because I use a basic component of the C# language called interfaces.

My criticism is not that Unity changing 'magic' is bad so much as that their replacement is tedious and unnecessary.

 

I'm struggling to understand how much boilerplate code you need for an event subscription. Or is your point that rather than event subscriptions, they should be pursuing the interface system they use for the IPointerHandler stuff?

 

You have to register for the event in Awake, and unregister it in OnDestroy. Yes, it's only a couple of extra lines (or more if you wouldn't otherwise need Awake or OnDestroy in that script). And yes, they are lines and syntax you have to remember and have more opportunity to screw up, compared to the old method. And furthermore yes, it is inconsistent with the several other ways we now have to accomplish very similar things.

All this ground has been well-trodden, and now we're just bickering. Let's stop. The old method is gone, the new method is what it is, and clearly there are them's who like it and them's who don't. Further argument seems unlikely to change hearts or minds on this one.

 

It's our way to cope, men aren't allow to cry

 

Yup, it's not idiot proof. It's power and flexibility over making it idiot proof, and I for one support that. I'd prefer that the power given to me through the language not be limited to the lowest level of programmer, or necessarily even accommodating to them. Events and event registration are part of the language, and used in several other high-level languages, so there is no downside to somebody who is programming having to learn them. Sometimes, programming requires you to actually learn a thing, and occasionally even to put that thing to use. Even if you don't aspire to be a professional programmer, or a good one, you have to at least learn to program, which involves learning a variety of concepts and syntaxes. Or syntaxii?

Consistency would be nice, but I'll take inconsistency over magic methods.

 

After saying that you better also be a good artist, a good designer, a good musician, a good actor and a good writer. Even if you don't aspire to be any of them.

 

Why? I didn't say you have to be a GOOD programmer, just that you have to learn it if you're going to do it. The equivalent would be that you have to learn to draw to try to do art, or you have to learn some music theory to play music. These are true things.

 

The delegate isn't what's in cause anyway, it's the convenience to decouple code from design, which is basically every tools ever made on computer, delegate has nothing to do with a scene conceptually, it's implementation, When I'm thinking design I want to deal with design concept. I want code that express design, not code that express the machine.

The more step, the more error, the more distraction from the main task, they are more problems to think and solve, I know because that's how I'm still bad at programming even though I know all these concepts, they are distraction from the main tasks and require totally different mindset, when I design (or do art), I have to drop programming entirely, else I will burn out from the clutter (also why we generally keep discipline somewhat separated and specialize in one). I admire people who can do both at the same time, that's not me.

And plenty people learn music without knowing anything about music theory, the same is true for drawing. And those people have created master pieces.

 

Not true. Name one "master piece" from a musician who plays an instrument and knows nothing about music theory.

 

Now we're arguing about music theory? Good lord people - drop it already.....