NAF Bridge

[dav42]

7 minutes ago, Evi1Panda said:

I guess you're right again. Sorry, it was a 6-7 of months ago when I wrote this script, and it uses some complex constructs, and sometimes it is difficult to understand what I've been writen there and why)))

 

I have written some complex software and came back to it later and had no idea what I was doing or why, so I totally understand where you are coming from. 

[Evi1Panda]

31 minutes ago, dav42 said:

 

It does not seem to work then.  However, if I move UpdateActorOverlay outside of the condition (setup.duration > 0) they are applied.  Any ideas on why that would be?

 

Does Overlays.Update(akActor) need to be called after Overlays.Add for the overlays to be rendered on the actor?  Because that seems to be what UpdateActorOverlay does eventually.  Not familiar with the Overlays API.

 

This does appear to work when duration = 0 when a mod calls AAF_API.ApplyOverlaySet.

int UID = Overlays.Add(akActor, setup.isFemale, newEntry)
			if (setup.duration > 0)
				...
			elseif (update)
				UpdateActorOverlay(akActor);	
			endif

 

I guess there is should 'elseif (update)'
but seems like correct idea.

Reuploaded with this. Thanks again!

[Here4SlootyMods]

Can you push the fixed changes to your github repo too? Good to have for later.

[dav42]

For the F4SE plugin modifications, are you building that the same way upstream NAF is with cmake?  I was able to build NAF from source with a few tweaks for the latest VS22, but trying to use the same process on the fork has a few issues:

 

#1 needed include for ${CMAKE_CURRENT_SOURCE_DIR}/extern, apparent dependency on DiverseBodiesRedux/Hooks/FixedString.h

#2 needed to remove /WX, there are several cast warnings that are treated as errors.

#3 needed to add extern/Bridge/Bridge.cpp, extern/Bridge/Papyrus/Papyrus.cpp to SOURCES (sourcelist.cmake).

#4 patch for CommonLibF4 compilation with VS22 (https://github.com/shad0wshayd3-FO4/CommonLibF4/commit/c7295d014284a346d7dc2a2546e3eb284fadafff.patch)  -- NAF also required this

#5 change cmake_minimum_required for ik (3.2 is deprecated with later versions of cmake) to 3.20.  -- NAF also required this

 

It did manage to compile a DLL, the DLL loads and mostly works (meaning no crash, and one animation played) except for this in the log:

[02/16/2025 - 12:45:44] [error] failed to get type info for structure
[02/16/2025 - 12:45:44] [warning] failed to register method "GetOverlay" on object "NAFBridge"

 

I haven't really dug into that.

 

Edited February 16, 2025 by dav42

[dav42]

Here is what I was working on:

 

 

NAF (extra logging):

[02/16/2025 - 18:24:19] [info] kInvalidActor
[02/16/2025 - 18:24:19] [info] ActorIsAlive, lifeState 6

 

NAF Bridge:

20250216182420 : BRIDGE :  0.906000 : NAF EVENT : OnSceneFailEvent key : 1036
actors : [[Actor < (00000014)>], [Actor < (340371C0)>]]
cached index : 0, ARG1 : [1, "One or more provided actors are None/Disabled/Dead.", [[Actor < (00000014)>], [Actor < (340371C0)>]], "None"]

 

 

ActorState (according to CommonLibSSE) has the values:

    enum class ACTOR_LIFE_STATE : std::uint32_t
    {
        kAlive = 0,
        kDying = 1,
        kDead = 2,
        kUnconcious = 3,
        kReanimate = 4,
        kRecycle = 5,
        kRestrained = 6,
        kEssentialDown = 7,
        kBleedout = 8
    };

 

It seems to me that perhaps this function should be changed:

	static bool ActorIsAlive(RE::Actor* targetActor, bool require3d = true) {
		return !targetActor ? false : ActorIsEnabled(targetActor, require3d) && targetActor->lifeState == 0;
	}

 

perhaps it should be targetActor->lifeState != 2, I am not sure where state 4 & 5 come into play.  At least what I was able build was good enough to add in some more debugging to track this down.

 

NOTE: hacking this function to targetActor->lifeState != 2 does solve this issue for me, but I still have that overlay problem which I am assuming is maybe related to 0.904 sources or some bits are missing in GitHub.  But any case enough is there to debug this one.

 

Edited February 16, 2025 by dav42

[Evi1Panda]

@dav42 GitHub, CMake is something completely new to me, someday I'll figure out how to do it right.

I had a plans with update today,  I'll take a look at your notes and apply it too. There really was a trouble with actor alive check, perhaps it is. Thank you very much for your help!

 

[dav42]

15 minutes ago, Evi1Panda said:

GitHub, CMake is something completely new to me, someday I'll figure out how to do it right.

 

Yeah, cmake is quite the beast and I am definitely a novice with it (I probably got lucky to get this far, much more familiar with autoconf/automake but that's not sexy anymore), but you guys have a lot of the really hard stuff in the bag.  I just can't imagine the reverse engineering effort by countless number of people to make this sort of modding possible.

[dav42]

8 hours ago, Evi1Panda said:

I had a plans with update today,  I'll take a look at your notes and apply it too. There really was a trouble with actor alive check, perhaps it is.

 

I gave 1.0 a shot but it seems like it still has the same issue with the actor.  The code pasted in my comment above was the current function, so not sure if that was the issue, but this would be my suggestion for the fix:

 

static bool ActorIsAlive(RE::Actor* targetActor, bool require3d = true) {
    return !targetActor ? false : ActorIsEnabled(targetActor, require3d) && targetActor->lifeState != 2;
}

 

This did work in what I was able to test out.

[Evi1Panda]

7 hours ago, dav42 said:

 

I gave 1.0 a shot but it seems like it still has the same issue with the actor.  The code pasted in my comment above was the current function, so not sure if that was the issue, but this would be my suggestion for the fix:

 

static bool ActorIsAlive(RE::Actor* targetActor, bool require3d = true) {
    return !targetActor ? false : ActorIsEnabled(targetActor, require3d) && targetActor->lifeState != 2;
}

 

This did work in what I was able to test out.

 

Honestly, I wanted to sleep and didn't look into it, I thought it was already a fixed line and didn't even look that it was the same. Yes, I think the scene can run in all states except dead. I hope it's the same as Skyrim. I poked around the assembly code a bit, and it looks like at least the dying state matches.

[dav42]

49 minutes ago, Evi1Panda said:

Honestly, I wanted to sleep and didn't look into it, I thought it was already a fixed line and didn't even look that it was the same.

 

Yeah it can always wait for you to rest.   I figured it was because the message was a bit too wordy (hard to tell when it's too much, and not enough).

 

One other thing I noticed is apparently AAF will enable disabled references implicitly, NukaRide has one scene where the non-player ref is disabled and shows up as invisible in scene (I am a bit curious why it's not caught by the existing condition for that).  I don't think it makes sense to add that kludge into NAF Bridge, but figured I would mention it.

 

Confirming the re-upload from today is working.  Thanks.

 

Edited February 17, 2025 by dav42

[dosfox]

Hey @Evi1Panda!

 

Thanks a lot for all the Bridge & Naficator updates ! Things are mostly working a lot better ...

 

Unfortunately, since Bridge v.906 a problem has been occurring. There are many instances of animations where both NPCs are performing the same gender of an animation simultaneously, e.g.:

 

Spoiler

 

 

• Male & Female both doing female animation simultaneously.

 

• Female & Supermutant both doing male animation simultaneously (plus artifact off the supermutant - never seen before).

 

 

• Male & Female both doing male animation, with offset between bodies (rare).

 

 

The problem mostly occurs with Leito and AtomicLust animations. The above examples are near the end of the log file.

 

aaSUPF4SEDebugPrint_ETM_DUPE BODIES.txt

 

I am still using Indarello's Patch and Autonomy, but have never seen this bug before v.904 of Naficator/Bridge.

 

NAF_XMLs.zip

 

Hope you are having a happy new year!  ❤️

 

[Evi1Panda]

try to clear archive and rebuild NAFicator files. 

[dosfox]

6 hours ago, Evi1Panda said:

try to clear archive and rebuild NAFicator files. 

 

Yes! Thank you! That seems to have fixed the problem.

 

Another position-related bug has been around forever, but i've only just worked out what it is. Animations are being staged on original vanilla furniture that has been deleted during settlement modification, so animations are happening on "invisible" furniture. This is most noticeable in Sanctuary where i have scrapped all vanilla furniture, but occurs in other settlements too. Can Bridge check to see if original vanilla furniture actually exists before assigning animations to it?

 

[Evi1Panda]

It's a two-way street. You can check, but the problem is that furniture that is part of precombined models will return false. So I have removed this check for now. I have not yet figured out how to determine if a model is a member of a precombined set of models.

 

That is, you will be deprived of a piece of furniture that just happens to be found in vanilla locations all over the Commonwealth - it will return isEnabled - false on such a check.

Edited February 21, 2025 by Evi1Panda

[vjnmrf]

11 hours ago, Evi1Panda said:

It's a two-way street. You can check, but the problem is that furniture that is part of precombined models will return false. So I have removed this check for now. I have not yet figured out how to determine if a model is a member of a precombined set of models.

 

That is, you will be deprived of a piece of furniture that just happens to be found in vanilla locations all over the Commonwealth - it will return isEnabled - false on such a check.

 

Я давно сделал себе патч, удаляющий прекомбинации по всему содружеству, но ситуация, описанная предыдущим оратором, тем не менее происходит.

[dosfox]

50 minutes ago, vjnmrf said:

Я давно сделал себе патч, удаляющий прекомбинации по всему содружеству, но ситуация, описанная предыдущим оратором, тем не менее происходит.

"I made myself a patch a long time ago that removes precombinations throughout the commonwealth, but the situation described by the previous speaker is still happening."

 

I use Unbound World Space which removes precombines and previs information with minimal performance degradation and none of the weird crashes that ScrapEverything used to cause. I was wondering if the exposed precombines might have caused the problem, but if i remember correctly the problem was there before i started using UWS.

 

[Evi1Panda]

I don't think it's a good solution. If you have a NASA computer, or few mods, then you can probably forgo the precombined models. You see, you disable something that works in compile-time and change it to something that works worse and in run-time. All the talk about how run-time can work as well or even better than compile-time is nonsense. 

[Evi1Panda]

5 hours ago, vjnmrf said:

 

Я давно сделал себе патч, удаляющий прекомбинации по всему содружеству, но ситуация, описанная предыдущим оратором, тем не менее происходит.

 

Конечно происходит, потому что я убрал проверку на enable фурнитуры, т.к. она некорректно работает с прекомбинациями. Отключение прекомбинаций это максимально нехорошее решение. Люди, утверждающие что коробки коллизий не хуже прекомбинаций просто обманщики.

[Evi1Panda]

Checking for NiAV object mapping also doesn't work with precombines. Most likely the model becomes a part of another model  (combined model) to which there must be a pointer somewhere. It is necessary to reverse this part. If anyone has an idea how to get to pointers to combined models - please let me know.

In fact, we don't even need to know if it's loaded, because on a normal location, without precombine problems, if you look at the combined model - you can see it anyway (it can't be disabled). So it should be easy enough to check if the precombined model has in its members the model of potential furniture that we are interested in.

And, accordingly, the secret of IsEnabled == false for combined meshes is that the original model is not really loaded, but the combined copy is loaded.

 

p.s. This mod guy above I asked a question about his strange confidence that his idea of collision boxes works better than comibined meshes, and he didn't answer convincingly. I tested this mod myself in a corvega location, and in addition to being noticeably worse, there are also image artifacts, since I like to play third-person.
I have not the weakest computer 14700k + 4070 TI Super + 32gb. I think that on weaker PCs the difference will be even more noticeable.

Edited February 22, 2025 by Evi1Panda

[vjnmrf]

27 minutes ago, Evi1Panda said:

 

Конечно происходит, потому что я убрал проверку на enable фурнитуры, т.к. она некорректно работает с прекомбинациями. Отключение прекомбинаций это максимально нехорошее решение. Люди, утверждающие что коробки коллизий не хуже прекомбинаций просто обманщики.

 

 И тем не менее, такое решение меня вполне устраивает. Но вот откуда берется маркер удаленной мебели, непонятно.

[Evi1Panda]

Потому что она не удаляется никуда, а просто помечается как отключенная (isDisable)

[izzyknows]

4 hours ago, Evi1Panda said:

precombined model has in its members the model of potential furniture that we are interested in.

Why not just look for the furniture marker?

Usable furniture is never part of a precombine or a SCOL. Only simple static items are allowed to be included unless that static item has a link that will exclude it during the precpmbine creation.

You don't want to use the static furniture anyway, as it's "normally" not in a position to actually be used by the player.

 

[dosfox]

@Evi1Panda

 

None of these "invisible" furniture items were ever in a precombine, and do not appear in the NAF gui when starting a new animation.

 

Sometimes i'm lazy and just disable things in console instead of disable;markfordelete. Unfortunately i can't remember how i scrapped any of this invisible furniture - vanilla scrap, PlaceAnywhere Delete, console "disable", or console "disable;markfordelete". Is it possible that if a piece of furniture is just disabled and not "marked for delete" that NAF will use it?

 

Not sure if it's relevant, but SavageCabbage's furnitureData.xml contains all of the invisible furniture items noted so far.

 

[Evi1Panda]

Why. Static furniture baked into precombines is the majority of casual furniture in the Commonwealth. And it's usually in the correct position, which is easily verified. And yes - you can't use it, but game knows that there is 3d model that can be used as place for scene. Scenes don't uses furniture like furniture object.

Edited February 22, 2025 by Evi1Panda

[Evi1Panda]

1 hour ago, dosfox said:

None of these "invisible" furniture items were ever in a precombine

You probably don't understand what I'm talking about. Just read it again.