Closed Stemuweb closed 4 months ago
Additional info:
When we play, we first look for the first switch along the way. From my notepad list, I tell my friend the different possibilities for the 2nd switch. When he's found it, I display the combination with the L/R symbols.
This lets me know which switches to activate quickly, and he knows which junctions to take along the way.
So perhaps typing /ah crossing
or /ah crossing x
should display the different paths locally (if there is more that one path, otherwise it can display the 0 or 1 solution in chat as below), and typing /ah crossing x y
should display in the zone chat (if it's possible):
There is a possible path:
x y [...]
or
There are several possible paths:
x y [...]
x y [...]
or
"No known path that starts with x y"
Just an suggestion, I don't want to give you extra work if you are already busy!
Since this is my idea, if you need an extra pair of hands, I could try to implement it in a separate file if it helps!
Trying to think of a clean way to do this in the UI - would be nicer than relying on slash commands - but UI design is not my strong point
Maybe a panel (that would appear automatically on the map of the treacherous crossing) depending of a setting.
A drop-down would allow to select a number between 1-6 for the path beginning.
If a value is selected, two other drop-downs would be enabled to filter even more (if more that one possible solution exist): 2nd step / end of the path
Below that, the possible paths would appear (with first number, and second or last number highlighted, depending on which drop-downs were used). See attachment for my best paint work.
But, it may be a lot of work for a small feature. Not knowing anything about UI panels in TESO, I think it would be better to do something simple for the next release, even if it means adding a fancy UI in the future.
And from reading the LibAddonMenu description, it's only available for the game's settings menu, so maybe dropdowns are not even possible. *
If you fear people will miss the feature because they won't read the slash commands description, a help message could be displayed in the chat when entering the crossing map resuming the commands.
(*) I remembered the add-on displayleads use dropdowns. It doesn't use a library but defines an xml file. A dropdown is defined like this:
<Control name="RDL_DropdownMajor" inherits="ZO_ScrollableComboBox" mouseEnabled="true" >
<Anchor point="TOPLEFT" relativeTo="$(parent)Alerts" relativePoint="TOPRIGHT" offsetX="15" offsetY="-2"/>
<Dimensions x="275" y="28" />
<OnShow>
RDL.SetupDropdown(self)
</OnShow>
<OnMouseEnter>
RDL.DropdownShowTooltip(self, "major", true)
/OnMouseEnter>
<OnMouseExit>
RDL.DropdownHideTooltip(self)
</OnMouseExit>
</Control>
I don't know if it would be easy to use!
P.S.: I have seen this comment at the end of utility.lua: "regex for crossing - (\d[LR]?)". The L and R don't need to be used in the slash command to filter the path, it's just a piece of advice to help the runner avoid wasting time by hitting a dead end.
I'm fine with dropdowns - I prefer lua to XML (nothing wrong with XML, I just don't like it :)) The comment is there as I worked out a regex that lets me store all the options in a simple way, just didn't want to forget what it was. I'll start having a play with this.
If you want to do a more graphic panel for this hidden level, I have begun to take screenshots of every path. It could be possible to display a map of the hexagons (it's a 7x3 grid, with the middle column visually shifted by 1/2 unit down), the actives tiles, maybe the correct path. And if the game gives the player coordinates in real time, it could be possible to deduct on which tile the player is.
(Don't know if is possible to display an hexagon. Does it to be a resource in-game or is it possible to draw lines?)
Let's stick with a box in the UI for now - might be worth investigating this one later though.
I've created a new branch "crossing" with my first attempt in it - not tested in the archive yet.
You can get the window to show anywhere with:
/script ArchiveHelper.ShowCrossingHelper(true)
Wow, great job! When I opened it, I never thought I'd see such an accomplished piece of work.
A few design remarks, just off the top of my head, feel free to consider them or not:
Runner: ⬅️ Turn left / ➡️ Turn right
with the same discret look as the instructions above.Since I started taking screenshots to document the paths, I've found a 9th one 1 6 2 4R 5 3
I'll add that shortly and address your issues which I think are all valid - just be aware the currently pushed code is bugged as it leaves bits of the window behind it (you'll see what I mean if you try it).
Also, since I started documenting the paths, I have updated my note file, that I use with my friend to be more clear about what side to start (because we start rapidly once we have identified the path, so he needs to know where to run first):
R 1 5 4 2L 3 6
. 1 6 2 4R 5 3
R 2 5 1 4 3
R 3 1 4 6 5L 2
R 3 5 1 4 2L 6
. 5 1 4 2 3
R 5 1 4 2 3 6
L 5 2L 6 4R 3 1
R 5 3 4 1 2 6
I have moved the first R/L before the first index because it's not related to a fork on the path, it's the start side. Either you could display an arrow as the first path symbol, or totally discard the first letter in the list above (. means starting middle, but it could be confusing to add an icon just for that)
To be very, very picky:
just be aware the currently pushed code is bugged as it leaves bits of the window behind it (you'll see what I mean if you try it).
I have taken the new branch an hour ago and can't reproduce this effect. I'm playing in windowed mode, not covering the full screen, perhaps it explains the difference.
Noted a small bug while playing with the dropdowns:
We also have to think about the duo mode. When one player changes one dropdown, should the 3 dropdowns values be shared with the other player? (I say the 3 values at the same time to be sure there won't be desync between the two players if the datasharing lib decides to drop messages to avoid spamming).
Knowing human nature, I'm a bit wary if both players can try to change dropdown values at the same time and get into some sort of conflict. Perhaps when one player changes his dropdown, the other player should have his dropdowns disabled for a few seconds, to force him to remain a spectator.
As long as it's easy to code, that is.
Thanks for the input - a few notes from me:
* My colour scheme looks horrific now - would you mind giving me some rgb values for colours that would work better? It's not my strong pount :-)
I have tested #DFDFDF (or 0.82, 0.82, 0.82) for CROSSING_INSTRUCTIONS and CROSSING_KEY. Not being a graphic designer myself, it's better not to be daring.
* I'm going to leave out the first L/R/. for the time being - I've personally not found that a problem so long as you stand in the middle to start with * The alignment of the numbers is not straightforward as they are not actually columns, but text strings - I'd prefer to avoid more complexity if I can (I'd have to make each one its own label - lazy coding FTW)
Both points are totally understandable.
* I've had a go at some of your other comments - let's see if it's any better now.
Everything is fine. You could remove a bit of spacing above and under instructions, making the box a little more compact, but otherwise, it's great.
Edit:
I asked my duo partner to test the panel without giving him the slightest explanation beforehand. Here's his feedback:
he didn't understand the meaning of the left/right arrows straight away, he didn't see that the legend referred to the arrows on the path. He confirmed that it would be better if the legend (turn left/turn right) was at the very bottom of the window under the solutions, otherwise it doesn't seem related.
In French, it would be better to say "Prendre à gauche" and "Prendre à droite".
It would be better to put the right arrow before the text, otherwise it doesn't look like a legend but like text between < > tags, i.e. : < Prendre à gauche - > Prendre à droite (maybe replace the dash in the middle by a | or several spaces, so it doesn't look connected to the right icon)
After testing during a run:
I have tested #DFDFDF (or 0.82, 0.82, 0.82) for CROSSING_INSTRUCTIONS and CROSSING_KEY. Not being a graphic designer myself, it's better not to be daring.
Works for me :-) - now applied
You could remove a bit of spacing above and under instructions
I've played a little with the spacing.
it would be better if the legend (turn left/turn right) was at the very bottom of the window
Agreed, and done
In French, it would be better to say "Prendre à gauche" and "Prendre à droite"
Also done
It would be better to put the right arrow before the text
Done
The position of the panel seems not to be memorised (corrected z to s - British English please ;-) )
I had already configured this, but the variable name was wrong. It's now fixed.
The drop-downs should be cleared when the panel automatically appears in a new bonus level
This should also now be fixed
ensure that the panel cannot move beyond the edges of the screen
I keep forgetting to add this in my addons for some reason - it's added now
In the Echoing Den, the timer text box kept the same width and height as the panel used in the Treacherous Crossing
This may have been due to a setting I changed for the crossing - I've added code to reset that now, so should hopefully resolve this issue
I'll check the centring issue later - been at this keyboard way too much today :-)
Oh - the duo mode stuff - I've implemented the crossing selection for the group leader only, the other player should just see the results - totally untested though.
1) Here's a screenshot to give you more details about the centering bug and how to reproduce it.
2) I've made a small change to the french instructions text to take advantage of the reduced font size, which gave me more room to reference the drop-down list. Also the proper way to say second, when there is a third (because it's French and its many rules). Sorry for the inconvenience. If you prefer a PR (or at least a branch) in the future, when it's just for one sentence, let me know:
L(
AH .. "CROSSING_INSTRUCTIONS",
"Trouvez l'interrupteur correspondant au début du chemin et sélectionnez-le dans la liste déroulante ci-dessous (1 est le plus à gauche, 6 le plus à droite)." ..
" Puis, si nécessaire, trouvez la 2ème étape ou la fin du chemin."
)
3) I don't know if duo communication works, we didn't get the right level during our last run. When the panel is opened, a debug print shows "nil". Both players (leader and other) could use the drop-down lists (when only the leader should have?).
Just to make debugging easier, would it be possible to activate data sharing throughout the archive? You don't need to be in the hidden level to test the panel, as it doesn't depend on any element, it will be easier to test it in the lobby.
Edit: Bear in mind that the group may consist of more than 2 people and that the group leader may not be part of the duo. I'm going to test whether the game lets you do this.
Edit 2: Yes, two group members can enter the infinite archive and begin a run. The group leader won't be able to enter the instance because it's "full". But I suppose it's a very exceptional case and you have to do it on purpose.
4) Are you planning to add:
So that I know if it needs to be translated and tested before the next release.
5) Important: the drop-downs background should be fully (or almost) opaque. It's hard to read, especially when solutions are already displayed underneath.
I changed debug to true, and activated the panel with the /script command inside the archive lobby. I got this error message:
user:/AddOns/ArchiveHelper/ui/ui.lua:326: function expected instead of nil
stack traceback:
user:/AddOns/ArchiveHelper/ui/ui.lua:326: in function 'createComboBox'
<Locals> name = "ArchiveHelper_choice1", parent = ud, width = 40, height = 40, choices = [table:1]{1 = 1}, callback = user:/AddOns/ArchiveHelper/ui/ui.lua:542, combo = ud </Locals>
user:/AddOns/ArchiveHelper/ui/ui.lua:535: in function 'AH.ShowCrossingHelper'
<Locals> bypass = T, frame = ud, defaultY = 208.16664632161, defaultX = 896, onMouseUp = user:/AddOns/ArchiveHelper/ui/ui.lua:489, ordinals = [table:2]{1 = "Début"}, box = 1 </Locals>
[string "ArchiveHelper.ShowCrossingHelper(true)"]:1: in function '(main chunk)'
/EsoUI/Ingame/SlashCommands/SlashCommands_Shared.lua:10: in function 'fn'
<Locals> txt = "ArchiveHelper.ShowCrossingHelp...", f = [string "ArchiveHelper.ShowCrossingHelper(true)"]:0 </Locals>
/EsoUI/Ingame/SlashCommands/SlashCommands_Shared.lua:347: in function 'DoCommand'
<Locals> text = "/script ArchiveHelper.ShowCros...", command = "/script", arguments = "ArchiveHelper.ShowCrossingHelp...", fn = /EsoUI/Ingame/SlashCommands/SlashCommands_Shared.lua:8 </Locals>
/EsoUI/Ingame/ChatSystem/SharedChatSystem.lua:1695: in function 'SharedChatSystem:SubmitTextEntry'
<Locals> self = [table:3]{isAgentChatActive = F, isMinimized = F, loaded = T, currentNumNotifications = 0, numUnreadMails = 0, ignoreTextEntryChangedEvent = F, isMinimizingOrMaximizing = F, shouldMinimizeAfterEntry = F, currentChannel = 0, maxContainerWidth = 2192, suppressSave = F, minContainerHeight = 170, maxContainerHeight = 1248.9998779297, minContainerWidth = 300, allowMultipleContainers = F}, text = "/script ArchiveHelper.ShowCros...", valid = F, prefix = 47 </Locals>
/EsoUI/Ingame/ChatSystem/SharedChatSystem.lua:2433: in function 'ZO_ChatTextEntry_Execute'
<Locals> control = ud </Locals>
ZO_ChatWindowTextEntryEditBox_Enter:3: in function '(main chunk)'
<Locals> self = ud </Locals>
Sorry - stray bit of code there from when I was trying to change the background colour of the dropdown (which I spectacularly failed to do)
Thanks, I've removed the line and will be testing soon.
Edit: Also need to comment line 547: frame["box" .. box].SetBackground()
Sorry - stray bit of code there from when I was trying to change the background colour of the dropdown (which I spectacularly failed to do)
Argh, I thought it would require a simple change of colour, otherwise I wouldn't have requested it.
Edit: I now see every drop-down in the game UI has the same level of transparency. It's probably not designed to be changed. Sorry for the loss of time.
Both players can change their drop-downs, data is shared correctly (debug prints match) but the receiver drop-downs are not updated.
We tried a few times from outside and inside the archive lobby or wing, we sometimes got this error when selecting a value in a drop-down:
bad argument #3 to 'string.format' (integer expected, got nil)
stack traceback:
[C]: in function 'string.format'
user:/AddOns/ArchiveHelper/ui/ui.lua:425: in function 'AH.CrossingUpdate'
<Locals> box = 1, value = 2, solutions = " 2 5 1 4 3..." </Locals>
user:/AddOns/ArchiveHelper/ui/ui.lua:542: in function 'callback'
<Locals> value = 2 </Locals>
user:/AddOns/ArchiveHelper/ui/ui.lua:278: in function 'callback'
/EsoUI/Libraries/ZO_ComboBox/ZO_ComboBox_Base.lua:245: in function 'ZO_ComboBox_Base:ItemSelectedClickHelper'
<Locals> self = [table:1]{m_sortOrder = T, currentSelectedItemText = 2, m_name = "ArchiveHelper_choice1", m_containerWidth = 135, horizontalAlignment = 0, m_sortsItems = T, m_height = 250, m_font = "ZoFontGame", m_enableMultiSelect = F, m_spacing = 0, m_isDropdownVisible = T}, item = [table:2]{id = 2, name = 2, enabled = T}, oldItem = [table:3]{id = 7, name = "", enabled = T}, selectionChanged = T </Locals>
(tail call): ?
(tail call): ?
/EsoUI/Libraries/ZO_ComboBox/ZO_ComboBox.lua:144: in function 'ZO_ComboBox:SetSelected'
<Locals> self = [table:1], index = 2, item = [table:2] </Locals>
I've picked the colour of the blue used in the Cyrodiil player rankings (#76bcc3) so that it can be used for the CROSSING_PATHS string to replace the bright yellow under the drop-down list. The corresponding values are: 0.46, 0.74, 0.76
I now see every drop-down in the game UI has the same level of transparency. It's probably not designed to be changed. Sorry for the loss of time.
Really not a problem - often there is a way to override things like this, but in this case I've been unable to find it
Both players can change their drop-downs, data is shared correctly (debug prints match) but the receiver drop-downs are not updated.
I had another go at both these issues
We tried a few times from outside and inside the archive lobby or wing, we sometimes got this error when selecting a value in a drop-down
This should be resolved now too
I've picked the colour of the blue used in the Cyrodiil player rankings
Applied
I'll be testing the code updates soon.
I have tried to patch the shorter solutions by adding a 6th void item to the formatted solution and it seems to work.
Unless you prefer to keep shorter solutions centred, feel free to use it or perhaps rewrite it in the form of a loop that would work for any shorter length (in case Zos adds paths of length 4, but as long as we don't add them as possible solutions, it won't go unnoticed).
With this morning's latest version, with debug=true, it neither displays debug prints nor performs data sharing when changing the drop-downs values (inside or outside the archive lobby)
Whoops - should be ok now
Whoops - should be ok now
We did a quick test outside the archive, data sharing and debug prints are back but it doesn't change the drop-downs values of the other player. Note: if the drop-downs are not designed for, maybe they should be disabled and not updated for the non-leader, and he should just see the solutions.
The capability is there - just something wrong with the response to the data share - I'll look into it
OK - reworked the response, should hopefully work better now
No, still no result on the other player's panel. I'll try to add some debug prints after data reception, to see if I can provide some information on this problem.
Edit: when tried in the lobby, both players had their drop-downs enabled. We have run through the Echoing Den (gender/plural texts are correct), the debug print "Received sharing notification" has appeared (it didn't until then). We then tried to open the helper again, this time the non-player controls were properly disabled. So maybe it's a initialisation problem in debug mode. Will update if we can test it in the Crossing level.
I have noted two problems:
After adding more debug prints, I noted that if the leader select a value for the first combo box,
Edit: a special case should be made if all three boxes are empty. Find should stop immediately or all paths would need to be returned (note: the solutions should be cleared, rather than displaying the "no paths found" message that could be confusing because in fact, too many paths are possible.)
Two minor details:
You are testing AH.Vars.ShowHelper in ShowCrossingHelper(). So, the player can't use the keybind or the slash command at all until they activate the setting. I'd rather thought that the setting meant that the helper opened up by itself in the hidden level. I'd rather check AH.Vars.ShowHelper in the function zoneCheck() to condition the call to the ShowCrossingHelper().
If the helper can't be opened via the keybind or the / command, it would be user-friendly to display a log message to explain why, otherwise the player might think that the add-on isn't working properly or that he's typed an incorrect command (that's the first thing that happened to me this morning when I logged on in Summerset to do my craft). The message should explain the helper can only be used in the Treacherous Crossing level in the Infinite Archive. (and/or if the setting is on or not, depending on how point 1 is resolved)
By giving the lead to another player in the group, while in Grahtwood (with debug enabled):
user:/AddOns/ArchiveHelper/misc/events.lua:398: attempt to index a nil value stack traceback: user:/AddOns/ArchiveHelper/misc/events.lua:398: in function 'onLeaderUpdate'
ok - should now have accounted for all the above - fingers crossed...
Data sharing works. No error by transferring leadership. Will try again shortly in real conditions, in the archive without debug mode.
L(AH .. "CROSSING_INVALID", "L'aide ne peut être activée qu'à l'intérieur du Gué traître dans l'Archive Infinie")
Another small suggestion about the settings: REMINDER_QUEST (option[12]) could be moved up in the menu to be grouped with REMINDER ([7]). Both are reminder texts that can happen everywhere in the archival wing. Then everything related to hidden levels would follow.
Awesome - thanks again for all the testing. Just done another push with your last two comments
Awesome - thanks again for all the testing. Just done another push with your last two comments
My pleasure. And thank you for your continued patience in sorting out the small details.
I may have made a mistake and got the index wrong. I shouldn't be typing suggestions while I'm playing. You moved up the SHOW_CROSSING_HELPER setting, instead REMINDER_QUEST. It should have been index 11 and not 12, perhaps. Sorry for the confusion.
Ha - I didn't even bother looking at the text, I just used the numbers - that will teach me to pay more attention :-)
It looks good now. Great idea to have added a "target markers" section, it makes the settings more distinct and easier to find. I would swap GW_PLAY and GW_MARKER (17 and 18), so that marker can be found before play, because "play" can be disabled by "marker" , hence is secondary.
Also a swap of MARAUDER_INCOMING_PLAY and MARAUDER_MARKER (19 and 20) because now that the section is about markers, it's more logic to present the marker first.
I promise to stop after that. Beautiful, well-organised UIs are my guilty pleasure.
I appreciate attention to detail - the only reason I have them the current way around is so the marauder icon is at the bottom of the list, otherwise it looks a little out of place. That being said, your idea makes more sense - I'll give it some thought.
OK - I've thought about it :) I've moved the icon to the other side of the text
No luck tonight. 3+2 arcs, we got every hidden levels except the (aptly named) treacherous crossing.
I noted that the tomeshells count did not take into account the plural. There are two calls in functions tomeCheck(), startTomeCheck() that still use the first version of the formatter:
local message = zo_strformat(_G.SI_SCREEN_NARRATION_TIMER_BAR_DESCENDING_FORMATTER, tomesLeft)
instead of
local message = zo_strformat(_G.ARCHIVEHELPER_TOMESHELL_COUNT, tomesLeft)
Unless it's an emergency, I suggest not doing a release for the moment. I've noticed a quirk with the drop-down lists: they're not updated visually when data is received, but the value is taken into account logically during following filterings.
I would like to properly test whether they are correctly disabled for the non-leader and whether they reset if leadership is transferred, which would hide the drop-downs problem mentioned above.
We'll try again tomorrow but my archive partner has to stop for tonight.
Another small settings adjustment: SHARD_IGNORE (16) should be disabled if SHARD_MARKER (15) is off.
Question/bug: currently, SHARD_IGNORE and SHARD_MARKER settings are disabled if "not AH.CompatibilityCheck()". Is it correct? I remember you said Lykeon's add-on should only disable Fabled detection.
All sorted - another push done to github
I have noticed that the Treacherous Crossing has only a few different possibilities. Maybe players would be happy to have a slash command such as /ah crossing that would list the different combinations. Or /ah crossing 1 would list the combinations beginning by the first switch (from left to right).
So far, here are the combinations I've noticed:
L or R means turning left or right at a fork in the road. I don't know if it widely known or not but it would probably be a good helper ;)