Automap (indoor & dungeon) implementation

[Nystul]

My bad, I will fix that. Compass was written before the GUI system, so it still has a couple of single-purpose assumptions in there.

Edit: Fix is on git now. The compass can now accept any arbitrary alignment. Just let me know if any more problems with this script.

great thanks! going to check it out right now!

update: managed to get it to work now - although had to use the dummy panel trick as well here - didn't manage to make it work without. resizing the editor window results in correct but delayed position updates - this is not optimal, but right now I don't know how to fix it...

[Nystul]

I love it! You made impressive progress.

How about the ability to place some markers (and maybe a way to find them, like a button that will cycle through the placed markers).

thanks mate!
markers are a nice idea - but how should the player position them, what would be intuitive? - easy way would be to allow to set a marker only on the current player position - so you have to walk before you can place the next marker.
your input made me think about it a bit longer and maybe something like the beams along the y-axis Interkarma used in the streaming world demo would be a nice way to visualize it.
There could be 3 permanent "markers" for dungeon entry, player position and rotation pivot point/axis of the automap

The map should automatically flash the exit block, for one thing.

see above comment how I would implement this

Another thing that would be extremely useful is a make route and clear route button. Clicking a block on the automap would trace a route from the current player position to the destination block. You could then draw a line near the floor for the player to follow. This would make the games ridiculously large dungeons easier to navigate because you wouldn't have to constantly survey the map just to backtrack.

this is too ambitious I think. at least I won't be able to implement this. Sounds complicated and very involved. I also fear that it could make the game a bit to easy. could also break immersion.

Alternatively, you could create some kind of "fast travel" button for dungeons that would enable the player to more-or-less warp to an already explored block in exchange for an hours passage of time.

not sure if this will also break immersion... I would suggest to solve this by implementing an advanced version of the recall-spell maybe...

[Ledjlale]

this is too ambitious I think. at least I won't be able to implement this. Sounds complicated and very involved. I also fear that it could make the game a bit to easy. could also break immersion.

You could use the compass to give directions, it will be more immersive.
You compute the path from the player position to the beacon (the best would be in realtime, so you don't need to show the map) and you can add a marker on the compass for the next point (not the nearest)

Here, the big task would be to compute the right path
Showing the route on the map become secondary and I guess that if you can get the path (so (x,y,z) points), drawing lines is nothing on the map

[Nystul]

this is too ambitious I think. at least I won't be able to implement this. Sounds complicated and very involved. I also fear that it could make the game a bit to easy. could also break immersion.

You could use the compass to give directions, it will be more immersive.
You compute the path from the player position to the beacon (the best would be in realtime, so you don't need to show the map) and you can add a marker on the compass for the next point (not the nearest)

Here, the big task would be to compute the right path
Showing the route on the map become secondary and I guess that if you can get the path (so (x,y,z) points), drawing lines is nothing on the map

I just can repeat my words. I think this is too ambitious - I don't think I could implement this. But anybody who wants to try to implement this can do so nevertheless I don't like the idea personally because of the immersion issue, but this is just my opinion

[Nystul]

I started implementing making the geometry of the automap independent from the existing geometry in game. I basically make a copy and deactivate the unwanted parts of the gameobject.
I encountered a issue though:
serialization class throws an exception in destructor. (I think also some constructor was giving an exception as well when I make the copy by instantiating the original gameobject - but right now I can't reproduce).

SerializableActionObject and SerializableEnemy class seem to behave a bit different than SerializableActionDoor class which doesn't seem to throw the exception.

the warnings i get are, e.g.:
Exception: serializableObject does not have a valid LoadID
DaggerfallWorkshop.Game.Serialization.SaveLoadManager.DeregisterSerializableGameObject (ISerializableGameObject serializableObject) (at Assets/daggerfall-unity/Scripts/Game/Serialization/SaveLoadManager.cs:216)
DaggerfallWorkshop.Game.Serialization.SerializableActionObject.OnDestroy () (at Assets/daggerfall-unity/Scripts/Game/Serialization/SerializableActionObject.cs:44)

I will update my "automap-playground" branch to make it possible for you to reproduce the issue

[LypyL]

Alright so I just grabbed it after some tinkering managed to get it working...this might be my favorite thing ever Once I remembered I could zoom in and drag with the mouse I was blown away

Some comments:

1. The rotation button controls could be a bit more precise

2. Not showing doors will reveal the locations of hidden doors...I think they use different meshes, so you might be able to just show the "non-standard" doors or something.

3. Have you thought about how you're going to deal with action objects? I did some quick checking as I've never really thought about it before, and it seems they filter out some objects like levers but show others like platforms.

4. Since there are colliders on the meshes, you should be able to use raycasting to allow the player to manually place markers on the map.

5. Holding the right mouse button and moving left or right would be a natural way to rotate with the mouse I think.

6. Sometimes the automap lights don't get disabled / destroyed when the map does.

edit: For 2 & 3 we might be able to make this a bit easier to deal with by making some more specific parent objects, rather than search through all the doors & action objects

[Interkarma]

update: managed to get it to work now - although had to use the dummy panel trick as well here - didn't manage to make it work without. resizing the editor window results in correct but delayed position updates - this is not optimal, but right now I don't know how to fix it...

Sorry about that. It looks like I need to rework compass some more to make it more portable. Stick with the temp solution for now.

I started implementing making the geometry of the automap independent from the existing geometry in game. I basically make a copy and deactivate the unwanted parts of the gameobject.

Rather than do that, we should use the RDBLayout methods to instantiate a simpler copy of the dungeon. Instantiate map geometry first time user opens map, disable it when not in use, then delete when user transitions to exterior.

RDBLayout can build the dungeon gameobject in stages. Use CreateBaseGameObject() for just the static geometry, then call methods like AddActionDoors() to add the doors. It will be fast because the meshes and textures are already cached. It will also let you create the dungeon how you want and avoid expensive objects (lights, enemies) altogether.

There are currently a few issues with this however. Firstly, the methods have been modified to require a reference to actionLinkDict. This will need to be designed a little differently so the geometry can be loaded independent of actions. Secondly, the RDBLayout methods will try to add serialization properties to some objects, which isn't desirable in this case.

I will quickly fix these issues with RDBLayout methods this morning.

Edit: I have made the following changes to better support you for loading a custom copy of dungeon geometry.

1. In RDBLayout methods actionLinkDict is now passed by value instead of reference. It's a Dictionary class, no need to pass as reference, it will be the same collection regardless. This allows you to pass null for actionLinkDict to avoid adding actions to geometry.
2. Added a serialize flag to RDBLayout methods. Passing false for this flag will turn off serialization for those game objects supporting it.
3. Changed serializable classes to only register/deregister if LoadID != 0. This will avoid exceptions for objects without serialization properties.

Give RDBLayout a shot now and you should be able to build your map geometry quickly and without any of the complications of working with live scene objects.

Let me know if any problems!

[Nystul]

Alright so I just grabbed it after some tinkering managed to get it working...this might be my favorite thing ever Once I remembered I could zoom in and drag with the mouse I was blown away

Some comments:

1. The rotation button controls could be a bit more precise

2. Not showing doors will reveal the locations of hidden doors...I think they use different meshes, so you might be able to just show the "non-standard" doors or something.

3. Have you thought about how you're going to deal with action objects? I did some quick checking as I've never really thought about it before, and it seems they filter out some objects like levers but show others like platforms.

4. Since there are colliders on the meshes, you should be able to use raycasting to allow the player to manually place markers on the map.

5. Holding the right mouse button and moving left or right would be a natural way to rotate with the mouse I think.

6. Sometimes the automap lights don't get disabled / destroyed when the map does.

edit: For 2 & 3 we might be able to make this a bit easier to deal with by making some more specific parent objects, rather than search through all the doors & action objects

glad you like it I agree with you basically about every point thanks for pointing out some open issues! should have mentioned the required "Automap" layer though - sry for that :/

Rather than do that, we should use the RDBLayout methods to instantiate a simpler copy of the dungeon. Instantiate map geometry first time user opens map, disable it when not in use, then delete when user transitions to exterior.

RDBLayout can build the dungeon gameobject in stages. Use CreateBaseGameObject() for just the static geometry, then call methods like AddActionDoors() to add the doors. It will be fast because the meshes and textures are already cached. It will also let you create the dungeon how you want and avoid expensive objects (lights, enemies) altogether.

There are currently a few issues with this however. Firstly, the methods have been modified to require a reference to actionLinkDict. This will need to be designed a little differently so the geometry can be loaded independent of actions. Secondly, the RDBLayout methods will try to add serialization properties to some objects, which isn't desirable in this case.

I will quickly fix these issues with RDBLayout methods this morning.

Edit: I have made the following changes to better support you for loading a custom copy of dungeon geometry.

1. In RDBLayout methods actionLinkDict is now passed by value instead of reference. It's a Dictionary class, no need to pass as reference, it will be the same collection regardless. This allows you to pass null for actionLinkDict to avoid adding actions to geometry.
2. Added a serialize flag to RDBLayout methods. Passing false for this flag will turn off serialization for those game objects supporting it.
3. Changed serializable classes to only register/deregister if LoadID != 0. This will avoid exceptions for objects without serialization properties.

Give RDBLayout a shot now and you should be able to build your map geometry quickly and without any of the complications of working with live scene objects.

Let me know if any problems!

great! getting my hands on this now! thanks!
regarding the geometry deleting when user transitions to exterior: is it possible for a gui script to subscribe and receive events? I was not sure because the don't seem to derive from monobehavior if I haven't overseen something. Will give it a shot

[Interkarma]

great! getting my hands on this now! thanks!
regarding the geometry deleting when user transitions to exterior: is it possible for a gui script to subscribe and receive events? I was not sure because the don't seem to derive from monobehavior if I haven't overseen something. Will give it a shot

There are a bunch of events in the components, but I need to add some more. If you're deriving from any UserInterfaceWindow class, you can also override OnPush and OnPop to do things when the window comes on and off the stack. Would you like some events for OnSetup, OnOpen, that kind of thing?

[Nystul]

yeah have seen this. I am already using OnPush and onPop. For now I think it is enough

update:
works like a charm
though had to split the automap into two scripts, one is Game/DaggerfallAutomap.cs, the other (the old) is now Game/UserInterfaceWindows/DaggerfallAutomapWindow.cs (I renamed this one)

its on github - some info in my last commit comment, which was (there is a issue but it will be solved soon - just had no time left):

[automap] automap geometry is now handled in DaggerfallAutomap class

KNOWN ISSUE: dungeon blocks are placed over each other...

DaggerfallAutomap is inheriting from MonoBehavior:
so it can use transition events (which are needed)
DaggerfallAutomapWindow no longer handles geometry - but instead consumes it, it handles still the camera and lights though
updated scene since it is now necessary to have a gameobject called "Automap" with the DaggerfallAutomap script attached!
added new function DoLayoutAutomap() to DaggerfallInterior

update2:
dungeon geomtry loading is now fixed