Daggerfall Workshop Forums

I was experimenting with modding the game UI but it's something that currently can't really be done. So I would like suggeset and discuss some changes that would open up some possibilites on this front

1.) Don't set the UIWindows (for exampele dfBookReaderWindow) on Awake in DaggerfallUI.cs

2.) Change the Properties for each UIWindow
to : 3.) Implement Properties for all UIWindows that doesn't have one

4.) Make sure the ProcessMessages (and all other references) in DaggerFallUI.cs always goes through the Property and not the variabel itself

5.) In the UIWindow classes (like DaggerfallBookReaderWindow.cs), set all private variabels and methods to protected, and also set all methods to virtual

This would allow modders to easily edit any UIWindow they like. Starting by setting the instance of DaggerfallUI they wish to replace with their own.
With MyBookReaderWindow being a class derived from BookReaderWindow that overrides with the changes that you would like to make

What do think?

I like your implementation idea better, but you can replace windows by catching the window in an OnWindowChange event, closing the window, and using your own custom class.

I feel like most/all private variables in DFU should be protected and most/all of the functions should be virtual. As it is now, some components have to be copied-and-pasted, and then modified.

DFIronman wrote: ↑Sun Oct 06, 2019 8:23 pm I like your implementation idea better, but you can replace windows by catching the window in an OnWindowChange event, closing the window, and using your own custom class.

I feel like most/all private variables in DFU should be protected and most/all of the functions should be virtual. As it is now, some components have to be copied-and-pasted, and then modified.

I actually started using the method you describe, I tried to make changes to the dialogue window, but there a few other scripts that reference it directly that are needed to make it function work (like getting the data from the NPC that your talking to). :/

Yeah, you'd have to replace those scripts at runtime OR (if the variable is available at the class-level) use reflection to set the target variable to point to your new window.

I think this is a good idea. This is only possible for UI windows where a single instance is created and re-used every time. Some UI windows, including most the ones I developed, don't do this and have a new instance created each time they're used. I suggest we do this for all of the existing single instance windows, and then take the others and convert them one by one as needed.

An alternative is a UIFactory class that is used to create new instances of UI windows. Replacement ui classes could then be registered in here by mods. This would cover both types of window without requiring conversion.

Any thoughts on which way?

Some really great suggestions in here. It lines up very closely with my thinking as well.

Something I'd like to add is the ability to optionally present standard UGUI in place of DagUI windows. This would allow modders to gradually reimplement UI to whatever modern standards they wish. Some of the events (like rest UI passing time) would need to be decoupled, but nothing too complex in all that. Hazelnut's suggestion of a UIFactory class is excellent here, as it could manage presentation of either UGUI or DagUI as required.

Could smeone explain to me the concept of a UIFactory. What does that mean exatctly?

It's quite a standard pattern where a 'factory' class is responsible for instantiating implementations. So when you need an implementation of IFoo, you request one from the factory. It decided whether to instantiate FooImpl1 or FooImpl2 and you just use it via the interface not knowing which implementation you actually got. (See https://en.wikipedia.org/wiki/Factory_method_pattern) It's not really much different from your suggestion except for separating the concerns out into it's own class.

I plan to implement a UIFactory soon, so if that makes no sense you can wait and take a look at the code. There are many people doing all kinds of nasty things to mod the UI at the moment, like duplication (TT) or reflection or even event listening and substitution. This is way overdue, so thanks for prompting the change. I also want to make a variant of the travel map to help people select map coords for new locations.

You know, I've been thinking and I don't see why we couldn't have a UIFactory and a ManagerFactory. The latter will allow new versions of the *Manager classes to be used by mods. e.g. a new WeaponManager for the guy doing the weapon mechanics rework mod... unless anyone has any objections I will do them both at the same time. Probably tonight.

No objections here mate.