A.J.

Nice to see you again!

...I know you... *poke*

Out of curiosity, I did few more tries and it's not the only strange thing of ShowMessage. If you put the same in the lower box (the one to make a menu), it will want a "time" value as first parameter, which makes no sense. However it won't CTD since it seems to ignore the format notation. While on the upper part (the message one), %n is not the only one ignored. I just tried a carriage return and it doesn't work.

That thing on the wiki was written in the days of FOSE, it's relative to FO3, it would have been interesting to test it with it. I just tried but my FO3 decided to refuse to start and I've got not much will to reinstall it.

Mmmh could it be because ShowMessage is a vanilla function while %n was added by the extender, so vanilla doesn't expect it? or you mean it's a matter with Let, because if you Set it works?

 

I've read in several other threads that "archive invalidation" is often the issue for textures not loading correctly. I never had such issues when using mod organizer for Skyrim.

Do you have the AI bsa on the top of the Archive list?

Exactly. The way a texture is "painted" over a model is called UV map. When a texture is completely different, like you can notice in your case, it means that the model is different, because it has a completely different UV. You still can put the texture, but as result you will see that the texture is not aligned as it should, and that's why the eyes are shifted in game.

no load order problem, it's all in this:

If the UV will be different, then well... uhm we'll see...

...

basically the texture of the eye is made for another 3d model eye. It should be manually replaced, pffft...

You should check the eye mod description if it tells you something more, like "these eyes can be used as replacer for this mod: ....", or better, check if inside the eye mod archive there's a model of the eye, it should be a nif file

EDIT: oh wait, because I'm assuming that Moonshadow is using the vanilla mesh, while it could be that it doesn't. However you got the point, the two mods use a different eye model, so it should be manually replaced. After that operation, you will probably have the opposite effect with the actual eyes - they won't work properly anymore

If you want to use assets from a plugin on another plugin, the first one should be an ESM and be master of the second one. I guess you would have two possibilities: open Moonshadow and create new eyes from scratch, pointing the path to the eyes folders of the eyes mod; or making the eyes mod an ESM, and then use it as master for Moonshadow (which is what you are doing now, but since the eyes mod it's not an ESM it doesn't work)

EDIT:

ok I fired up the GECK to write you few steps to see if you can solve on your own:

- Open the eye mod (and not Moonshadow)

- Go on top on menu Character - Eyes

- Identify the added eyes, check the path of the texture and write it down

- Make a copy of Moonshadow ESP, just in case

- Now open Moonshadow and click on Active, so that the modifies will be saved in the esp

- Go on top on Character - Eyes, Right click on a empty space and choose New

- Create your eyes, pointing to the textures of the eye mod, the ones you checked in the first steps

- Drag and drop these new eyes on the Moonshadow race as you usually do, save and try in game. You don't need to activate the eye mod ESP, because you added those eyes directly inside the moonshadow esp

If the UV will be different, then well... uhm we'll see...

Is Moonshadow a ESM or a ESP? I assume you are opening both in GECK but which one is setted as active? or you are creating a third file, like a patch?

 

Of course, the above statements only apply so long as noone posts a way in which this can be easily implemented without the need to alter any vanilla assets.

 

There are at least 2 ways I could think to script that.

One, I did it few months ago for a mod, but never had the time to test it properly.

The second probably is easier but requires JIP NVSE.

Maybe it could deserve uploading the script as separated ESP if some people have a need like that, so more mods could use the same function without cluttering the game with extra scripts that do the same thing over and over. What do you think?

(Without taking in consideration a scripted solution) you can do that if the eye is a ESM and your modified plugin will then add it as new master on the header

 

Okay, GECK/NVSE really needs some well organized manual, otherwise you just tend to learn a useful function after you've already created a couple of ugly script crunches

A certain amount of NVSE documentation was written by a daemoness who gathers power more you struggle and bang your head against the monitor.

And another amount was written by Odessa, so careful to what you write or I'll shoot you on sight.

I'm kidding of course.

Fishing on lake vegas

https://www.youtube.com/watch?v=Btb7Hcl0BKw&feature=youtu.be

I know you can restore some windows default settings erasing GECK inis inside My Documents - so in the same way, maybe there are specific lines to add to the inis so that the windows are bigger? I really don't know, I never had reasons to poke with that...

yes I find it a pretty dumb function, it seems it returns a correct value only the first time. This big limit allows it to be used only in those very specific cases like triggering a menu in gamemode, so today 90% of the times I abandoned those types of menus in favor of other solutions

You can add the console to the menumode list of exceptions you did. But console shouldn't be considered as exception by mods, in my opinion: those who use a console must take the responsibility of their actions

 

Unfortunately, just comparing array size won't be enough since you can easily fire a companion and hire a new one pretty quickly. And the mod is also supposed to store "former companions" in a separate array.

It wouldn't be a big problem, since the dialogue would trigger and you would compare the arrays anyway. I was thinking that comparing the size would be only for extra events in game mode that you can't expect.

 

If you can't find anything better, the first thing that comes in mind is something like this, which executes the code every end of a dialogue

Hmm, seems like a way to do it, thanks! Although will not fire if some (3rd party?) companion is added/removed by a script, or is auto-fired on reaching wait limit...

 

No, but you can't have everything

The auto-fire could not be a problem on itself, everything which is vanilla could be studied and scripted properly. I.e. they set those umanoid /non umanoid variables, you could check these instead, but just to make an example. In my opinion the real problem are those external factors (=mods) where you can't really foresee the behaviours, how they were modded and what they do. If you want to be sure, I still believe the best would be a gamemode on Default quest delay, even if like you say 99% of times that script is unuseful, there are far too many external factors that could influence these kinds of relationships. At that point, I would try to focus on reducing the most I can the operations every <default time> seconds to compare the arrays, i.e. I wouldn't really need to compare the elements of the arrays but only the size for example, pretty sure that an operation like ar_size is unpercettible under a point of view of performances.

If you can't find anything better, the first thing that comes in mind is something like this, which executes the code every end of a dialogue

Begin MenuMode 1009

   Let bIspokeWithSomeone := 1

End


Begin GameMode

   ...

   if bIspokeWithSomeone 

      Let bIspokeWithSomeone := 0

      ; compare ar_sizes

      ; if ar_size is different >>> someone new was hired >>> do the rest of the code

   endif

...

End

I remember some thread some time ago where people were explicitly claiming "I don't see a valid reason to NOT make a BSA". While for FONV I would have had some reason, that was for Skyrim. As Skyrim's lover (but Player only), I would be really curious to understand if it really increases performances, because it's not hard to reach 30 Gb of mods datas, I guess even the smallest difference in terms of performances could make a big difference in the playability / fps when the numbers are so big

This is a very interesting thread. Are these considerations about BSAs valid for FO and Skyrim too?

There's a Skyrim guide in my language, after installing all the mods (i.e. texture replacers) it shows how to package everything inside a BSA. Do you believe it's a nice move to do or not?

 

And as A.J's suggested solution uses topics you have the background ... and the possibility to click through the conversation.

 

Another nice positive feature is that it requires time to make the whole thing working, like triggering the goodbye and spinning the camera. As result, there's more delay to read subtitles. If you like me can't live without subtitles (due to not understanding and speaking spoken english) you know how annoying is when you don't have enough time to read them...

Good R.J. Helms, he was a very good inspiration for me. His quests are amazing. Long life to R.J.Helms

The way to build a conversation as it's explained on the wiky isn't bad, it usually works. Then there are a couple of more tricks that could help, like SayToDone, but yeah the problem with subtitles will remain, but what can you do against that? the only solution would be voicing them.

It would be nice if the courier could be forced to look at the NPC who is actually speaking, and it would be nice if the NPCs would look at each other, maybe sometimes look at the courier in the moment they are speaking about him/her.

The way I do this is different, I saw that in Beyond Boulder Dome and used for my mod too. NPCs are not conversating, they still will talk with the player, but referring to each other (so it's like if they are conversating). To explain better... imagine a npc on a edge of a room, and another one on the other edge. You Player arrive more or less in the middle of them, the first one will start talking to you, your camera will force you to look at him, he is looking at you but since the other npc is on the opposite, you could even think that he is looking at the other npc. After he speaks his line, the dialogue has a Goodbye flagged, and as result script there's a SecondNPCREF.StartConversation Player NextTopic, so at that point your camera will make a 180 degrees spin and will force to look the other npc, which will talk to you but still it would be like if he is talking to the other npc, etc.etc.

Hope you can get what I mean, or I'll try explain again. This method's very easy and works flawless. However, you can make in different ways, of course, both with animations (your player will look at the one who is speaking because you are calling a specific animation on the player) or via script (you turn your head using GetHeadingAngle, and then SetAngle X to change the vertical angle).

I guess there's a global that can be modified to make them less heavy

Some time ago I did a small ESP to test timing.

I introduced 5 quests and a spell.

The quests had a difference delay (0.1 - 0.01 - 0.0001)

The fourth and the fifth quest had 1 and 99 of priority

The spell had both a GameMode and a ScripfEffectUpdate block.

Some results were expected, some weren't:

- I know priority is used in dialogues for the position of the line, but I always thought that priority, when scripts are involved (i.e quests and perks) was deciding the order of execution of that script inside the same frame. Instead this test denied it: with 1 or 99 priority, the order wasn't changing at all, and the quest with higher ID was executed before (and I also thought the contrary, like lower IDs were executing before)

- The other values were more or less expected: inside the same frame, it was first executing the spell, then the 0.0001 delay, then the 0.01 delay; the 0.1 was executed every 6 frames (running at 60 fps)

- No timing difference at all between a GameMode and a Effect block