NAF Bridge

[Andy14]

48 minutes ago, dosfox said:

Hey @Evi1Panda

 

MCM will not keep changes made to settings. Below are images of my changes made to settings along with the results next time MCM is opened.

 

  Hide contents

PAGE 1

 

PAGE 2

 

PAGE 3

 

Don't know what's going on here at all. I have reinstalled bridge 3 times, cleared the MCM Boostr cache, moved the NAFbridge MCM folder from overwite to mod folder, etc.

 

A similar problem is occurring with AutonomySex MCM settings. Specifically the "Chance 2-actor pose" "Chance 3-actor pose" and "Chance ->3 pose". Whatever combinations of settings i put in (all adding to 100), when coming back to MCM next time those values are all random (never adding to 100).

 

MCM works perfectly for every other mod.

 

Yes. It's the same for me after loading my save. And once again, no scenes are triggered.🤔

I'm going to revert to version 1.30 or better to 1.16 and start a new game.

Edited December 27, 2025 by Andy14

[seaclip]

Hi, Evi1Panda, thank you for your energetic fixes and updates. I love you.

This may not be necessary, but I'd like to report a bug related to Ver.1.35.
Sorry to bother you when you seem busy!

 

In save data that has loaded NAF Bridge v1.35, the hotkeys of AAF-based mods
(tested with SexEmUp) stop responding.
NAF animations can still be played normally.

- The issue occurs only in save data that has loaded v1.35
- Reverting to v1.30 or v1.37 does not resolve the issue
- If I load a backup save that has never used v1.35 (without restarting the game),
  everything works normally
- v1.38 is untested (the affected save was already deleted)

 

Since this issue seems to be save‑data dependent, I'm a bit worried.
I hope it's already fixed in 1.38.

Edited December 27, 2025 by seaclip

[Evi1Panda]

5 hours ago, Andy14 said:

MCM will not keep changes made to settings. Below are images of my changes made to settings along with the results next time MCM is opened.

Do you have Baka Framework installed?

[dosfox]

4 minutes ago, Evi1Panda said:

Do you have Baka Framework installed?

 

Yes, the recommended version of Baka Frramework is installed ...

[Andy14]

1 hour ago, Evi1Panda said:

Do you have Baka Framework installed?

Yes. The old Baka Framework.

[Evi1Panda]

It seems that the LL website is being DDOSed by a bunch of people craving a little love for the New Year! You could say that my website is practically down.

 

11 minutes ago, Andy14 said:

Yes. The old Baka Framework.

 

I can't say any without logs. It's better to continue on Nexus for now, because this is an act of masochism. The site is almost down.

[dosfox]

Well, that seems to have fixed it. MCM settings are now stable on MCM reopen, also after fast travel, and Save-Quit-Restart.

 

It is good to see that the NAFbridge\MCM folder is not ending up in Overwrite. I suspected that might be a cause of the problem. I have only been testing with Autonomy2.8 so far - seems to be working OK but a little slower than it was with pre-v1.30 versions. Will install AutonomySex a bit later when i am sure everything is stable.

 

Just a couple of bugs i have been putting off reporting until NAFbridge problems were resolved:

 

1. NAF rescaling doesn't seem to work with some of the creatures i frequently use:
      Junkyard Dogs - ID 0176337
      Gorillas - ID 0176336
      FEV Hounds - ID 0304BA65

 

2. Not sure whether to report this to you or the author of "Settlement Visitors". Sometimes Visitors engaged in NAF scenes will break from the scene to do one of their own random idle animations. This is the only event i've ever seen that breaks a NAF animation.

 

Edited December 27, 2025 by dosfox

[Evi1Panda]

1. Will test.

2. I guess it is mostly to the author of "Settlement Visitors", if he forces animation then probably he should has this code or smth like

 

Keyword IsInAfScene = none
AAF:AAF_API api = AAF:AAF_API.GetAPI()
if api != none
	IsInAfScene = api.AAF_AAFActorBusy
endif
if IsInAfScene != None
	if myActor.HasKeyword(IsInAfScene)
		return
	endif
endif
myActor.PlayIdle(myIdle)

 

Edited December 27, 2025 by Evi1Panda

[Evi1Panda]

@dosfox I guess it works fine... I answered on Nexus with pictures.

 

[Evi1Panda]

5 hours ago, seaclip said:

Hi, Evi1Panda, thank you for your energetic fixes and updates. I love you.

This may not be necessary, but I'd like to report a bug related to Ver.1.35.
Sorry to bother you when you seem busy!

 

In save data that has loaded NAF Bridge v1.35, the hotkeys of AAF-based mods
(tested with SexEmUp) stop responding.
NAF animations can still be played normally.

- The issue occurs only in save data that has loaded v1.35
- Reverting to v1.30 or v1.37 does not resolve the issue
- If I load a backup save that has never used v1.35 (without restarting the game),
  everything works normally
- v1.38 is untested (the affected save was already deleted)

 

Since this issue seems to be save‑data dependent, I'm a bit worried.
I hope it's already fixed in 1.38.

 

Test in 1.39, be sure you have installed Baka Framewor. If trouble is there still then send me log:

1. Be sure in MCM you have debug level Console.

2. Send Fallout 4/aaSUPF4SEDebugPrint.txt right after issue.

[dosfox]

42 minutes ago, Evi1Panda said:

 I guess it works fine... I answered on Nexus with pictures.

 

Thank you. You should probably delete those pictures from the post ... 😉

Edited December 27, 2025 by dosfox

[seaclip]

36 minutes ago, Evi1Panda said:

 

Test in 1.39, be sure you have installed Baka Framewor. If trouble is there still then send me log:

1. Be sure in MCM you have debug level Console.

2. Send Fallout 4/aaSUPF4SEDebugPrint.txt right after issue.

Got it, thanks.
Baka Framework is already installed, and I’ll test again on 1.39.
If it happens again, I’ll make sure to grab the log properly.
Sorry for the incomplete report.

[dosfox]

@Evi1Panda

 

Is there a console command that performs the same function as "Interrupt all active scenes"?

[Evi1Panda]

1 hour ago, dosfox said:

@Evi1Panda

 

Is there a console command that performs the same function as "Interrupt all active scenes"?

No, but I can made GlobalFunction to call it from console. But maybe later... It needs to understand how console sends it data.

Edited December 27, 2025 by Evi1Panda

[Evi1Panda]

Just reuploaded 1.39, nothing changed except AnimateFanniesData.json updated. Added dogs, ferrals, gorilla. To be honest, I just guessed the values, so if someone could fix them up a bit and add other races, that would be great.

[dosfox]

@Evi1Panda

Since installing v1.39 there have been zero animations on furniture, despite Furniture preference =95. Also tried setting Override = 95, but still no furniture animations.

 

Here is log:  NOFURNITURE_aaSUPF4SEDebugPrint.txt

 

Edited December 28, 2025 by dosfox

[Evi1Panda]

@dosfox I see. Little trouble in ScanForFurniture function. Reupload it now.

[dosfox]

@Evi1Panda When you re-upload versions, would you mind incrementing the version number to avoid confusion? e.g. This last upload should be v1.39.2.

 

EDIT: Oops sorry. You've gone straight to v1.40.

Edited December 28, 2025 by dosfox
.40

[Evi1Panda]

@dosfox I always increment if there is changes in code. I can just reupload if there is no code changes, like json/ini etc.

Edited December 28, 2025 by Evi1Panda

[dosfox]

@Ev1lPanda

 

Thank you for v1.40. Furniture behaviour is now working properly.

 

In testing so far Autonomy2.8 is generating considerably less scenes concurrently than with v1.16. E.g. in Club Snuggle there are only 1-3 scenes max. With v1.16 it was generating 1-6 or more scenes concurrently.

 

Latest log using v1.40:  V1.40_aaSUPF4SEDebugPrint.txt

Edited December 28, 2025 by dosfox

[Evi1Panda]

I studied 300 lines of log, there were 15 attempts to launch the scene, of which 7 launched correctly, 4 launched via fallback AE (solo scene) - all because AE added NPCs that were already in the scenes to the list, and another 4 were completely rejected for the same reason.

 

upd. Actually idk was AE fallback or Bridge. 

 

	Actor[] actors = PrepareActorsForScene(akActors, settings)
	if akActors == none || actors.length == 0
		SendFailOnSceneInitEvent(settings, akActors, "StartScene failed : no valid actors for scene")
		if actors != none
			int i = 0
			while i < actors.length
				CleanupActorAfterScene(actors[i]) ; cleanup first actor to avoid stuck
				i += 1
			endwhile
		endif
		return false
	endif

In fact, the bridge continues to launch the scene even if some of the actors have been rejected. Perhaps this is not right and the scene should be rejected, because it turns out that the bridge is making up for the customer. It's not critical, I'll fix it in the update... Ideally, the customer should think about how to handle the rejection, bridge just need to notify about result.

upd. I've written some kind of bullshit in the code. I need to sleep. This part will never execute:

if actors != none
	int i = 0
	while i < actors.length
		CleanupActorAfterScene(actors[i]) ; cleanup first actor to avoid stuck
		i += 1
	endwhile
endif

It's not dangerous, but simply pointless.

Edited December 28, 2025 by Evi1Panda

[Andy14]

I've been testing version 1.40 for a few hours now and will probably downgrade back to 1.16.

Violett works, but it selects completely nonsensical scenes: specifically, only single-actor posing animations for the character.

It doesn't matter if it's Raiders, Super Mutants, or anything else. It also doesn't matter what settings I use in Violett or Naficator Bridge.

The result is always the same. The console isn't reporting any errors. It's simply selecting the wrong scenes.

 

P.S. It was a new game and all requirements were met.

Edited December 28, 2025 by Andy14

[Evi1Panda]

@Andy14 

Thanks for the report. The specific issue you described (Violett selecting only single-actor scenes) has been identified and fixed in 1.41. Your feedback was crucial for pinpointing this.

I understand that frequent version changes and instability can be frustrating. However, the project is currently in a necessary phase of large-scale refactoring. The old Papyrus codebase was unsustainable for future development. Rewriting it is a complex puzzle with minimal documentation, akin to reverse-engineering logic built for a different system.

 

This approach has two paths:

1. Spend dozens of hours internally testing every mod combination before release.

2. Release functional but potentially rough versions and iterate quickly based on concrete community reports, like yours.

 

I've chosen path #2 to move the project forward more efficiently. It saves development time and allows fixes to be based on real-world use.

Therefore, while I share your frustration, the most helpful way to interact is to continue providing specific, fact-based reports like this one. They are invaluable.

[Evi1Panda]

The root cause lies in the original codebase. It was developed incrementally, often based on immediate user requests and workarounds for the limitations of its time (like the absence of tools such as NAFicator). This led to deeply embedded "crutches" and artifacts that made the code unpredictable and hindered its intended functionality. The current refactoring is the final, crucial step to remove this technical debt. We are on the home stretch. Once this foundation is solid, achieving a polished and awesome result will be significantly faster, especially with concrete feedback like yours.

[Evi1Panda]

I'm sharing this context to highlight the key difference: the previous code was a patchwork of reactive fixes, while the current refactoring is a deliberate, methodical rebuild. This is a chosen development strategy, not haphazard patching. The situation is under full control. In fact, the issue you reported took about 15 minutes to locate and fix once identified — a direct benefit of the new, clean codebase. This efficiency is exactly why we're going through this process.