I can't piggyback on the icons in flash files, because Soulsy is native code + imgui and not flash. But I could contact the author of one of the icon mods and ask if I can use their icons extracted as svg.

This set in particular

https://www.nexusmods.com/skyrimspecialedition/mods/89241

The utility item is the one case where it matters when the topmost item is removed.

It would be nice to have drop shadows or text specific background for easier readability. At the moment, the text can be harder to read depending on the game world light level/texture.

The brief peek is the term in the HUD rendering code for the HUD showing itself briefly if it's hidden when you cycle. It needs to become visible much more quickly. It can fade out using the player's setting for fade-out, but it needs to become visible faster. It should still use the easing function to slide in nicely.

Investigate, repro, fix.

Take the global setting and make it be per element. Easy to do. The only thinking required is in making it back compat with older layouts.

IDGI.

Because this is how archers IRL do it. The easiest way to do this by far is to do a variation on the swap I'm doing right now with arrows and the left hand:

• ammo ➜ right
• right ➜ left
• left not drawn

This is independent from the OCF work, because the OCF keywords do not cover spells AFAIK. There might be an additional project that does, in which case I should support it. In the meantime, I should push the work in the icons branch all the way forward with spells.

I'll want to keep the deserialization for a while, but we want to stop writing fresh TOML in version 0.9. This will in turn allow me to clean up the fairly awful bincode serialization shadow structs.

This is a little funky with picking a hand. Some selections obviously go into one slot or another, but for spells and one-handers I think it'll need either a preference or just letting the user override afterward.

It should theoretically work with CommonLIbSSE-NG, but I might have messed something up.

When you stand and ready your weapons again, the left hand item is not properly re-equipped. E.g., a torch in the left hand won't start burning again. The un-equipping is happening out of band of the HUD, possibly? I'm not sure why it's not just a regular weapon un-ready. Need to look at logs.

So they can be translated. Some implementation notes:

• They don't have to be the same translation files as the MCM strings. They can be in their own UTF-8 files.
• Parallel structure to the MCM translation files, though. One per language, in the same directory, named for the mod.
• Format strings themselves will need work. Numbered parameters, for instance.

The keyword reference is in their wiki.

Tasks to get this done:

• Generate useful enums from relevant keywords. Probably these will have to be shared enums. Segregate them from the API bridge, probably with a separate cxx bridge. Sigh.
• Update the ItemKind enum to include additional categories as it makes sense. Note that the core list has to remain and remain in the order given because the repr value for icons is used in persisted cycle data.
• Rename icons to match the derived display strings from the OCF-matching enums. This will make life better in the long term.
• At item entry creation time, look up keywords for spells, weapons, and armor. Assign icons based on keywords. Fall back to game data icon assigment.
• Implement on-the-fly coloring for icons, not preset in layouts. Alpha transparency will be respected still, however.
• Look up coloring using color keywords. This varies by category. E.g., ammo colors vs spell colors.
• Map icons to categories. Remove all item coloring from icons and use white svgs, so on the fly coloring works.

Use the existing ceej/icons branch for this work.

It would be better to prevent the player from doing this than to let the confusion happen afterward. Right hand takes priority, I think.

• The HUD briefly fades out at launch, no matter what your setting is.
• It doesn't remember last-visible state. Store this in the cycles file, probably.
• The show/hide key sometimes doesn't work, and I think this is related.

The entire fade-out implementation needs a look-over and probably a simplification.

This design can probably piggy-back off whatever I end up doing for enchanted items: some kind of filled bar that ticks down over time.

Write it in markdown here and update the settings article on the nexus mod page.

This is pretty hilarious. I might as well let you cycle when you have only 1 item.

Specifically:

• logging directory
• player name
• item names

Commit 4247a38 does the bulk of the work required for the fix, but it needs to be built on Windows and tested.

I get a crash to desktop whenever I equip a ring or amulet.
This happens with both vanilla and modded rings/amulets.

Here are the top few lines from the crash report, though I don't know if it will help.

PROBABLE CALL STACK:

[ 0] 0x07FEBF8F7069  SoulsyHUD.dll+00E7069	cmp [rax+r8*1], dil |  C:\Users\ceej\source\repos\ceejbot\soulsy\src\game\equippable.cpp:248 ?collect@KeywordAccumulator@equippable@@SA?AW4ForEachResult@BSContainer@RE@@AEAVBGSKeyword@5@@Z
	

[ 1] 0x07FEBF94169C  SoulsyHUD.dll+013169C	test eax, eax |  ?ForEachKeyword@BGSKeywordForm@RE@@QEBAXV?$function@$$A6A?AW4ForEachResult@BSContainer@RE@@AEAVBGSKeyword@3@@Z@std@@@Z_13169C
	

[ 2] 0x07FEBF8F6160  SoulsyHUD.dll+00E6160	mov rcx, rdi |  C:\Users\ceej\source\repos\ceejbot\soulsy\src\game\equippable.cpp:134 ?hudItemFromForm@equippable@@YA?AV?$Box@UHudItem@@@cxxbridge1@rust@@PEAVTESForm@RE@@@Z
	

[ 3] 0x07FEBF940666  SoulsyHUD.dll+0130666	mov rax, [rsp+0x20] |  C:\Users\ceej\source\repos\ceejbot\soulsy\target\cxxbridge\soulsy\src\lib.rs.cc:1433 helpers$cxxbridge1$formSpecToHudItem C:\Users\ceej\source\repos\ceejbot\soulsy\target\cxxbridge\soulsy\src\lib.rs.cc:1447 helpers$cxxbridge1$formSpecToHudItem
	

[ 4] 0x07FEBF8757D1  SoulsyHUD.dll+00657D1	movups xmm0, [rax+0x60] |  _ZN6soulsy4data10item_cache9ItemCache16get_with_refresh17h7808334febc6c33cE_657D1
	

[ 5] 0x07FEBF86B9B7  SoulsyHUD.dll+005B9B7	movzx eax, byte ptr [rbp+0x2A6] |  _ZN6soulsy10controller7control10Controller20handle_item_equipped17h8105c115dfaee55eE_5B9B7
	

[ 6] 0x07FEBF8446DE  SoulsyHUD.dll+00346DE	mov ebx, eax |  _ZN3cxx6unwind14prevent_unwind17ha00217cc511c0f0dE_346DE
	

[ 7] 0x07FEBF815C5D  SoulsyHUD.dll+0005C5D	nop |  cxxbridge1$handle_item_equipped_5C5D
	

[ 8] 0x07FEBF92048D  SoulsyHUD.dll+011048D	lea rcx, [rsp+0x20] |  C:\Users\ceej\source\repos\ceejbot\soulsy\src\plugin\sinks.cpp:52 ?ProcessEvent@EquipEventSink@@MEAA?AW4BSEventNotifyControl@RE@@PEBUTESEquipEvent@3@PEAV?$BSTEventSource@UTESEquipEvent@RE@@@3@@Z C:\Users\ceej\source\repos\ceejbot\soulsy\src\plugin\sinks.cpp:75 ?ProcessEvent@EquipEventSink@@MEAA?AW4BSEventNotifyControl@RE@@PEBUTESEquipEvent@3@PEAV?$BSTEventSource@UTESEquipEvent@RE@@@3@@Z

I visualize this as a stick figure in the center of the screen with icons radiating outward from it.

I haven't seen this, but it has been reported. Repro is probably going to be spending a lot of time on the maintenance page.

They fall to the floor instead of going into the display. WTAF.

I now understand why iEquip did this the way it did, and I am going to borrow their approach.

• Add a boolean setting for auto-including unarmed options in left & right hand cycles.
• Update cycles when this setting toggles.
• Make sure the update gets flushed to disk.
• Test both removing and adding.

Commit fdccbf7 implements most of this.

Take some inspiration from iEquip here, I think. A green or purple droplet would be great.

Consider adding on-the-fly colors from item statuses to hud draws.

Spell in left; two-hander in right. Switch to same spell on the right. Sadness ensues.

A brief highlight flash on a changed slot OR a slot that's cycling and in mid-timer has been requested by several people.

People seem okay with the fade-in time. One request asks to sync it with iHUD, which is a reasonable thing to want.

There's code to draw the spell properly but none to handle bound weapons. Figure out what the game is reporting in this case and find a way to show the same bound weapon display in the relevant hand.

I might want to add an item kind for each variety of two-handed spell. By this I mean a spell that requires two hands, not merely one that can be dual-wielded for more damage.

It's far easier for me to cope with, and very easy to inspect out of game, but doing it this way has some drawbacks. The file sticks around when characters are deleted. Old files stick around when a character is renamed. It cannot roll back to a previous state if the user re-loads a save, though the cycle will be re-validated.

My laziness says to leave it as-is, but it bothers me.

Version used - v0.8.3

Hi, I have encountered a CTD that may relate to Soulsy HUD. The crash happened at the start of a fight when I tried to equip a scroll of mass paralysis, and the game crashed instantly with the following crash log. The scroll was not added to any slots of the Soulsy HUD and is directly accessed through inventory.

Crash Log

I narrowed the problematic scrolls to those that use both hands (e.g., Mass Paralysis, single-hand scrolls can be equipped with no issues).

As I tested more, it does not matter what weapons the player uses/equips. As long as I switch to a scroll that will use both hands, the game CTDed with the crash log above.

This can be seen easily if you turn off auto-fade and make the HUD visible by hand.

All ini-reading code is now implemented in Rust.

In particular, test using a two-handed weapon with the single-hand grip. If there's a spell in the left hand, cycling that hand will force a change in the right to a one-hander. This is obviously wrong when CGO is up.

Things to figure out: How to tell if CGO is present. How to tell if CGO is in grip-switch mode.

By equip sets, I mean items that are equipped together. For example, a one-handed sword + a shield.

This is especially important for controller users.

Both in the repo and on the Nexus.

It skips arrow types and it doesn't filter ammo appropriately. As in, it includes bolts when it shouldn't, and so on.

I think the right solution is going to be to build an ammo list when the ranged weapon is equipped, and manage it on the Rust side until it's unequipped. Trying to be stateless isn't sparking joy atm.

This is more of an investigation than a feature spec. helpers.cpp has notes on how to add and remove keywords from forms on the fly. Is there a way to use these keywords to control how an item is displayed in SkyUI? The inventory menus show is-favorite and is-poisoned, but those are built into the game. Would this have to be built into the flash for a menu?

And suppress the cycle keys if relevant. Figuring out "relevance" is going to be tricky.

It seems that in v0.7.1, the default "unarmed" is missing for both left and right-hand cycles, and when you only have exactly one item added to either cycle, pressing the corresponding cycle key will not change the desired item.

Example:

Iron Greatsword added to right-hand cycle (the only item)
Equip iron sword in the right hand
Press Cycle Key (e.g., mine is 4)
Player will not equip Iron Greatsword

Something as simple as a green or purple colored droplet icon for poison plus a filled bar for enchant charge would work. However, this is an addition to the left and right hand hud widgets that is not applicable to the others. It also needs design for what aspects of the widget need to be controlled by the layout.

Some of this code is left over from the initial fork and I don't think it's working very well. Simplify.

Hide the hud when out of combat: toggle

Autofade time: shown & honored if toggle enabled.
HUD show/hide key: shown and honored if toggle disabled.

It's possibly this simple, but the code is evolved and tangled.

Looks like I left it out of settings.ini x.x

I could do what LamasTinyHud does here, and have a font file item in the layout spec for each locale the game is built for.

This will make long press actions a lot snappier because they'll fire on computer timing, not on a human guessing how long to hold a key down.

I have this maybe 80% implemented in latest starting with commit e179f21 .

To repro: Get arrested and go to jail. The cycles don't update and you might lock up.

Probably there's an event I need to handle better? I would think this would go through the usual inventory-changed or equip-changed event paths, but maybe I'm not handling these two the same way. In which case that would be the bug.