Automap (indoor & dungeon) implementation

[Narf the Mouse]

Neither did I, until I read it on Reddit.

Another thing from Reddit:
The yellow/other squares in the upper left are a block map.
Four squares to a block.
The quest item/monster is always in an "inner block"; a block with at least four other blocks around it.

Daggerfall maps; not as bad as sometimes surmised.

[Nystul]

Another thing from Reddit:
The yellow/other squares in the upper left are a block map.
Four squares to a block.
The quest item/monster is always in an "inner block"; a block with at least four other blocks around it.

this I know.
It showed a rough estimate of the player position and dungeon entrance in there as well...
Although I don't plan to implement it now that the increased resolution + beacons lead to much better usability.

update: @interkarma: I saw the automap-playground branch was removed. any issues with it? I ask because from my side the automap is ready to get integrated as soon as you get time to review it

[Al-Khwarizmi]

I always used the feature to take notes about a dungeon piece in vanilla Daggerfall. And the square with the blue and red dots showing a rough sketch of where you were with respect to dungeon entrance was rather handy too. You guys were playing vanilla Daggerfall dungeons wrong!

It would be great to see these features in DFUnity.

[Interkarma]

update: @interkarma: I saw the automap-playground branch was removed. any issues with it? I ask because from my side the automap is ready to get integrated as soon as you get time to review it

Sorry, I meant to re-create that branch as part of the cleanup. Done now!

Please update from my latest master to your fork's master and working branches then send me another pull request to the automap-playground branch. I'll get that updated at my end and review.

[Narf the Mouse]

I always used the feature to take notes about a dungeon piece in vanilla Daggerfall. And the square with the blue and red dots showing a rough sketch of where you were with respect to dungeon entrance was rather handy too. You guys were playing vanilla Daggerfall dungeons wrong!

It would be great to see these features in DFUnity.

I knew about the minimap. Just didn't know about the "Your quest item is in an inner block" or how to put a note on tiles till I read it on reddit.

That last alone makes dungeons a lot easier to navigate.

Anyway, getting a bit off topic.

----------------

I think the minimap would be a good thing to include, because it tells you which blocks are inner blocks, and where you are in the dungeon. But I haven't tried the auto-map yet, so I'll wait for that before I make any real recommendation there.

[LypyL]

I always used the feature to take notes about a dungeon piece in vanilla Daggerfall. And the square with the blue and red dots showing a rough sketch of where you were with respect to dungeon entrance was rather handy too. You guys were playing vanilla Daggerfall dungeons wrong!

It would be great to see these features in DFUnity.

I understood what the yellow minimap was for, it just wasn't at all useful to me.

[Nystul]

Sorry, I meant to re-create that branch as part of the cleanup. Done now!

great thanks! One thing I want to change as soon as possible is - as already mentioned - the constant speed of control actions regardless of framerate.
As soon as I managed to fix that issue I will do a final pull-request and will be available for any integration issues/questions

one thing that is bothering me: automap branch has changes to the default scene (gameobject automap with attached script).
Since merge-conflicts are a consequence of it - should I try to revert the scene to your master branch's scene (I hope I manage to do it) - or are you more expert regarding git than me and it is an easy thing for you to revert it when integrating the pull request)


regarding the mini-map. Would like to wait for feedback after people tried out the current implementation in DFUnity 0.2. If the majority of people then thinks that the mini-map would increase the usability of the map I will look into it. But that will be after 0.2

[Interkarma]

Scene is a fun one. Unlike code, it's hard to use git compares to see any changes that have been made to a scene, and I want to keep this as curated as possible from my end.

If you could, revert back to the master scene just to ensure everything else can be pulled cleanly into your branches. Then add back your gameobject and script in the automap branch. When it comes time to pull to master, I will add the necessary changes to the scene in the master branch.

I'm also wondering if reverting the scene will help with the overexposed lighting issue. I've not experienced any worse effects here moving from 5.2 to 5.3, so maybe the scene needs a bit of a resync? In any case, I would still love to retune lighting before 0.2 release, there are just too many dark angles and bright spots, and no warmth to anything. That's something I'll tackle once the items-inventory features are nearing completion.

[Nystul]

On my side, I use iTween to handle all translations/rotations and it performs correct time integration per-frame for those actions. It might be worth taking a look at iTween if you don't want to handle manually. It's more or less fire-and-forget.

took a look at iTween and its documentation. what is unclear to me is how to use it inside my update() function.
for example, when the corresponding button is clicked, the model is rotated left for a certain amount in the update function as long as a boolean variable "leftMouseDownOnRotateLeftButton" is held down.
How to implement this with iTweens?
Can iTween's RotateUpdate() function help here? I want to point out that I want to have it rotating at a constant speed as long as the button is not released. I don't want to require a click-festival

maybe it is easier to use Time.deltaTime this time...

[Interkarma]

If you're talking about manually rotating or translating objects the map view, then yes definitely better to just set a rotation speed and multiply by Time.deltaTime to keep resulting speed constant across multiple systems.

iTween is better for fire-and-forget actions (e.g. move this object to here in this amount of time), which is what I thought you were looking for sorry.