Hm, I didn't know that. It seemed to work fine here. Here's the code used now:

if (CloverREF.CombatStyleRanged)	SetUIString "HUDMainMenu\_followerSlot7CStyle" "Ranged"else	SetUIString "HUDMainMenu\_followerSlot7CStyle" "Melee"endif

You're saying this won't work reliably?

---

For HUD display, you could always make a small esp to handle that separately from the rest of the mod. Should be a very short&easy script when I get the kinks worked out.

That sounds cool! May I ask how you generally implemented it so that multiple mods can add new menus dynamically? Because one of my mods adds a new meter to the hud (see http://fallout3nexus.com/downloads/file.php?id=11025). But to enable this meter, it has to be included in
the hud_main_menu.xml, which leaves me with 3 options:
- Either package a modified hud_main_menu.xml for every different mod out there that modifies it (vanilla version, dui version, fook version) => svcks
- Have the users manually add the entry => well... svcks too, but if there's no other way..
- Automatically insert the include with a FOMOD script , which is what im doing right now, but still, there are users who don't use FOMM.

It would be much better if there was a way so the meter could register itself somehow without having to make static modifications...

That code won't be accurate. Check the combatstyle directly instead. I know FOSE has a function for it. That variable only indicates what the player wanted the follower to be set to, and at the very first application of the command it worked, but the follower itself in my experience will not match that after the game has been reloaded. In vanilla, the player needs to go back into the tactics dialogue each time if he wants the follower to keep using a melee-specific combat style.

hmm so the small .esp that added the HUD would require FOSE but the main mod would not? that's interesting.

If I may, how something like this works, in a nutshell:
- An interface mod provides empty forms, like ... etc

- Then there's your mod that generally keeps track of it's settings in quest vars (without FOSE)

Whats needed is a glue .esp, that reads the data from your quest vars and writes it to the hud (with FOSE functions).

normally this shouldnt require any changes to the original mod.

It's all a theory at this point. For these things to be dynamic, you'd had to have a full set of menus present, which could be enabled and filled in from script. The simple follower hud system is done that way, but a menu like this will be much too complex for that. At some point files will have to be copied to their destinations, an include will have to be made to a file. The idea I had was to make a list in which mods could add themselves, and have their menu show up when their entry was clicked. This part could be done from script. If made right, the system could only require a single include somewhere. Whether it be by fomod script or user interaction, this is required. FOSE doen't enter into the picture until after includes are processed I think.


Ok, thanks man.


Sure. Just separate all the UI stuff from the rest.


These are present in the HUD:

<_followerSlot1Visible> 0 </_followerSlot1Visible><_followerSlot1Health> .1 </_followerSlot1Health><_followerSlot1CStyle> CStyle1 </_followerSlot1CStyle><_followerSlot1Action> Action1 </_followerSlot1Action>

Script finds available slot, sets it's health, cstyle and action, toggles it's visibility. Easy. If this is a separate esp, depend on the master you need to read from, detect if DUI is installed, read&write.

btw, in Phalanx, you could have a maximum number of followers present at the same time as being 11. Two slots only wouldn't be so meaningful.. . Also, something must check distance from the player before being willing to show any stats on the follower, with only followers whose distance is 1000 or less showing up.

The max is currently at 8 slots. Making more is easy, but the HUD would look bloated I think. I suppose I could make a compact display of sorts.

Why is the distance from the player important?