Automap (exterior) implementation

Discuss Daggerfall Unity and Daggerfall Tools for Unity.
Blue Footed Booby
Posts: 8
Joined: Wed Jun 14, 2017 4:32 pm

Re: Automap (exterior) implementation

Post by Blue Footed Booby » Wed Jun 14, 2017 4:49 pm

Al-Khwarizmi wrote:
Interkarma wrote: One of the problems with keeping these nameplates is that Daggerfall can (and does) reuse the same building for different quests with a different surname. Daggerfall doesn't even try to resolve this and just stacks all the nameplates on top of each other, leading to a cluttered mess.

See, it's not really "The Wicking Residence". None of the occupants are likely to even have that name. It's just some random "local/remote house1-4" with a random surname generated at the time quest was instantiated. There's no tracking in the game data to persist these names in the way shops can. Residences don't even have a name key at all. And the way Daggerfall resolves this is by just slapping down name stickers and hoping for the best. The core issue is actually that residences have no function before or after a quest they are involved in.
Oh, that's a real pity. I didn't know the (vanilla) game had that imperfection.

Hoping for a mod in the future that makes the X residence always be called the X residence, and have occupants surnamed X.

Yes, I'm that kind of guy... :lol:
I haven't actually messed with the code, but I don't think it'd be too hard to implement. Two houses can't have their front door occupying precisely the same space and still have both be accessible, so the coordinates of the front door are essentially a unique identifier. When a house is entered or assigned as the destination for a quest, hash those coordinates and use the result as a seed value for whatever code generates the random names. Bam, the house will get the same name every time, without needing to store the name or assign every house a new identifier.

Even if there's some edge case I'm forgetting about, like a generic residence with multiple entrances, the worst case is ending up with the same behavior as vanilla Daggerfall.
vvvvv hallooooo! I'd been hopefully following the DaggerXL forums for ages and only just got around to joining here.
Last edited by Blue Footed Booby on Fri Jun 30, 2017 6:42 pm, edited 1 time in total.

User avatar
Interkarma
Posts: 3481
Joined: Sun Mar 22, 2015 1:51 am

Re: Automap (exterior) implementation

Post by Interkarma » Wed Jun 14, 2017 9:16 pm

Hi Blue Footed Booby, welcome to the forums. :)

User avatar
Nystul
Posts: 1150
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (exterior) implementation

Post by Nystul » Sat Sep 15, 2018 8:38 am

I am working on SDF rendering support for the exterior automap.
In principle I have this almost working with the old approch (rendering textures for nameplates).

But since the new font rendering shaders now support clip regions (restricted render areas) I want to use the TextLabel now for the nameplate rendering. If I get it to work with nameplates this would make lots of code lines obsolete so fingers crossed...
A positive side effect would be that ideally we could get rid of all these textures completely saving a bit of gpu memory

Just want to say it will take some more time to get this working correctly

User avatar
Interkarma
Posts: 3481
Joined: Sun Mar 22, 2015 1:51 am

Re: Automap (exterior) implementation

Post by Interkarma » Sat Sep 15, 2018 9:14 am

Sounds great! And take your time, my friend. :)

Mike
Posts: 172
Joined: Sun Feb 19, 2017 6:49 pm

Re: Automap (exterior) implementation

Post by Mike » Tue Sep 18, 2018 5:10 am

Nystul, would your contemplated automap nameplate rendering change also have the positive side effect of preventing this bug from ever cropping up again? https://forums.dfworkshop.net/viewtopic.php?f=24&t=1060

Unfortunately, I haven't been able to test for the bug in the most recent builds and won't be able to for a while longer, and I seemed to be the only person reporting the issue - still not sure whether that was just because I was the only one who noticed it, or it's a problem on my end.

User avatar
Nystul
Posts: 1150
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (exterior) implementation

Post by Nystul » Tue Sep 18, 2018 6:03 am

This bug is likely more related to the discovery system than the nameplate rendering.

Mike
Posts: 172
Joined: Sun Feb 19, 2017 6:49 pm

Re: Automap (exterior) implementation

Post by Mike » Tue Sep 18, 2018 11:44 am

OK, thanks for the reply. I'll test again when I get a chance and see if I can still reproduce, then update the bug topic.

BansheeXYZ
Posts: 83
Joined: Fri Oct 23, 2015 8:19 pm

Re: Automap (exterior) implementation

Post by BansheeXYZ » Tue Oct 30, 2018 6:25 am

This isn't a bug, just a few problems I have with the implementation. Basically:

-I want the town map to stop auto-zooming. When I go into smaller towns, the setting I was using in the prior town gets wiped, and it goes ridiculously zoomed in and I can't see much. Generally, the more you can see at once, the better, and this behavior isn't doing that. It's requiring me to do a lot of tedious scrolling and zooming when I should be able to see the whole map in my 900p window.
-With high resolutions at our disposal, anything above 4x is just bad. 2x/3x is optimal, and 1x without labels would actually be useful too. And that's because you don't always need labels to recognize every building. If I'm going to the Mage's Guild, I can use 1x for that. I can see the entire city map in a 900p window and not scroll for that.
-Zooming itself is too cumbersome and slow. This is because instead of zooming between 4 integer settings, you're zooming small fractions at a time. But there's really no point in a 2.67x setting, is there? It's so close to 2x and 3x, and it distorts the pixels. It would be faster and clearer to just restrict zoom to integers. Being able to switch between 1x,2x,3x, and 4x really fast would be awesome.
Last edited by BansheeXYZ on Tue Oct 30, 2018 6:31 am, edited 1 time in total.

User avatar
Nystul
Posts: 1150
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (exterior) implementation

Post by Nystul » Tue Oct 30, 2018 6:31 am

Initial zooming level is dependent on location size currently. This can be fine tuned however I agree with you. But as always it is a matter of taste. So we need more opinions here

BansheeXYZ
Posts: 83
Joined: Fri Oct 23, 2015 8:19 pm

Re: Automap (exterior) implementation

Post by BansheeXYZ » Tue Oct 30, 2018 9:15 pm

Yeah, I mean, ideally a test build for people to try would be best. I see it working fine in my head, though.

I've been thinking about this some more today, and I had an idea to make the town maps an overlay toggle. I created this mockup to show what I mean.
mapidea1.png
mapidea1.png (447.97 KiB) Viewed 179 times
This is 2x scale, centered, with the brown color adjusted to stand out better. I added bullets to labels. The two advantages to this are (a) being able to move while seeing the map and (b) not having to scroll or zoom at all since the map is static and complete. It works on 900p or higher resolutions. Which is basically every PC monitor.

I don't know if this would be considered a mod or QOL. It's using the same imagery as the classic viewer, it just doesn't use the fairly useless buttons or background.

Post Reply