Well, give it some time, @swit has a lot on his hands with EET being so close to release. A new Release Candidate should be up soon, I'm at Ust Natha and it's been perfectly playable so far.
I agree with you that this is currently a big dilemma (ease of use UI or EET awesomeness?) but I think we're not close to having both at once. As good as he is, k4thos is mostly alone on this and it takes a lot of time and work.
No eta sorry. I'm currently not even working on this mod, though Mr2150 is. What I gather from the g3 link posted earlier, k4thos wants to wait until final patch of this mod is released and that will take an unspecified amount of time. I don't recommend wating for it yet.
EET has additionnal campaign selections screens and a few other changes as pointed out by @Mr2150.
I did a quick check of Dragonspear UI++ against EET and the main difference is some strings, text styles and obviously the start menu. There are some fundamental changes to the start menu (both UIs do a lot of stuff in the background in the start menu), however, it should be quite easy to adapt Dragonspear UI++ to make it EET compatible.
By the way, if you're installing EET and not reading the g3 forums, the SoD GUI for EET currently doesn't have an "abilities" button and has no scrolling for modded kits, it will be fixed shortly but going for the BG2 EET UI until next release of EET is a safer bet.
I already had a very brief discussion with @swit regarding EET SOD GUI and we agreed that it's simple to convert Dragonspear UI++ to make it compatible with EET.
However, there are still many changes likely to happen to both this mod and EET yet, f.ex current tally of complete items for the next Dragonspear UI++ update is (Bug Fixes: 6, New Functions: 5, Improved functions: 5, with about 30 more items on the list to go).
Once both are more stable, then it makes sense in making a Dragonspear UI++ EET version as there is clearly demand for it.
I just noticed there's a bugged tra file for polish language, which aborts polish installation, so I fixed it. Here you have correct one: https://www.sendspace.com/file/a9jpuk
What is the resolution of portaits added to NPCs? I have created mod which adds portraits for plot NPCs (gorion for instance) and theirs resolution is 38x60, but your mod strech it to bigger one.
Do you plan to do something with journal pop up? This changing font size looks pretty bad. Maybe adding a scroll would solve this. Then with longer entries you could pause the game, mouseover the window and scroll it to read it all.
I've made it a little bigger, customised it and limited the number of characters. It's also much more reliable at finding the journal/quest entries!
Here's some screenshots from the newest version (currently being tested) - the graphics are placeholders:
New 'naming scheme' for journal entries:
Limiting the number of characters:
Details of the naming scheme:
1 - "Important Events", this is the primary or main storyline 'quest' that appears at the top of the quest log. 2 - "Quest Updated", this is for side-quests or non-primary quests that appears in the quest log. 3 - "Important Information", this is for standard journal entries that aren't tied directly to quests. 4 - "Information", this is for textflashes that don't have an associated visible entry in the quest or journal.
For me, this represents a truer reflection than just 'Journal Updated' which can be misleading. Clicking the popup takes you directly to the relevant section of the quest log/journal, but in the case of item (4) it adds the information presented as a user entry so that information is no longer 'lost'.
Does it always place it in a user entry for item (4), or only if you click on it? I often have troubles that I don't click the popup in time, and then have no idea where to find the update in my journal.
You have to click on it if you want a journal entry added - I tried to make it do it by default for item 4, and was finding that it was adding it multiple times...
So, items 1,2,3: - If you left click then it will find the relevant quest OR journal entry for you. - If you right click then it will also copy the text into your notes
Item 4: - If you left click or right click then it will copy the text into your notes.
It may be possible to increase the display time of the pop-up and have that as an option in settings, eg slow/medium/fast.
EDIT - @Thels - Each popup has it's own display time set for it (presumably by dialog length). Yup, it's doable... I can slow down the ramp-up / ramp-down of the opacity/display process... my quick test ~ doubled the overall display time from about 7s to 14s.
Sorry for the late reply - I made a fix for the dialog with long text issue, and then looked specifically at the journal update in the dialog window that you reported. Fortunately that journal entry works correctly and appears in the journal even though there isn't a pop-up for it. I think this is because Grael is an enemy both before AND after the discussion you have with him - often when you have a journal entry combined with a battle like this the other character starts as neutral rather than an enemy... (or I could just be guessing completely wrong).
Anyway - because that text was long and then the journal entry is also long, I checked specifically to see if the new fix for long text could cope with it. I'm pleased to say it did.
Some screenshots:
Normal text size:
Largest text size:
Journal Entry:
So the good news is that that specific journal entry doesn't appear as popup, yet it does go in the journal log, and the long text fix makes sure that the dialog adjusts correctly (the scrollbars in that instance are expected behaviour due to the size of the dialog) - so all good.
EDIT - Just out of interest I performed the same test in the vanilla UI to see what happens:
Normal text size:
Largest text size:
So I think for that specific situation neither copes particularly well but at least there is more room in the Dragonspear UI++ ...
That came up in 6 seconds or so. Funny thing is, this character is simply going to test something for me on the Lion's Way, and then probably be deleted after...
I cannot get the portrait picker to work. Like it refuses to see my files which is actually getting frustrating. I tried skipping it in hopes that it'd default to vanilla but that won't work either. As soon as I uninstall all my portraits are seen just fine though so I dunno.
Fast = Standard (about 5s) Medium = About 10s Slow = About 15s
And remember that setting in baldur.lua so you can use that when you adapt for journal fix standalone into EEUITweaks/Mod Options.
I'll pop you a message.
EDIT: Thanks @AncientCowboy - the advice you gave me will be invaluable. Much appreciated.
That's a nice feature. I'm trying to implement it too due to problem with vanilla code that doesn't take in-game FPS into account. I'm always playing on 60 FPS, so there is no way to read these messages at all (lasts 2.5s). In order to provide proper timings for journal pop up I'd like to suggest following implementation for Dragonspear UI++:
time = --some default value fps = Infinity_GetINIValue('Program Options','Maximum Frame Rate') popUpTime = time * fps / 30 setSelectedQuest(textflashes[tf][popUpTime])
For some reason it doesn't seem to extend the time though, so there's probably error in above code.
btw. did you manged to somehow extend the time that pop up messages above object's head are visible? Seems to be hardcoded because engine doesn't show boarder around those windows in UI edit mode. That's another thing mostly unusable on higher FPS setting (or maybe I'm just slow reader).
I managed to do it more reliably than I was originally trying, all thanks to @AncientCowboy ...
You raise an interesting point and that factor does need to be included in the final version - Here's the code I'm currently using modified for the approach you want right now, the final code will also have the user selection as an additional multiplier...
1. Create a new M_*.lua file, name it however you want. 2. Paste the following code into the M_*.lua file
-- new Textflash showTextflash function to override the one in util.lua changing the displayTime
showTextFlash = function (title, str, displayTime)
if #textflashes == 0 then
textflashidx = 1
end
local fullStr = Infinity_FetchString(str)
local splitLines = string.gmatch(fullStr, "[^\r\n]+")
local line1 = splitLines()
local line2 = splitLines()
if(line2 == nil) then return end
fps = Infinity_GetINIValue('Program Options','Maximum Frame Rate')
mfunDisplayMultiplier = fps / 30
textflashes[textflashidx] = {title, line1, line2, mfunDisplayMultiplier * displayTime, str}
textflashidx = textflashidx + 1
end
This code currently doubles the display time at fps = 60.
3. Edit the line mfunDisplayMultiplier = fps / 30 as needed to increase/decrease the speed (eg changing it to ((2 * fps) / 30) would mean the textflash is displayed for 4x the time if fps is set at 60.
EDIT: I've not looked at the timing of those popup messages when highlighting something as it's not something I've had a problem with directly... I can't see off the top of my head how to change it either.
EDIT 2: For a standard popup (the soldier that meets you when you first reach Nashkel), my code is giving the following approx. timings:
FPS 30
Slow = ~15s
Medium = ~10s
Fast = ~ 5s
FPS 60
Slow = ~11.5s
Medium = ~7s
Fast = ~3.5s
Reasoning is that the ramp-up / ramp-down times are not being altered so at 60fps these are occurring twice as fast...
So the open question is... would a set time might be a better approach - maybe 5s, 10s, 15s (+ ramp up / ramp down) ? It's easy to code and then you would get the same time regardless of your FPS.
@swit EDIT 2: For a standard popup (the soldier that meets you when you first reach Nashkel), my code is giving the following approx. timings:
FPS 30
Slow = ~15s
Medium = ~10s
Fast = ~ 5s
FPS 60
Slow = ~11.5s
Medium = ~7s
Fast = ~3.5s
Reasoning is that the ramp-up / ramp-down times are not being altered so at 60fps these are occurring twice as fast...
So the open question is... would a set time might be a better approach - maybe 5s, 10s, 15s (+ ramp up / ramp down) ? It's easy to code and then you would get the same time regardless of your FPS.
Not sure what you mean by "ramp" but if it fixes the issue that why not :> Thanks for helping out with this.
The ramp up / ramp down is the point in the text flash when it is not quite solid... eg it is just appearing or disappearing - obviously the timing of these are 2x as quick at 60fps than at 30fps and the code doesn't alter those.
I think, maybe, the best approach is to factor in FPS / User selection but only give approx. timings:
Fast = 5 to 10s Medium = 10 to 15s Slow = 15 to 20s
(based on your PC, what else is on the screen, your FPS setting and other factors).
First time trying this UI and I like it a lot, although the split dialogue window up top takes a while to get used to on a large monitor. One question I dd have though... with both versions of the quick loot window, I can't seem to see if an item is unidentified or not. (i.e. I don't see the blue border that indicates it as such).
I seem to recal the vanilla quick loot interface having this. It makes it a lot easier to visually scan the items in the quick loot window and figure out what to select than when (for example) Gorion's unidentified belt just looks like a standard belt.
Is there anything I'm missing here or is that functionality just not supported by the customized quick loot windows?
You are missing nothing @XKal - both versions of the quickloot have the correct code for showing the familiar blue tint for unidentified items. It should be fully enabled for the next release. Sorry for any frustration caused.
You are missing nothing @XKal - both versions of the quickloot have the correct code for showing the familiar blue tint for unidentified items. It should be fully enabled for the next release. Sorry for any frustration caused.
No worries! That's great to hear. I've played the game so many times over the past 15+ years that it shouldn't even matter, but as my memory goes, my reliance on the UI grows. Thanks for all your work!
Hello @Pecca and @Mr2150 . I was wondering, is there is anyway to activate the blue background functionality when looting things ? I am finding very annoying to have to take all loot, see which is magical/unidentified on inventory and then drop them again. Thanks. P.S.: I use Dragonspear UI++ 2.14 , if there´s a workaround to do b4 needing to wait for the next version, it would be welcomed.
Comments
I agree with you that this is currently a big dilemma (ease of use UI or EET awesomeness?) but I think we're not close to having both at once. As good as he is, k4thos is mostly alone on this and it takes a lot of time and work.
By the way, if you're installing EET and not reading the g3 forums, the SoD GUI for EET currently doesn't have an "abilities" button and has no scrolling for modded kits, it will be fixed shortly but going for the BG2 EET UI until next release of EET is a safer bet.
However, there are still many changes likely to happen to both this mod and EET yet, f.ex current tally of complete items for the next Dragonspear UI++ update is (Bug Fixes: 6, New Functions: 5, Improved functions: 5, with about 30 more items on the list to go).
Once both are more stable, then it makes sense in making a Dragonspear UI++ EET version as there is clearly demand for it.
v2.14
- Polish tra file bug fixed
- Italian tra file updated
- Werewolf Island chapter screens fixed
I've made it a little bigger, customised it and limited the number of characters. It's also much more reliable at finding the journal/quest entries!
Here's some screenshots from the newest version (currently being tested) - the graphics are placeholders:
New 'naming scheme' for journal entries:
Limiting the number of characters:
Details of the naming scheme:
1 - "Important Events", this is the primary or main storyline 'quest' that appears at the top of the quest log.
2 - "Quest Updated", this is for side-quests or non-primary quests that appears in the quest log.
3 - "Important Information", this is for standard journal entries that aren't tied directly to quests.
4 - "Information", this is for textflashes that don't have an associated visible entry in the quest or journal.
For me, this represents a truer reflection than just 'Journal Updated' which can be misleading. Clicking the popup takes you directly to the relevant section of the quest log/journal, but in the case of item (4) it adds the information presented as a user entry so that information is no longer 'lost'.
So, items 1,2,3:
- If you left click then it will find the relevant quest OR journal entry for you.
- If you right click then it will also copy the text into your notes
Item 4:
- If you left click or right click then it will copy the text into your notes.
It may be possible to increase the display time of the pop-up and have that as an option in settings, eg slow/medium/fast.
EDIT - @Thels - Each popup has it's own display time set for it (presumably by dialog length). Yup, it's doable... I can slow down the ramp-up / ramp-down of the opacity/display process... my quick test ~ doubled the overall display time from about 7s to 14s.
Fast = Standard (about 5s)
Medium = About 10s
Slow = About 15s
And remember that setting in baldur.lua so you can use that when you adapt for journal fix standalone into EEUITweaks/Mod Options.
I'll pop you a message.
EDIT: Thanks @AncientCowboy - the advice you gave me will be invaluable. Much appreciated.
Sorry for the late reply - I made a fix for the dialog with long text issue, and then looked specifically at the journal update in the dialog window that you reported. Fortunately that journal entry works correctly and appears in the journal even though there isn't a pop-up for it. I think this is because Grael is an enemy both before AND after the discussion you have with him - often when you have a journal entry combined with a battle like this the other character starts as neutral rather than an enemy... (or I could just be guessing completely wrong).
Anyway - because that text was long and then the journal entry is also long, I checked specifically to see if the new fix for long text could cope with it. I'm pleased to say it did.
Normal text size:
Largest text size:
Journal Entry:
So the good news is that that specific journal entry doesn't appear as popup, yet it does go in the journal log, and the long text fix makes sure that the dialog adjusts correctly (the scrollbars in that instance are expected behaviour due to the size of the dialog) - so all good.
EDIT - Just out of interest I performed the same test in the vanilla UI to see what happens:
Normal text size:
Largest text size:
So I think for that specific situation neither copes particularly well but at least there is more room in the Dragonspear UI++ ...
That came up in 6 seconds or so. Funny thing is, this character is simply going to test something for me on the Lion's Way, and then probably be deleted after...
Edit: Yay that did it. NVM. Fixed XD
Really hoping for a BG2EE version
btw. did you manged to somehow extend the time that pop up messages above object's head are visible? Seems to be hardcoded because engine doesn't show boarder around those windows in UI edit mode. That's another thing mostly unusable on higher FPS setting (or maybe I'm just slow reader).
I managed to do it more reliably than I was originally trying, all thanks to @AncientCowboy ...
You raise an interesting point and that factor does need to be included in the final version - Here's the code I'm currently using modified for the approach you want right now, the final code will also have the user selection as an additional multiplier...
1. Create a new M_*.lua file, name it however you want.
2. Paste the following code into the M_*.lua file
-- new Textflash showTextflash function to override the one in util.lua changing the displayTime showTextFlash = function (title, str, displayTime) if #textflashes == 0 then textflashidx = 1 end local fullStr = Infinity_FetchString(str) local splitLines = string.gmatch(fullStr, "[^\r\n]+") local line1 = splitLines() local line2 = splitLines() if(line2 == nil) then return end fps = Infinity_GetINIValue('Program Options','Maximum Frame Rate') mfunDisplayMultiplier = fps / 30 textflashes[textflashidx] = {title, line1, line2, mfunDisplayMultiplier * displayTime, str} textflashidx = textflashidx + 1 endThis code currently doubles the display time at fps = 60.
3. Edit the line mfunDisplayMultiplier = fps / 30 as needed to increase/decrease the speed (eg changing it to ((2 * fps) / 30) would mean the textflash is displayed for 4x the time if fps is set at 60.
EDIT: I've not looked at the timing of those popup messages when highlighting something as it's not something I've had a problem with directly... I can't see off the top of my head how to change it either.
EDIT 2: For a standard popup (the soldier that meets you when you first reach Nashkel), my code is giving the following approx. timings:
- FPS 30
- Slow = ~15s
- Medium = ~10s
- Fast = ~ 5s
- FPS 60
- Slow = ~11.5s
- Medium = ~7s
- Fast = ~3.5s
Reasoning is that the ramp-up / ramp-down times are not being altered so at 60fps these are occurring twice as fast...So the open question is... would a set time might be a better approach - maybe 5s, 10s, 15s (+ ramp up / ramp down) ? It's easy to code and then you would get the same time regardless of your FPS.
I think, maybe, the best approach is to factor in FPS / User selection but only give approx. timings:
Fast = 5 to 10s
Medium = 10 to 15s
Slow = 15 to 20s
(based on your PC, what else is on the screen, your FPS setting and other factors).
I seem to recal the vanilla quick loot interface having this. It makes it a lot easier to visually scan the items in the quick loot window and figure out what to select than when (for example) Gorion's unidentified belt just looks like a standard belt.
Is there anything I'm missing here or is that functionality just not supported by the customized quick loot windows?
P.S.: I use Dragonspear UI++ 2.14 , if there´s a workaround to do b4 needing to wait for the next version, it would be welcomed.