Thanks for the information numberkruncher. All i mean is a different rule for tile placement when there is a height difference at tile borders.
Essentially i am looking for something like the old NWN toolset or starcraft 2 level editor, like this https://www.youtube.com/watch?v=wEPFlZ_QKVg
I believe they both operate on the vert and effect the four tiles around them rather than the middle tile and effect the nine tiles around them. This means less possible combinations which allows them to have rules for every possible tile placement including height up or down.
i can see from the documentation that working with different heights is entirely possible with your current system in conjunction with the normal unity tools. However, what i really need is to pass my assets off to level designers and for it just to work, so they dont have to worry about the actual construction and can concentrate on the flow and aesthetic of the level. The great strength of a system like this is the freeform nature of level building, where if something doesnât work then it can quickly be deleted and painted out differently. If the process has manual tweaking and set up for different heights then i see that as a hindrance and the benefits of an automated system like this begin to disappear.
So i am wondering if you believe its possible for your tile system to be extended in this way? So it could deal with height in a similar way to the starcraft 2 editor. I would consider paying someone to extend this system or perhaps ask a colleague to look at it.
I havenât used the starcraft 2 level editor, but from the video that you provided, it appears to be procedurally generating the terrain upon painting.
Rotorz Tile System is an object placement system which places instances of tile prefabs. The placement of objects can be influenced by their surrounding tiles, though each tile combination is a separate prefab.
I think that you are going to want an entirely procedural solution to achieve an editor like the one in the video. So in this scenario, Rotorz Tile System is probably not the best choice for your needs.
Ahh, yes now I can see what you mean, though this does still appear to be using a terrain mechanism to achieve this. Which Rotorz Tile System cannot offer.
Well anyhow, please see the private message which I sent you
When switching between play/edit mode Unity clears and regenerates everything which causes object references to be lost. In the case of the brushes palette, the designer window and the scene palette the currently selected brush, tileset and tile system will usually be retained.
Q1. Do you have the âSceneâ palette window open?
Q2. Which game object is being deselected?
Q3. Could you please provide a list of steps which I can follow to reproduce the problem?
Please send your invoice number and E-mail address via PM if you would like to have access to pre-release versions of Rotorz Tile System. If you are interested, I would be very interested to know whether you experience the same issue in the upcoming version.
Many thanks!
Added: After switching to/from play mode you may notice that your tile system has become deselected in the scene hierarchy, but it will still be selected in the scene window (even if the scene window is not displayed). So if you just select the paint tool, the previously selected tile system should automatically âreselectâ. I have just tested this with the current version and this is working as intended.
ive just updated to the latest version and im getting this compile error,
Assets/Rotorz/Tile System/Editor/RtsBrushPropertyDrawer.cs(22,65): error CS1502: The best overloaded method match for `Rotorz.Tile.Editor.RotorzEditorGUI.BrushInspectorField(UnityEngine.Rect, string, Rotorz.Tile.Brush, bool, bool)â has some invalid arguments
ive tried deleting and reinstalling rotorz fresh but its still coming up , any idea whats going wrong ?
Okay, this indicates the true cause of the problem. Another script in your project has defined a class in the global space called Brush which is conflicting with the Rotorz one. Our class is placed in a namespace, but the current release of GameDraw has theirs in the global namespace which causes this problem.
If you are using GameDraw you should contact the developers since they tell me that they have a fix for this. Please let me know if you are using GameDraw.
Cool, like I said, just let the GameDraw developers know that you have the problem also. I had one other customer report this issue and the developers said that they would provide a fixed version immediately via E-mail since the asset store one will of course take a while to approve.
Another resolution is to avoid âusing Rotorz.Tileâ in any scripts in your project, but instead, to use explicit references or aliases.
// Example of alias, at top of script
using Rotorz.Tile.Brush as RtsBrush;
RtsBrush someBrush;
// Example of explicit reference
Rotorz.Tile.Brush someBrush;
