[Released] Terra Slicer & S.A.M.

​

S.A.M. - The Streamable Assets Manager
Terra Slicer
Streamable Worlds Bundle

Website | Discord Server | S.A.M. API | Contact Form
SAM Documentation | Terra Slicer Documentation

​

Spoiler: Users of both SAM and Terra Slicer, PLEASE READ

With the movement of the In-Editor Guide info to my website, some code changes were required to the Core DLL. If you have both products int eh same project, it's very important that you update SAM to 1.4.0 or greater and Terra Slicer to 1.2.0 or greater, even if you only need to update one of the products. If you do not do this, you will likely see an error in the console!

Spoiler: Warning! Please Read! Products may be shown as discounted after free purchase

I have had reports from users that after getting Terra Slicer and SAM for free, they show as available for a discount.

This is an Asset Store bug that I have notified the store team about. Please do not purchase Terra Slicer or SAM again in these instances!

If you have not gotten the Assets for free yet, and you believe they should be free (based on being a TS&DLK or SWB owner) but they are showing as not free (but discounted), please contact us!

Hello and welcome! This forum serves as a shared space for Terra Slicer, S.A.M - The Streamable Assets Manager, and the Streamable Worlds Bundles (which includes TS and SAM).

Feel free to post questions or anything else related to these products, or use our website contact form or discord channel!

If you are looking for the Terrain Slicing & Dynamic Loading Kit, don't worry, you're not crazy! That kit has been converted to the Streamable Worlds Bundle. Please read the first two spoiler messages below for more info!


Terra Slicer and S.A.M. Have Arrived!

Spoiler: More Information About The Arrival

Terra Slicer and S.A.M. - The Streamable Assets Manager are now live on the Unity Asset Store! The Terrain Slicing & Dynamic Loading Kit has been converted to the Streamable Worlds Bundle, which includes these two products.

1) If you purchased the TS&DLK in the past, you will now see the Streamable Worlds Bundle in your Asset List - When you add Terra Slicer and/or S.A.M. to your cart, they should show as free.

2) If you purchase the Streamable Worlds Bundle - When you add Terra Slicer and/or S.A.M. to your cart, they should show as free.

2) If you purchase S.A.M. - When you add the SWB to your cart, it should show as costing $30.

3) If you purchase Terra Slicer - When you add the SWB to your cart, it should show as costing $80.

If you purchase both S.A.M. and Terra Slicer individually, you cannot get the discount, so please make sure to get the other products (when you have one) by purchasing the Bundle instead.

Spoiler: Redeeming Terra Slicer & S.A.M - For purchasers of the TS&DLK or the Streamable Worlds Bundle

If you purchase or have purchased the Streamable Worlds Bundle, or purchased the TS&DLK in the past, please follow these steps to gain access to Terra Slicer and S.A.M.

1. Navigate to each products asset store page using the links at the top of this post.
2. Add each product to your cart.
3. Checkout - Each product should show as 0$
4. Download each product separately.
5. Note, after steps 1-4, the products may show as available for a discounted price (as if you never purchased them). This is an Asset Store Bug. Do not purchase the products unless it is for free!

Spoiler: Support

Use Our Website Contact Form: https://deepspacelabs.net/html/other/contact.php

Or post here/use Discord (link above)

If you have emailed us and we have not gotten back to you after a full day, please send us another email, post on these forums, or on discord. Chances are the email was lost somehow!

If you are seeking support for an error, please check the "Known Issues" spoiler below this one to see if the error has already been reported. If it hasn't, when you contact support please include:

1. Screenshots or Descriptions of Errors.
2. Steps to reproduce the error (if possible).
3. Screenshots of the settings from components/assets that you think are related to the error (Streamable Grid, Slicer asset, etc.)
4. Your invoice number and which product you purchased (if it's the bundle or TS&DLK, let me know).
5. Which version of Unity you are using

This will help speed up the support process.

Please remember that both Terra Slicer and SAM include abundant inspector tooltips (settings with * in their name) and comprehensive In-Editor Guides. If you have a question, the fastest way you will find an answer is by using these resources rather than seeking support from us. If you can't find what you're looking for, let us know!

Spoiler: Known Issues (Unresolved)

• You may see this console error: Burst internal compiler error: Burst.Compiler.IL.CompilerException: Error while verifying module: DISubprogram attached to more than one function - I have logged a bug report with Unity on this and am waiting to hear back.

Spoiler: Known Issues (Resolved)

• A MissingReferenceException may be thrown when using the Standard Hierarchy Organizer and hierarchy pooling (setting found on the World)(Fixed in 1.3.2).
• The About SAM asset may list the version as 1.2.0 and the Last Updated date may be wrong. Check the Package Manager to confirm the actual version of SAM you are using (Fixed in 1.3.2).
• There is a bug with the Scene Chunk Streamer resulting in correctly added Build Setting scenes not being detected properly (most likely results from spaces being present in the Group Name of your LOD Group) (Fixed in 1.3.1).
• There are some bugs with the Default Asset Creator when creating both Prefabs and Scenes with the same Creator (Fixed in 1.3.0).
• An ObjectDisposeException appears after entering Play Mode 2+ times, but only when the Reload Domain setting is disabled (in Project Settings/Editor) (Fixed in 1.3.0).
• You may see Native Collection Leak errors both in the editor and Play Mode (Hopefully all have been in 1.3.0).
• Some active tabs in Inspectors and Editor Windows may appear as inactive (Fixed in 1.3.0).
• A NullReferenceException is thrown when using the SAMInitializer's InitializeSAM_Gradual method without a SAMSlider or SAMText object assigned (Fixed in 1.2.0).
• A Compilation Error appears in Unity 2020.3 and 2021.1 if the Addressables Package is not present in your project (Fixed in 1.2.0).
• There is a bug in the ScaleTransitioner component that makes it not work correctly with the World Designer Tool (Fixed in 1.2.0).
• When using Unity's Light Editor Theme, the Main Controls Window of the Loading Blueprint Editor and World Designer Tool makes use of a dark background rather than a light one (Fixed in 1.1.0).

Spoiler: Important Notice about Compatible Unity Versions

We have tested both Terra Slicer and S.A.M. from versions between Unity 2020.3.37f1 and 2022.3.0f1 (but all LTS versions should work).

No testing has been done on 2023 versions yet and you purchase at your own risk for these versions!

Spoiler: Looking For More Information About The Products?

Please use the Asset Store Page Links at the top of the post to find out detailed information about each product!

 

I've found a couple of issues when working with terrain that use up a lot of memory (large groups and/or high resolution terrains). Unity currently has a 2GB limit, which I unfortunately forgot to take into account in a couple of places, like when using the prefab tool and when calculating world grid data. I have already fixed the world grid data calculation issue, and am going to try and do a thorough sweep of any code that might produce problems.

If anyone wants these fixes early, email me with your invoice number and I'll get you the updated files.

At this time, there is still an issue where trying to build projects can cause out of memory errors. Not sure if this relates to the resources folder being too big, or project size, but I'm looking into ways around the issue. It's possible using scene loading will avert this problem; that's something to add to the testing plate for this week.

Again, all of this should only be a problem when using many high resolution terrains. Of course, one of the reasons I created the dynamic loading kit was to reduce the memory footprint during runtime (success) and make creating large high resolution worlds possible (still within sight, but currently a no go), so I am not happy with these issues.

 

Good news! Using Scenes does indeed get around the 2GB memory limit of Unity. I just got done testing a world made up of 64 2049x2049 (1km x 1km) terrains. The only thing you need to make sure of is to rename your Resources folder (_Resources, for example) so that Unity doesn't load the assets stored in it.

I withheld from adding a Scene loading method for Unity Indie users (using LoadLevelAdditive) because I felt it was kind of pointless. I figured it would be doing the same thing as the Prefab Instantiator. However, seeing as how using scenes (or asset bundles) is the only way to get around the 2GB limit, I will be adding a new loader immediately that utilized the LoadLevelAdditive method.

More updates to come.

Edit: Seems this was a case of premature jubilation. Although I am able to play the scene when using 64 2049x2049 terrains and the scene loader component, I cannot actually build the project. I am investigating this issue (which goes back to 2010), and actively searching for a solution.

Edit 2: Turns out my folder with all my prefabs got renamed to Resources and I didn't realize, and that is why the build was failing. I am not sure if there is a limit to the build size when using scenes, since scenes are generated as separate assets. I am going to conduct some test, but for the time being, it looks like large high resolution world are in fact possible!

 

Looks like there's a bug in Unity 4.3. The kit worked fine in 4.2, but as soon as I updated the project to 4.3 it started crashing. I've submitted a bug report, but for the time being it looks like you'll have to keep your project at 4.2 if you want to use this kit .

Update: The crash only occurs when destroying objects, so a temporary workaround is to use the pooling primary sub controller component rather than the non-pooling one. Keep in mind, however, that this component keeps the objects in memory for the duration of the program (or scene), so if using objects that take up a lot of memory this method shouldn't be used (though you're free to try it if you wish).

Update 2: The crash only occurs when trying to destroy a GameObject that has a Terrain Component (aka a Unity Terrain), so if you're not using a Terrain, you should be okay. Please let me know if anyone else is experiencing crashing!

 

Good news; I think I have identified the root cause of the crash and believe I can work around the problem. More info to come . . .

 

I am happy to report that the issue has been identified and fixed, and will be available in the next update (which should hopefully hit the Asset Store sometime next week). Here is a taste of some of the fixes/improvements in that update.

1. Fixed crash when destroying Terrains in Unity 4.3. It should be safe to update now!

2. The CreatePrefabs tool, Scene Generation Tool, and Calculate Data button on the World Grid ScriptableObject should no longer cause Out of Memory errors when working with objects/terrains that use up a lot of memory.

3. Added a new cell object Scene Loader component type: this component is a non-asynchronous loader that can be used by Unity Indie users. Scene Loading is necessary when dealing with object groups that utilize a lot of memory, as loading Resources causes an out of memory errors due to a 2GB (3.5?) limit on the Unity Editor. In order to create this new type, a new base abstract class was created, and much of the logic from the Async Scene Loader component was moved to this base class. SceneLoader and AsyncSceneLoader derive from this new class (BaseSceneLoader).
4. Fixed a potential bug with the SliceTerrain tool.

5. Added an error dialog to the GenerateScenesTool that pops up if the user did not select a tag for the Unbound Tag Name field.

6. Changes to some tool tips.

7. It is no longer possible to initiate an active grid shift or move if a shift or move is currently in the process of executing. The ControllerCurrentlyExecuting property will tell you if a shift or move is currently in the process of executing. The ShiftActiveGrid method of the DynamicLoadingController class also now returns false if the shift could not be executed, or true if it could.

Note: execution of the shift happens over several frames, so when the ShiftActiveGrid method returns true, the shift has not been completed yet. When the shift is completed, the ActiveGridShift event will fire, but be advised, this event must be fully processed (subscribers must all return control to dynamic loading controller) before another shift can be initiated.

8. The BoundaryMonitor class was changed so it does not stop monitoring when it detects a boundary has been crossed. Keep in mind, however, the dynamic loading controller will stop the monitor while it is performing a grid shift/move. When it’s done, it starts the monitor. This change is only noteworthy if you’re using the Boundary Monitor for some different use outside of the Dynamic Loading Kit.

9. Small improvements to existing code in various places.

 

Interesting. How do you feel about performance, with terrains that are just terrains (not full of trees/grass)? Specifically, when loading/unloading terrains, any noticeable hitches or fps spikes?

Something that would go hand in hand with this (almost a necessity) is being able to specify low terrain detail for distant terrains, and also have something that stitches the borders between distant and near terrains. Any thoughts on this?

 

It's hard to say what kind of performance you'll get, since it depends largely on the terrain you're using. If it's any indication, I have run some test on the world in the Island Demo and performance has been really good (this was a while ago, I need to re run the test since I've redone a lot of stuff). I am also always open to taking people's world and running test to see how well they perform using my kit, but of course, those test would not be accurate since my system is different than everyone else (for better or for worse). I'm also in the process of using World Machine to generate large worlds full of high detailed terrain, so I'll be able to run more substantial performance test.

I've tried to limit the performance hit of my own code by spreading the load across frames, although there might be additional things I can do. And of course if using Unity Pro the Async Scene Loader should perform better than non-async scene loading or prefab instantiation. In practice, the AsyncLoadLevelAdditive is not as good as it should be. The docs state that using this method should allow you to load levels with no impact on performance, but this is not the case in reality. Hopefully that can be rectified by Unity in the future, but I doubt it, since I don't see a lot of clamoring for it.

As for a sort of level of detail system, that's something I definitely want to add. To be honest I haven't done any research on that aspect, however, so I can't speak on the challenges associated with it. Your point about the borders needing to be adjusted is a good one. Stitching the terrains during run-time shouldn't be a problem.

 

The update has been submitted. As always, you can get it straight from me if you email my your invoice number.

Here's a couple more changes:

10. Small improvements to existing code in various places. Also changed the return types of many methods to IEnumerable<YieldInstruction> (from IEnumerator), in order to remove various StartCoroutine calls. There is now only one StartCoroutine call for each load cycle. This change reduces some garbage generation.

11. Updated Undo system in Blend Edges and Tileable Terrain Maker tools for 4.3 users. Alphamap undoing is still not working, so I am still using my own system.

12. GameStateObjectSwitcher was placed in wrong folder before and has since been moved, so you may have a duplicate file error after updating the package from the Asset Store. Delete the .cs file that is located in DynamicLoadingKit_SourceCode if this is the case.

Next I will be focusing on documentation.

 

I just began working on a comprehensive document that should help you understand and use the dynamic loading kit. Currently it is incomplete and limited, however I will be updating it daily and it should be completed soon. You can download it (and future versions) from my website.

Link

 

Hi ! this ratter Seams a very interesting and very UNIQUE solution ...

Thanks for the Updates / And mproving this SLicing Kit to Dynamic loading ...

----

I read the Full PDF guide : http://deepspacelabs.net/files/Dynamic Loading Kit_Full_Guide.pdf

And I like the Grid / cells / Method ...

The Dynamic Loading Kit utilizes a grid based system, where each cell in the
grid is identified by a row and column number. At any given time, a number
of cells are “active,” which means the objects associated with those cells are
loaded into the scene or enabled. This active grid can move up, down, right,
or left, and doing so activates cells (in the direction of the move) and
deactivates cells (in the opposite direction).​

SO as far as i understanded We must :

1) Setup a World Grid ... Were Each Terrain Will be loaded ?

​

Ok ...So Some Questions :

1) How far Can we go with this Dynamic Loading kit ?
How Far can we push The Grids ?
- Can we Have a World grid.. lets say like 60 Per 60 rows ?

2) Is this made just for First person / races ? X/Z Loading
For example In a case of a ScyFy Flying / With Landing Game ...
Can We Have a Full Cubic X/Y/Z Grid With Dynamic Loading Also ?

3) Is it Possible ( in the case of a fly game ) to have LODs Substitutions in the distance of Distant cells in the grid ?
- This that we can See in the far distance the Other grids content... but Then be Swapped by LODs version according Fly Distance ..
- - My idea is to have In the Grid LODS Replacements untill Once The Player crosses the Grid "full level load" boundary..
- - - This could Should be made in the Editor So we Save load from disck new cells content - but also specify a LOD Replacement a series of Prefabs 1-4 Geometry Lod Prefabs of the Entire Cell that will Load in the distance being the Level 5 a simple Large Bilboard

4) Could be possible further in thsi development the Loading of Individual "Cubic grids inside each others" ?
- A friend mine posted here about that Cubic Grid Cubes Areas inside Areas on triggers concept : http://goo.gl/2OqpyK

5) And About the "GRID CELLS" 1 grid Cell must be Tight Down to 1 Terrain Cell ?
- Can we for example have many terrains inside 1 Cell in the grid instead ?

6) Can we with this sistem go over Unity 32Bits Editor Memory limits ? How does the Editor Workflow Works ?
... Can we for example Select a Cell in the grid / and Save / load and Unload That cell from Editor ?
- Loading that Cell In the editor and runtime will load also All Objects Contained in that Cubic Cell Space Right ?

7) How about the Loading Trigger System ? Can that Allow to have More grids inside Grids ?

8 ) Do you have a Roadmap ?
What are your plans for this Amazing extension in the near future ?

Sorry for the Overload of subjects ...
But im reaaly interested in make this kind of Better Game Dynamic Loading Management system be possible in unity...
ANd from all the many developers in all unity you are surely the most advanced in your methods to make all this possible from this sistem so far - My sincere congratulations for that !

I think this Product Needs more Bumping and Awareness, as this is one of the most needed features for big Levels
Thanks so Deeply much for your Development. Keep Going !


Wishes of a happy Holidays and Most Prosperous new Year.


Best Regards !

 

Hey Triax employee , thanks for your interest!

Let's tackle your questions.

There should be no limit to the number of rows and columns you have in your grid. Unity does have some memory limitations, where if your terrains in your scene take up too much memory, Unity will crash. This means when creating your world you will have to be careful, and you will have to use one of the Scene Loading components when using the Dynamic Loading Kit (rather than the prefab instantiation component).

However, the World Grid asset doesn't require terrains to be in the scene in order for its data to be calculated; the terrains only have to be stored as prefabs in the Resources folder. The data calculation method has been optimized to free memory after each prefab is processed, so theoretically it should be able to process an infinite number of terrains (or other objects). Again, you'll want to use a Scene Loading component, so once the data for the world grid has been calculated and you've created the scenes (using the Scene Generation Tool), you'll want to rename your Resources folder to something else so Unity doesn't try to load it when building your game.

Unfortunately it is only designed to work on a 2-dimensional grid at this time. Honestly I never really thought about doing a full cubic grid; I will look into that and see how much work it will take. I have some other stuff to finish first though, so it'll probably be at least two months down the road before it would be added.

Keep in mind also, though the kit only works on a 2D grid, you can use it both of the X-Z plane and X-Y plane, which means you can use it when making a 2D side scrolling game.

A LOD system is something I have thought about and definitely want to implement. One hurdle another user brought up is making sure the borders of the lower resolution terrains match up with the borders of higher resolution terrains. Another issue I can foresee is in the transitioning from a lower resolution object to a higher resolution object. My plan is to introduce some kind of user defined component that controls the transitioning, but I am not sure how feasible that is. Other than those two issues, I don't believe a LOD system should be very hard to implement.

I read through about half of that post, and wow; there are some very interesting ideas there to say the least! Unfortunately, while the cubic grid idea you mentioned before definitely sounds doable, I am not sure I could incorporate the ideas from that post with my kit. I believe it would involve rewriting a ton of my own code, to the point where it would be a separate project. If you wanted to try and implement it yourself, I would be happy to share my experience working with dynamic loading and help out in any way I can!

Yes you could, but I am not sure if you'd want to. You have complete control over the load dimensions. Take a look at Chapter 1, Section 2 in the full guide document (if you don't see this section, download the newest version from my website!). Basically you can control how many terrains/objects are loaded at any given time, so there's nothing stopping you from having 25 grid cell locations loaded, or 36, or whatever you want (game performance and memory usage being the only limiting factors). If you did want to implement multiple terrains in a single cell, it will take some work.

1) Create an empty game object, then make all the terrains you want in a single cell children of this game object. This object will serve as the main cell object associated with the cell, and when it's loaded/destroyed the child terrains will be loaded/destroyed.

2) The World Grid will not be able to calculate the dimensions for the grid cells, since the parent game object has no dimensions. You will need to work out the dimensions for each cell yourself, and create a .txt (or other TextAsset) with the necessary data (see example.txt in the asset package or the full guide for details).

3) This will ensure the terrains are loaded correctly, but unfortunately the terrain neighboring will not be handled by the dynamic loading kit. You'd have to do this yourself, which might be a bit of a pain.

If you can make an argument for why this functionality would be useful, I will be happy to try to implement it myself.

Yes, you should be able to go over the Editor memory limits, but it requires that you make use of scenes (or Asset Bundles, which will be added later and only available to Pro users). I say "should" because I have performed test on terrains that use a ton of memory and have had no problems with building my sample project, but there is always the possibility that I may have missed something. If for some reason you do get editor memory crashes when using my kit, and you are taking the correct steps (using scenes), and we cannot find a solution, I will be happy to offer a full refund as long as an invoice number is provided. I am confident you will not experience any problems.

As for loading cells in the grid, there is functionality on one of the components that allows you to load the entire grid, but obviously that is not a viable option when dealing with terrains that eat up large chunks of memory, as you will get editor memory errors if loading every cell. If you have not yet created scenes for your cell objects, you can simply drag the prefab for whatever cell you want to load into the editor; you'll just have to make sure to apply changes you make. This is not ideal, since the prefabs will not be positioned correctly when dragging them into the editor.

I will probably change the grid loading functionality mentioned previously so that instead of loading every grid cell, you can specify a range of cells (you'd specify a row/column and then the number of rows/columns you want to load, so for instance if you wanted to load the first two cells on row 1, and the first two cells on row 2, you'd specify row 1/column 1 and 2 rows/2 columns.

Finally, if you have already created scenes out of your prefabs, you can just open the scenes to edit the terrains/other objects in that scene (and just save the scene when you're done editing). Obviously with this method you can only view one grid cell at a time, so it may not be ideal.

I have rethought the triggering system and I don't think that's something I am going to add, the reason being that it is really completely separate functionality from what my kit offers. There is no way to merge a triggering system with the dynamic loading so they both can function at the same time (no way that I can see at least), so there is really no point to implement it.

If you did want a triggering system, I don't believe it would be hard to do. You'd just have a script on a game object with a collider that has a public variable where you drag the object you want to load when the collider is crossed. When the collider is crossed the appropriate trigger or collider method will fire and in that method you'd load the object. If using terrains you'd have to do some terrain neighboring, but that wouldn't be too difficult.

Right now I am working on completing the documentation/video tutorials/etc.

After that, I will probably create a video or two that details the benefits of using the kit (mainly the memory usage benefit). I might also create a Demo.

As far as adding functionality to the kit, the next addition will be adding the Asset Bundle Cell Object Loader component for Pro users. I don't think this will take much time, but I will need to do some research on Asset Bundles since I've never used them before. After that, I plan on adding a more sophisticated partial pooling primary cell object sub controller component. Once those two components are complete, I will begin work on the LOD system, as well as any additional changes I think up or others request.

The full guide is my number one priority, and is being updated daily. I really want to get this done, especially the parts detailing how to create your own components. From the beginning I knew creating a comprehensive dynamic loading solution would be impossible, so I tried to make adding your own functionality as easy as possible. While things like the 3D grid you mentioned previously will need to be added by myself, this customization should allow for better integration with individual projects, and should also give the kit a better chance at being future proof. For instance, down the line Unity may introduce a new way to load objects into the scene, and you may want to use that method with the dynamic loading kit. Because of the component based nature of my kit, as well as the easy customization (well, it will be easy once the documentation is complete ), adding a new loading method is relatively painless!

Thank you for those kind words! I completely agree about the bumping and awareness; I will definitely ramp up my own efforts in that department once I get some more of the documentation/video tutorials/etc. completed. In the mean time, anything users can do (reviews here and on the asset store) is much appreciated and goes a long way to helping me out!

 

The package has been updated and the current version is 1.52. This is minor update, with the following two changes.

1) When setting the data on a world grid asset for an object of type “Other_No_Renderer”,
you can now simply drag the Text Asset that holds the required data onto the appropriate
field, rather than typing the path where this file is stored.

2) Changed ShiftActiveGrid’s return type from void to bool. The returned bool return true
if a grid shift was initiated, or false if a shift was not initiated (if the grid was locked
or the input directionToShiftGrid was None).

If those changes are of interest to you, feel free to update. If not, you hold off until the next update.

 

WHOW ! AAAMAZING !! You got here a Real Amazing product Done and Even more to become ...
this Product Power Is even better than what i was expected ...

And man ! Finaly someone that can Write As much as me About this subjects ...
I just Love Passionate people about is work as you Big Friend !
​

Thanks so much for the Long Explanations / And Im Extremely Sorry for mess up with your Development time ...

Hope my Input helps Debug Your product in What it is and will be also for other Potential Customers...
I think this extension power is reaaly unknown, and people are not seeing what this can do actually .

In a Short Resume i would say its the Same as bringing the Exclusive power of HeroEngine Seamless 2 levels into unity you know :
http://hewiki.heroengine.com/wiki/Seamless_World_2.0
http://hewiki.heroengine.com/wiki/Seamless_world
http://hewiki.heroengine.com/wiki/Seamless_area_link

Less technical people im sure cannot grasp the real power of seamless Dynamic Level loading ...

THANKS FOR YOUR AMAZING SUPPORT !

Im completely Sold out At this point ! Soo...

YOU GOT HERE A NEW CUSTOMER ...
And hope many more Follow Up my Enthusiasm !!

Gona try to buy this Extension before new year !
( As right now im dealing wth late cristmas Gifts and preparations and stuff ) ; )

This Development reaaly Deserves All Support one can make and should have !

THANKS FOR EVERYTHING ! In this product Development support ...
Keep Improving it please ! I will be back ..

Happy Holydays !!


TRIAX STUDIO Team Admin

 

Wow, thank you so much for the support! I hope you are as happy with the product once you purchase it .

As for those links, I don't have experience with HeroEngine, so I'm not familiar with their Seamless linking technology, but from what I gather, you are correct that my kit can be used to implement similar functionality. Even though my kit works by loading entire rows/columns of cells (not the whole world grid, just however many cells are defined by the active grid dimensions), there's nothing stopping you from only having one cell contain a terrain/other game object, and the other cells on the row/column being empty. The single non-empty cell could act as a corridor where the adjacent level is loaded, much like the seamless linking technology does.

The only limitation at this time is Unity's loading methods. While LoadLevelAdditiveAsync is the fastest method and does a good job loading assets in a background thread, the actual moment when the assets are completely loaded still incurs a performance penalty. I have to think by Unity'd wording in their documentation for this method that this performance penalty is unintentional. The relevant quote:

"This allows you to create a completely streaming world where you constantly load and unload different parts of the world based on the player position, without any hiccups in game play."

I am going to start a thread on this matter in the hopes of find out if this method is performing as intended, and if not, hopefully bring it to Unity's attention so they can fix it.

Sorry, went on a bit of a tangent there. Thanks again for the kind words!

 

Just submitted another update to the Store which should be available in about a week. The main feature of this update is the ability to define either the horizontal axis as endless, vertical axis as endless, or both axes as endless. Previously there was just a single option that when checked, made both axes endless.

This new functionality is especially useful for endless runner type games, where you might just want your terrain or game world to run endlessly in a single direction.

Here's the full change log.

1) Changed the endless world functionality. Previously, checking the "Endless World" option on the Dynamic Loading Configuration Form would make the world endless on both the horizontal and vertical axes, which may not be desired behaviour. This option has been replaced by two new options, "Endless Horizontal Axis," and "Endless Vertical Axis." Checking both options will produce the same effect as the previous single option, or you can check only one or the other to make the world endless on that axis. This is especially useful for endless runner type games, where you have a single terrain/tile piece which you wish to extend endlessly in one direction.

2) World Grid Asset Creation has been improved. Instead of being created in a default folder, the world grids are created in whatever folder you have selected. The folder must be actively selected for this to work (blue highlight - if the folder has a light grey highlight it will not work). Alternatively, you can right click a folder or inside a folder and choose "Dynamic Loading Kit/Create World Grid."

3) New Property added to The Dynamic Loading Controller component. This propery (called ShiftInProgress) will tell you the Direction of the current active grid shift in progress. It will return Direction.None if no shift is in progress.

4) New option called "Destroy After Starts" added to the Dynamic Loading Configuration Form. This option, when checked, will tell the form component to destroy itself after all Start Methods have been called. Useful if you want to free some memory. This should only be used if you are prepared to retrieve the Dynamic Loading Controller component(if needed) using the GetComponent method.

5) Added Word and PDF versions of the Dyanmic Loading Kit Full Guide document. This is a work in progress and is constantly being updated. New versions will be included in future updates, or in the mean time you can go to http://deepspacelabs.net/files/Dynamic Loading Kit_Full_Guide.pdf.

 

The update described in the previous post is now live on the asset store!

 

Hello all,

I wanted to take some time to talk about what I'm currently working on, and to also (hopefully) get a little feedback on some planned improvements. I'm going under the assumption that anyone reading this has some knowledge with how my kit works. If you don't, you probably won't understand this, but feel free to ask questions and I will explain.

The main component that drives my kit is the Dynamic Loading Controller; if you want to manually shift the active world in a certain direction or move it, you do so by calling the appropriate method on this component (let's call these commands). Or if you're using a Boundary Monitor component, when the player crosses a specific boundary, a signal is sent to the controller and the appropriate shift command is initiated.

It's important to note that the actual shifting and moving actions generally occur over several frames, which helps spread the performance impact in order to avoid massive game hiccups. Currently, when one of these shifts or moves are in progress, the controller is locked down, and any additional shift or move commands are ignored until the current action completes.

I do not like this approach personally, so I've been considering a change that will allow you to queue commands. So, for example, if a right shift is in progress and a down shift command is sent, the left shift will execute immediately after the right shift completes.

Adding such a system to the current implementation would not cause any problems, but there are some additional changes I am working on that confuse matters a bit. Basically these changes amount to adding three different states to the Dynamic Loading Controller, which can be changed via the following methods:

Code (csharp):

1. public void DisableController()

This method disables the Dynamic Loading Controller. Disabling the controller means any present Boundary Monitor is disabled and all active cell objects are disabled (and most likely destroyed, though that depends entirely on how your sub controller components are setup).

Code (csharp):

1. DisableCellObjects()

This method disables all active cell objects. The cell objects are guaranteed to be deactivated, and depending on your sub controllers, may be destroyed. You'd use this option if you want the dynamic loading controller and boundary monitor to continue tracking the player and shifting/moving, but you don't want terrains or other cell objects to be displayed. Why would you want to do this? I have no idea, but I think it could be useful to someone .

Code (csharp):

1. DisableMonitorIfPresent()

This method disables the Boundary Monitor if one exists. This will stop the player from being tracked, effectively shutting down the dynamic loading of the world. Note that you can still manually shift/move the world if you choose, and using this method does not change the state of cell objects, so if they're currently visible, they will remain visible. You can use this method to freeze the world in a specific state.

Code (csharp):

1. EnableCellObjects()
2. EnableMonitorIfPresent()

These methods will reverse the effects of the two previous methods. Note, however, that calling these two methods will have no effect if the controller is currently disabled.

Code (csharp):

1. EnableController(bool enableCellObjects, bool enableBoundaryMonitorIfPresent)

Enables the controller, and additionally enables the cell objects and Boundary Monitor if the corresponding parameters are set to true.

Now, why does the addition of this functionality make the queueing I discussed before more complex? Quite simply, the problem is I don't know what you want to happen.

For example, say a left shift is currently executing when a down shift command is sent to the controller. Because a command is being executed already, the down shift is added to the queue and will occur after the left shift has completed. But what happens if you call the DisableController method at this time? Should the controller be disabled immediately after the current command (the left shift) is completed, or after all queued commands are completed (in this case, just the down shift is in the queue, but in other cases, there might be several actions).

Like I said, it's impossible to know what you want to happen in this case, and in several others. With that in mind, there are three options I am considering.

1) Assume that all commands should be executed in the order that they arrive.

2) Assume that disable/enable commands should be executed as soon as possible. This means they will be executed after the current command has finished executing, and after any other enable/disable commands that were previously sent in.

3) Add a new ExecutionPriority enum type that will allow you to specify when the command should be executed. Something like:
a) ExecuteAsSoonAsPossible
b) ExecuteAfterCurrentCommandsInQueue
c) ExecuteAfterCommandQueueIsEmpty

Option a) would be the same behaviour as described in number 2) above.

Option b) would simply add the command to the current command queue.

Option c) would ensure that the command queue is empty before executing the command. This means that other commands added to the queue (via option b) would execute before the command with option c), even if the commands were sent in after the command with option c) was sent in.


So, what do you guys think (if anything) about all this. Any and all feedback is welcome!

If you made it this far, thank you, thank you, thank you! And another thank you if you provide some feedback .

 

Hello all, time for another update!

I'm going to be making some changes soon that will improve the functionality of the kit, but unfortunately will also break existing projects using the Dynamic Loading Kit.

The reason for this is two fold:

I am going to be moving the World Grid scriptable object class into the dll. This is necessary for several reasons that I won't get in to. I'm not actually sure if this will break anything; I still need to test the change and see.

The second change will definitely break things, but don't worry, it won't be hard to make the necessary changes to get your project up and running again. Basically I am going to be removing the Dynamic Loading Configuration Form component and adding two new components: The Active Grid component and World Component. The options you previously setup in the DLCF will be split between these two components.

These changes will allow for two awesome new features:

1) The ability to have multiple players in a single player game. To do so, you just added multiple Active Grid components. Note that you don't necessarily have to have a player associated with the active grid, but "Dynamic Loading" won't work without one. Without a player, you have to manipulate the grid manually.

2) The ability to have multiple worlds. Again, to do so you just add multiple World components. Each world is associated with a World Grid (either different ones or the same one). This will allow you to combine different terrain groups easily and a host of other possibilities.

In addition to these features, I will also be adding support for 3D worlds! Unity terrains can only operate on the 2D XZ plane, but if using other game objects, you will be able to utilize this new world type! In addition to rows and columns, 3D world will utilize a new property; layers! Layers operate on the Y axis, while rows operate on the Z axis and columns operate on the X axis (note that this is only for 3D worlds, you can still have a 2D XY world where rows operate on the Y axis; for a 2D side scrolling game for example).

With these three new features, there are a ton of new possibilities! Expect these changes in a week or two!

 

Nice :3

 

A quick warning:

Secondary Cell Object Sub Controllers will become obsolete with the next update. I am introducing a new system that I think is more flexible and intuitive. I doubt anyone is even using secondary sub controllers, so this will probably have little to no effect on anyone, but I wanted to put out a warning just in case!

 

I posted this on the OP, but wanted to add it here too:

If using a Prefab Instantiator Component, please ensure the prefabs in your Resources folder are disabled. If they are not, the player will see your terrains/other game objects in the wrong position, and the tree colliders on your terrains will not work properly!

Thanks.

 

Known Issue added to OP

If you enable the "Set Neighbors" option when using the Terrain Slicing tool, deleting a slice from the scene after slicing will cause Unity to crash, or produce errors. This may only be an issue with Unity 4.x.

Solution: Either disable this option, or after slicing simply perform any action that causes your scripts to recompile (close/reopen your project, edit/save a script, etc.). This will clear the terrain Neighbors and you should be free to delete the slices without issue.

 

Hello everyone,

In testing my newest update, I have come up across a couple of Unity 3.5 issues I wasn't aware of before now. As I noted some time ago, when using the Prefab Instantiator component, you need to disable your prefabs in your project hierarchy to avoid tree collider issues, and to ensure the terrain is not shown before it is positioned in the correct spot. However, it turns out you can not set the state of a prefab in Unity 3.5.

My first thought was to just have anyone using 3.5 to use the new Scene loader component that makes use of the Application.LoadLevelAdditive method. Unfortunately, it turns out that this method behaves differently in 3.5 then it does in 4.x. In 4.x the objects in the scenes you load take one frame to initialize (that is, to show up in the scene). This allows you to call Application.LoadLevelAdditive(levelName) in Awake, and then in Start, find the objects loaded from that scene for storage/manipulation (this is what I do in the Dynamic Loading Kit). In 3.5, however, this method takes several frames to work, which makes it less than ideal for my purposes.

What does this mean for you? Basically, I am going to be dropping 3.5 compatibility with the next major update. I suspect that this will impact very few users, as most are probably using Unity 4.x Indie or Pro.

However, if you are using 3.5, please contact me. I am fairly confident I can rework the scripts to support 3.5 use of the Scene Loader components. However, it will take a little work, and if there are no 3.5 users then there's really no point to bother with it. It will also result in a few less than ideal changes to how the DLK works, which is why I'm not going to implement these changes to the Asset Store version.

Also note, the Prefab Instantiator issues have no solution (although, if not using Trees and if your cell objects are loaded beyond the camera's far distance, you shouldn't have issues with using it).

I deeply apologize for these issues. Rest assured that any issues will be resolved!

Thanks,

Kyle Gillen

 

I try to "Create a World Grid Asset"... and nothing happens?

 

It should be created in whatever folder you have selected at the time. If no folder is selected, it should be created directly in the "Assets" folder. If you still can't find it, try doing a search in your project hierarchy for "WorldGrid."

If you are still having trouble, please email me at kgillen@deepspacelabs.net

 

Oh! Right, okay, I assumed it was supposed to be in the hierarchy. Found it thanks

 

Glad you found it!

The documentation is not great right now, which I am working on. I actually started writing up some docs a while ago, but then started working on update 2.0 of the kit. Because this update is going to make some things outdated, I decided to forestall writing the guide until it was finished, (which it basically is). I just started rewriting the full guide, and will work on some other stuff soon (as well as videos).

You can check the "Dynamic Loading Kit Comprehensive Guide" found near the top of the following page if you have any more issues:
Page where Guide can be found.

As I said, it's not actually comprehensive, but perhaps it will offer some quick help to common problems. If not, just post on here again and I'll try to respond as quickly as I can!

Thanks!

 

Hey mate, thanks

I'm following along with your steps on the first page of this thread. I hope I'm understanding things correctly. I've placed all my terrain slices in a prefab called "Terrain" in a folder called "Resources" which is under Assets, so Assets > Resources.

I moved World Grid in there as well, as it went to my main folder. I set the base name as Terrain, which my prefab is, set it to 4 x 4, which my sliced terrain is, then pressed Update Data.

Now, the column widths, row lengths, etc are saying "Not Set" after pressing update data. Is that supposed to fill out with data or should it just remain that way?

Cheers.

Edit: While I don't have the dynamic loading working yet obviously, I have 16 terrains from the slice. Is it normal for it to cause a significant frame rate drop? Meager system went from 60fps to 20fps after the slice.

 

You're almost there! Each slice should actually be its own separate prefab rather than being parented to a single prefab. So if you're slices are "Terrain_1_1," "Terrain_1_2," etc., there should be 16 separate prefabs in the resouces folder. I will update the steps to make this clearer.

Also, (and this will only work in Unity 4.x), you should make sure all the prefabs are in a disabled state.

The World Grid can be placed anywhere. It's probably not a good idea to place it in the resources folder, however, because placing it there will mean it is always included with your project build, even if later you decide not to use. Once you add the WorldGrid to your Dynamic Loading Configuration Form component in the inspector, it will be included in your build automatically, so there's no need to place it in the resources folder.

The resources folder is only for assets which are not referenced by one of the components in the scene. Unity tries to only include assets in your build that are actually used in your game, which means it will only include an asset if it is referenced by some component in a scene that is included in the build.

Sometimes, however, you may have an asset which is not referenced directly, but you still plan to make use of during your game (ex: a texture which will only be assigned to a programmatically created material). Our terrain slices are such assets, as we don't reference them anywhere directly, but still plan on using them. Resources folder to the rescue! Any asset in a folder called Resources (you can have multiple Resources folders) will always be included with the build.

Hopefully that clears up some of the mystery surrounding why we need to use the Resources folder in the first place!

As for the performance, that does not seem quite right. Did you remove the pre-sliced terrain from your scene (make a prefab backup for it before deleting)? Each terrain has its own performance overhead, so there's a chance the performance would degrade with slices rather than a single terrain, depending on each individual users project. Once you get the dynamic loading up and running, please let me know if the performance improves.

If not, maybe you can send me a copy of your project that only includes the terrain you are slicing (along with any assets it uses)? You can delete everything else from it except for the TerrainSlicing folder. Just duplicate your project folder, then open the new project in Unity and delete all the unrealted stuff. Then zip (or 7zip) it up and send it to the email listed in my previous post.

Thanks and good luck!

 

Hey mate!

Thanks for running through every thing for me, I really appreciate it

I placed each individual slice in the resources folder as a prefab (all deactivated before doing so). Then created a new world grid just to be sure (deleted old one). And yeah, essentially it just keeps saying "Not set"?

Don't mind the numbers, I was playing around with 4/8/16 just to test I suppose. I also tried the base name as just Terrain and Terrain_Duplicate.

http://i.imgur.com/OgU2aLv.png


As for the performance, I've always had a bit of a performance hit in this project (using editor, it usually takes about a second and a half for a click to be registered... frustrating). But yeah, the terrains are causing even more performance hit, drastically so. I think it might be wise for me to export my project and import into a fresh one as I've had quite a few issues with this project, I just don't know how feasible that right at this moment.

Cheers again for the help

 

Okay, so your grid name is actually going to be the common name shared by all of your terrains. In your case, that will be Terrain_Duplicate 1 (with a space between duplcate and 1). Also, it looks like you are using a 4x4 group rather than an 8x8, so change rows and columns to 4 as well.

After that, the Update Data button should work. Good luck!

 

Oh, right! Worked perfectly. Thank you!

Edit: Sorry, I know it's probably explained but I'm terrible with following guides correctly heh :/

I'm getting the following error:

Which confuses me, do I have to add those prefabs to the build setting? is that even possible lol?


Cheers and sorry again!

 

Looks like you are using a Scene Loader component instead of the Prefab Instantiator one. Remove it and add the Prefab Instantiator instead. You can find it under Componet -> Dynamic Loading Kit -> Cell Object Loaders.

And it's not your fault. The guide is incomplete, as I noted before. So please feel free to keep asking questions!

I am actually working on the new guide for v2.0 of the kit (soon to be released) right now, so hopefully things will be clearer in the future.

 

Alright that's all set up. Things seemed to be loading correctly (pressed play, went back to scene mode, dragged my player to a new area and that area loaded), but now, running around to different sections, the terrain doesn't load for some reason. Not entirely sure why.

And I'm still getting the poor frame rate. It only ducks that low with the sliced terrain. I tried exporting but my project just keeps crashing when I go to export prefabs. Must be too big... idk.

Edit: Actually, that first problem was solved... I had the parent empty game object I store my RFPS player in as the player in the dynamic loader, I changed that to the object with the capsule collider and the terrains load fine now.

 

I am sorry to hear about the poor performance. Is there any way you could send me a copy of your project?

1) Find your project on your machine and copy/paste it somewhere.
2) Open the copy/pasted project in Unity.
3) Remove everything except for the TerrainSlicing folder(and its sub folders), the base terrain (the unsliced one), and any assets associated with it (trees, textures, plants, etc.). You can remove the slices and terrainData associated with the slices as well. Let's try to make the project as small as possible.
4) Compress the folder.
5) Send it to kgillen@deepspacelabs.net

Thanks!

 

Hey mate,

I'm just going to try manually moving everything over into a new project as I was having a lot of unrelated issues anyway, and my project was pretty bloated with a lot of unnecessary assets. I'll see how I go with this and report back

 

Okay.

I sent you a private message as well; please take a look at it when you get the chance and respond back (via PM) at your earliest convenience.

Thanks!

 

Hello. Thanks for the great solution On your website, it says

"Note: I am working on some major updates that will make some of the information in this guide irrevelant. I will start updating the guide once these updates are completed!"

Will the new update possibly break compatibility with older version of the kit? In that case, I want to wait implementing map feature for my game till the update comes out. Do you have any ETA?

 

Hello noanoa,

Yes, it will break compatibility, in a major and minor way.

First, the major. I have found while working on the latest update that the kit isn't really compatible with Unity 3.5. To be clear, it's not that the update that has made it incompatible; it turns out there was always a small quirk that I only recently discovered that makes it so. Because of this discovery, I am changing the kit to require 4.0 or above.

For 3.5 users, this means you should avoid the upgrade. If you really want/need it, please contact me about a possible solution.

As for the minor break in compatibility, the Dynamic Loading Configuration Form component has been removed in the new update, and replaced by three new components. When you download the update, there will be a button on the Dynamic Loading Configuration Form that you can press to add the new components and remove the form component.

Using this button will automatically configure the new components with any settings from the form component that apply. It will also remove the Active Grid Resetter component (which is now obsolete). You should look over the three new components (World, ActiveGrid, and ComponentManager) to make sure they are configured how you like. These changes also mean that any player prefs data you have for the kit will be obsolete, as a new player prefs format is used with the new update.

Also, I have made some changes to the WorldGrid class that will require everyone to reset the their WorldGrid's data.

Finally, secondary sub controllers have been removed, but I very much doubt this will effect anyone (if it does, contact me for possible workarounds).

As for the release, I am done with the actual update and am now working on documentation. The new full guide is almost complete, and once that's done I'll add it to the kit submit the entire thing to the Asset Store.

So, it will probably be a week or two before the update is available. If you wish to get the update early, you can do so by contacting me via email with your Invoice number.

Thanks for the interest!

-Kyle Gillen

 

The time table mentioned above will be pushed back a couple of days, as I want to look into adding some LOD functionality. The system I am thinking of will make use of the Terrain.heightmapMaximumLOD field (and other such fields), so it won't be applicable to non Terrains. I haven't messed around with these settings before, so I still have to see if this will be a fruit full endeavor.

 

Another quick update:

I have indeed decided to add Level of Detail functionality to the kit, but am going to delay implementation of the system for a couple weeks, as I don't want to delay 2.0 of the kit any longer.

As long as my testing goes well, I will submit version 2.0 to the Asset Store tomorrow. Hopefully it will be available sometime next week.

Again, the new version will only support Unity 4.0 or above!

 

Okay, the update has been submitted to the Asset Store. I will let you know when it is available!

I've updated the Dynamic Loading Kit full guide, which you can peruse to get an idea of some of the changes coming with 2.0. It also provides a great overview of the kit in general, which you might find interesting.

You can find it here.

I will start working on a video tutorial series in the coming days as well, which some may find more helpful in upgrading or setting up the kit for the firs time.

Finally, the API is coming a long nicely. I am going to prioritize the video tutorial series first, but the API should be done shortly after. Please let me know what you think about the design (color, layout, text, etc.)!

​

 

It appears the submission review time has been dramatically reduced. Version 2.0 of the kit is now available on the Asset Store!

Unfortunately, I thought I'd have a week or so before the release to get the video tutorials done. I am watching my Niece this week and probably won't have a chance to work on them. So expect them starting next week (if it's earlier, I'll let you know).

 

The first couple tutorial videos covering how to set up the Dynamic Loading Kit for the first time have been uploaded to You Tube.

There's still a couple more in the series, which I'll finish tomorrow.

Please be easy on the critique, this is my first time doing recordings like this!

Like to first video:

DLK Setup

 

The first video series is now complete. More videos will be coming in the next week or so, as well as the API.

Please let me know if you have any questions regarding the upgrade, or the kit in general!

First Time Setup Youtube Playlist

 

Hello all! Hopefully everyone who was waiting for update 2.0 has upgraded by now, but if not, now is a good time to do so.

I took a bit of a break from the kit to work on some other projects, but I'm planning on starting work again next week. Here is a rough outline of what's coming.

1. A couple of improvements to the kit.
   
   • A new component type will be added (Cell Object Destroyer), which you can derive from to create custom object destruction behavior. Currently objects are destroyed via the root object, which can be problematic when the root has many children. The new custom component will allow you to implement custom destruction logic which will allow you to destroy the children of the root in a more efficient manner (destroy 5-10 children per frame, for instance). I will include a default destroyer that does what I just described (destroy x children per frame), though it may make more sense to create a custom destroyer particular to your hierarchy.
     
     
   • Some of the methods of the Active Grid will be updated with a new variable, waitForSignalBeforeMovingPlayer (bool). Currently the methods which move the player (either to a new world or a spot on the current world), move the player automatically once the area the player is going to be moved to is set up (i.e., cell objects are loaded for the area). This may not be ideal is some instances, as you may want to have the new area set up, and then make the Active Grid wait for your command to actually move the player. The new variable and a new method will allow you to do this.
2. The API will be finished.
3. Some new videos will be made showcasing some of the features of the kit. I'm also working on a 2D side scrolling game which I plan on using the DLK with, so I'll make a video showing how the kit can be used with non terrains.

If anyone has found any bugs, or if you do find any, please let me know so I can put the fixes in the next update! Thanks for your time.

-Kyle Gillen

 

Update 2.1 has been approved and is now available on the Asset Store. There are three changes/additions:

1. Fixed a bug with Terrain Slicing tool when attempting to slice a terrain with a detail resolution of 0.
   
   
2. Added a new component, the Cell Object Destroyer. A new field has been added to Primary Cell Object Sub Controller components which accepts this new component. The new component is meant to provide greater control over object destruction behavior.
   
   You can either use the default Simple Cell Object Destroyer (found under Component -> Dynamic Loading Kit -> Secondary Components), or create your own custom type (see Dynamic Loading Kit Full Guide, Advanced Topics chapter for information on how to go about this).
   
   The simple destroyer destroys x number of child objects on each cell object each frame, and then destroys the root cell object last. This is useful when you have a ton of child objects, and destroying them all in a single frame (the default behavior when no destroyer component is provided) would cause performance issues.
   
   Since your parent-child hierarchy is probably complicated, it may make more sense to create a custom destroyer based on your custom hierarchy.
   
   
3. All methods on the Active Grid component which move the player have had a new parameter added to the method signature (bool waitForCommandBeforeMovingPlayer).
   
   Previously, all move methods would work in the following manner:
   a) Add objects for the area that the player was going to be moved to.
   b) Move the player to the new location.
   c) Remove objects for the old area that was no longer in use.
   
   If false is passed in for waitForCommandBeforeMovingPlayer, then the move methods will work in this same manner. Basically, the actual movement of the player is executed immediately after the objects for the area the player is going to be moved to are loaded.
   
   In some cases, however, you may wish to setup the area (preload it), but then manually control when the player is actually moved. You do this by passing in true for waitForCommandBeforeMovingPlayer, which will result in the following procedure:
   
   a) Add objects for the area that the player is going to be moved to.
   b) Wait for a new method called InitiatePendingMove to be called. The move will not be executed until this method is called.
   c) Move the player to the new location.
   d) Remove objects for the old area that is no longer in use.

 

Hey!

Loving the look of this kit

Just wondering, If I use terrains, or mesh terrains, then populate my world with mesh objects, will they work?

I.E, If I walk around my world, will the Meshs, such as houses, rocks and trees be there as I left them? Or is this not supported yet?

Thanks!

-Sean

 

@TheNorthridge

There's a couple ways you could do this.

The easiest would be to just parent the objects to the terrains/meshes they are "on." The one issue with this is if using the Instantiate or Non-Async scene loading methods to load the terrains/meshes into the scene, all the children of your main terrains/meshes will be loaded at the same time, which will most likely cause a hitch in game play.

Another option is to make use of the Cell Action abstract class. With this class, you'll need to implement your own script which derives from CellAction. You then attach your custom Cell Action to each main terrain/mesh in your world. When that terrain/mesh is loaded and activated (positioned and made visible in the scene), the Cell Action's "DoStuffAfterCellIsActivated" method is called. Because this method is a coroutine, you can implement logic which loads the objects over a series of frames. Obviously this method is not ideal, as you'll need to create your own means of generating/storing the list of objects that need to be loaded, and you will also need to manually position the objects if using an endless world (since there is no guarantee the main terrain/mesh will be at its default location).

With either method, the problem arises that all the loaded objects will be in a "default" state. For example, a door that was opened will be reset to it's default "closed" state. If this is something that concerns you, then I'll assume you already have a system of saving/loading the state of these objects. You can use Cell Actions to load the state of the objects as they are loaded. You can also use the "DoStuffBeforeCellIsDeactivated" method of the Cell Action to save the state of the objects before they are destroyed/unloaded.

If you have any other ideas for how to handle miscellaneous objects, please let me know. I am always open to new solutions!

Also, one final thing. By default, the kit simply destroys the root terrain/mesh when it is no longer needed, which will also destroy any children in the same frame. Again, this may cause a performance hitch when you have many child objects attached to your root terrain/mesh. The solution is to implement a Cell Object Destroyer component. This component can be used to customize the destruction logic used by the kit (for instance, destroy x children per frame, then the root object). More info can be found in the Dynamic Loading Kit Full Guide.