Author Topic: Prefabs as Strings  (Read 572 times)

phil.atha

  • Newbie
  • *
  • Thank You
  • -Given: 3
  • -Receive: 0
  • Posts: 18
    • View Profile
Prefabs as Strings
« on: July 01, 2017, 01:22:01 AM »
Q: What is the reason behind RFC prefabs being passed down as strings rather than object references?

I ask because this makes things somewhat difficult where I have a randomly selected environmental prop instantiate on my world. I have to have a big switch statement that keys off of the name to help find out which Prefab subfolder the object is located in. Not the worst thing in the world but it's forcing me into messy code.

phil.atha

  • Newbie
  • *
  • Thank You
  • -Given: 3
  • -Receive: 0
  • Posts: 18
    • View Profile
Re: Prefabs as Strings
« Reply #1 on: July 01, 2017, 01:25:09 AM »
Not only that but, how to I get the GameObject back to the method that called it so I can continue to work with it? In ExampleCreate.cs I see that ColoredObject returns a GameObject but that doesn't seem to be valuable since TNManger.Instantiate returns void. What am I missing?

cmifwdll

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 149
  • Posts: 285
  • TNet Alchemist
    • View Profile
Re: Prefabs as Strings
« Reply #2 on: July 01, 2017, 05:43:30 AM »
RFC prefabs or RCC prefabs? Your RFCs shouldn't have GameObject as a parameter - you'll end up serializing the entire GameObject over the network and this is very expensive.

For RCCs (and TNManager.Instantiate in general), you pass the path to the prefab as a string. Pass the full path here, including its subfolders.
The reason it's done this way:
1. The old way involved dragging & dropping every prefab you'd want to instantiate onto TNManager. This is obviously tedious and hard to manage for complex projects, but it also kills memory which leads to...
2. When a GameObject is referenced in the scene (eg; a component of yours has a public GameObject prefabToInstantiate field and you drag a prefab onto this component field in the Inspector) then Unity will *always* load that GameObject when the game starts and will never unload it.
The new system uses the path to the resource and loads it using Unity's Resources.Load function. It also then caches the return value for faster subsequent loads.

Your problem with TNManager.Instantiate returning void is common: use the search function for solutions. What I usually do is have a GameManager then for every GameObject I'm interested in I'll have it register itself with the GameManager in its Awake function. You could even add an event to the GameManager that's fired whenever an object registers itself, and then subscribe to this event where ever you need to (though this is likely poor design).

The reason TNManager.Instantiate *has* to return void is because it's a network call... network calls will never be instantaneous. The object will be created when the server processes your request and sends its response (to all players).