LMAO - Tolls and Crimes

[Alexvkj_new]

Well, I think in an oppressive world a mildly submissive player shouldn't be able to fast travel   I usually disable the feature. And as I already mentioned, I add an immersive way to skip tolls via modded sewers

 

I think my next campaign will be as a criminal punk 

Edited Thursday at 07:55 PM by Alexvkj_new

[Talesien]

So where to add bug reports for versions not on LL? My first instinct was gitlab, but the issue board there appears completely unused?
Anyway LMAO sends a DHLP that is ... problematic in its implementation IMHO. I noticed it because the outfit swap mod I use, blocks swaps during an active DHLP. Which was basically all the time I was anywhere remotely close to a city gate, so I dug a bit deeper.

Lets get technical, then shall we:
LMAO Version: 0.4.0.3, also compared the scripts against GitLab main.

LMAO broadcasts a dhlp-Suspend as soon as a guard is assigned to the player, and a confrontation hold can end without the matching dhlp-Resume. The result: every DHLP-aware mod stays suspended, and that state survives saves.
 

What happened:

One dhlp-Suspend from LMAO, sent near the Whiterun gate, was never followed by a resume. PalmGear (the mentioned outfit tool that honours DHLP) stayed blocked for over an hour across four sessions. Managed to identify the DHLP sender using BindingUpdated and Sexy Adventure, both reporting the sender in different way. Binding Updated identified the crime controller as the sender, and Sexy Adventures showed a form ID with LMAO.esm's load-order prefix.
 

| Time (2026-10-17) | Source | Event |
| 01:19:40 | Papyrus log | LMAO logs SetActiveCrime (a crime becomes active) |
| 01:19:44 | PalmGear log | dhlp: suspend received |
| — | — | no dhlp-Resume ever follows |
| 01:43, 02:04, 02:18 | PalmGear log | three later sessions load the save: suspend flag restored from save (suspended) |
| 02:30 – 02:39 | PalmGear log | outfit changes blocked 4 times |

Workaround: MCM -> Debug -> toggle "Events Paused". That runs ClearAllHolds(), which broadcasts dhlp-Resume.

 

Issue 1: The suspend starts at guard assignment

dhlp-Suspend goes out when a guard is picked, not when he engages the player. Near city gates that happens constantly, so every DHLP mod pauses during ordinary play, just by proximity to a city gate.

LMAO_Crime_Controller_Script.BroadcastRows() sends the rows in Interface/LMAO/Events.json -> LMAOPauseBroadcasts (dhlp-Suspend / dhlp-Resume) on the 0 -> 1 edge of HoldEvents().
HoldEvents() callers:
 LMAO_Search_Alias.InitializeAlias() ("Search"). It is reached from the random-search rolls in LMAO_Guard_Manager_Script and LMAO_Watching_Guard, which run while the player is in a city, and from the toll-search dialogue fragments.
  LMAO_ConfrontingAlias.InitStuff() ("Confrontation"), when a guard is assigned to confront.
  Escort and punishment starts.
So the hold begins while the guard is still walking over, and it holds even if he never reaches the player. A hold placed by a random search roll is the common case.
I would suggest limiting the hold to when the LMAO guard actually engages (forcegreet, dialogue or scene start), and release it when that interaction ends. Other mods should only be blocked while the player is really in an LMAO interaction.
 

(Possible) Issue 2: I think from checking the logs (and consulting Claude Code to confirm my suspicions against the scripts) that a confrontation hold can potentially end without a resume

Far as my understanding goes, the confrontation hold is released only through ClearConfrontation() or ReleaseHold(). Two paths on main still empty the alias with a plain .Clear(), so OwnedHolds never returns to 0 and no dhlp-Resume is sent.

| Location (0.4.0.3) | When it runs | Releases the hold? | 
| LMAO_Punishment_Controller_Script.psc:324 | end of a punishment | No; only the punishment's own hold | 
| LMAO_Utility_Script.psc:598 (DisableMod) | mod disabled | No | 
 

After a plain .Clear(), LMAO_ConfrontingAlias.Confronting stays true. The next confrontation then skips HoldEvents(), so the stray hold lasts until some later ClearConfrontation() happens to unwind it.
OwnedHolds is saved, and receivers save their suspended state too (PalmGear does). A leaked suspend therefore survives save/load, as the timeline above shows.
I could be wrong here, provided that EndCrime() always runs before the punishment-end clears. In this case that row would be covered. I'm not sure it does though.
Might be safer to send every confronting-alias clear through ClearConfrontation() or ReleaseHold(): the punishment end and DisableMod() paths above.

Maybe even add a safety net on game load. Something like: When LMAO holds nothing (i.e. OwnedHolds == 0, no active search, confrontation or punishment), broadcast dhlp-Resume once. A stale suspend from an older session then clears itself. Needs to make sure of course the suspend actually stems from LMAO.
 

 

Edit: Hmpf, the board messed up the tables, sorry 'bout that.
 

 

Edited yesterday at 02:05 AM by Talesien

[alliga]

SSE 1.5.97 sexlab LMAO - Tolls and Crimes - 0.4.0.3 (from lmao gitlab)

 

MO2 error

The failed plugins are:

• EcelliPapyrusExtender version 1 (EcelliPapyrusExtender.dll, LMAO - Tolls and Crimes) reported as incompatible during query.

[Talesien]

Hit another 'interesting' bug. Got strip searched by a guard in the Bannered Mare, he removed my clothing and afterwards, after me asking, gave it back ... except he didn't. 

Took me a while to figure it out, appears when a guard strips the player, the clothes go into LMAO_Search_Controller.SearchContainer.
Then for some reason there is a routine that moves the items out of that into another container once per game day. If the in-game day rolls over before the search ends, LMAO_Utility_Script.Daily() calls ClearConfiscation() with no argument, which moves the container's contents to the city confiscation chest. The return line ("Eh. Fine. Here are your rags.") then runs returnStrippedClothes() on an empty container. So, the PC gets nothing back, and the clothes end up in the city chest. Yes, unlucky timing, still, not sure why this cleanup is even required? At any rate it should check if anything is going on and delay or skip if yes.

Log from the event:
- 03:03:53–58: the bra, sleeves, dress, heels and thong move from the player into the search container.

- 03:04:16: Daily Check, toll cost: 25. All five items move from the search container into the confiscation chest.
- 03:05:47: "Can I have my clothes back?" / "Eh. Fine. Here are your rags." Nothing is returned.                   

Tried to build a patch myself, but couldn't compile it, as I lack several of the compile requirements.

OnCityChangeStart() and OnCityChangeEnd() appear to have a similar race condition, didn't delve to deep into that though, so might be wrong. Would likely require coc or a teleport spell to trigger, still both can happen (I use mark and recall for example), so perhaps worth guarding against as well.

[Thoraag]

3 hours ago, Talesien said:

Hit another 'interesting' bug. Got strip searched by a guard in the Bannered Mare, he removed my clothing and afterwards, after me asking, gave it back ... except he didn't. 

Took me a while to figure it out, appears when a guard strips the player, the clothes go into LMAO_Search_Controller.SearchContainer.
Then for some reason there is a routine that moves the items out of that into another container once per game day. If the in-game day rolls over before the search ends, LMAO_Utility_Script.Daily() calls ClearConfiscation() with no argument, which moves the container's contents to the city confiscation chest. The return line ("Eh. Fine. Here are your rags.") then runs returnStrippedClothes() on an empty container. So, the PC gets nothing back, and the clothes end up in the city chest. Yes, unlucky timing, still, not sure why this cleanup is even required? At any rate it should check if anything is going on and delay or skip if yes.

Log from the event:
- 03:03:53–58: the bra, sleeves, dress, heels and thong move from the player into the search container.

- 03:04:16: Daily Check, toll cost: 25. All five items move from the search container into the confiscation chest.
- 03:05:47: "Can I have my clothes back?" / "Eh. Fine. Here are your rags." Nothing is returned.                   

Tried to build a patch myself, but couldn't compile it, as I lack several of the compile requirements.

OnCityChangeStart() and OnCityChangeEnd() appear to have a similar race condition, didn't delve to deep into that though, so might be wrong. Would likely require coc or a teleport spell to trigger, still both can happen (I use mark and recall for example), so perhaps worth guarding against as well.

This one i think I found and fixed before I paused to do my rebuild - The reason for the clean up is cause the intent is there will be ways to purchase back your stuff at the kennels. For now they go into the licenses bin or the prison bin. 

 

 

On 10/16/2026 at 7:01 PM, Talesien said:

So where to add bug reports for versions not on LL? My first instinct was gitlab, but the issue board there appears completely unused?
Anyway LMAO sends a DHLP that is ... problematic in its implementation IMHO. I noticed it because the outfit swap mod I use, blocks swaps during an active DHLP. Which was basically all the time I was anywhere remotely close to a city gate, so I dug a bit deeper.

Lets get technical, then shall we:
LMAO Version: 0.4.0.3, also compared the scripts against GitLab main.

LMAO broadcasts a dhlp-Suspend as soon as a guard is assigned to the player, and a confrontation hold can end without the matching dhlp-Resume. The result: every DHLP-aware mod stays suspended, and that state survives saves.
 

What happened:

One dhlp-Suspend from LMAO, sent near the Whiterun gate, was never followed by a resume. PalmGear (the mentioned outfit tool that honours DHLP) stayed blocked for over an hour across four sessions. Managed to identify the DHLP sender using BindingUpdated and Sexy Adventure, both reporting the sender in different way. Binding Updated identified the crime controller as the sender, and Sexy Adventures showed a form ID with LMAO.esm's load-order prefix.
 

| Time (2026-10-17) | Source | Event |
| 01:19:40 | Papyrus log | LMAO logs SetActiveCrime (a crime becomes active) |
| 01:19:44 | PalmGear log | dhlp: suspend received |
| — | — | no dhlp-Resume ever follows |
| 01:43, 02:04, 02:18 | PalmGear log | three later sessions load the save: suspend flag restored from save (suspended) |
| 02:30 – 02:39 | PalmGear log | outfit changes blocked 4 times |

Workaround: MCM -> Debug -> toggle "Events Paused". That runs ClearAllHolds(), which broadcasts dhlp-Resume.

 

Issue 1: The suspend starts at guard assignment

dhlp-Suspend goes out when a guard is picked, not when he engages the player. Near city gates that happens constantly, so every DHLP mod pauses during ordinary play, just by proximity to a city gate.

LMAO_Crime_Controller_Script.BroadcastRows() sends the rows in Interface/LMAO/Events.json -> LMAOPauseBroadcasts (dhlp-Suspend / dhlp-Resume) on the 0 -> 1 edge of HoldEvents().
HoldEvents() callers:
 LMAO_Search_Alias.InitializeAlias() ("Search"). It is reached from the random-search rolls in LMAO_Guard_Manager_Script and LMAO_Watching_Guard, which run while the player is in a city, and from the toll-search dialogue fragments.
  LMAO_ConfrontingAlias.InitStuff() ("Confrontation"), when a guard is assigned to confront.
  Escort and punishment starts.
So the hold begins while the guard is still walking over, and it holds even if he never reaches the player. A hold placed by a random search roll is the common case.
I would suggest limiting the hold to when the LMAO guard actually engages (forcegreet, dialogue or scene start), and release it when that interaction ends. Other mods should only be blocked while the player is really in an LMAO interaction.
 

(Possible) Issue 2: I think from checking the logs (and consulting Claude Code to confirm my suspicions against the scripts) that a confrontation hold can potentially end without a resume

Far as my understanding goes, the confrontation hold is released only through ClearConfrontation() or ReleaseHold(). Two paths on main still empty the alias with a plain .Clear(), so OwnedHolds never returns to 0 and no dhlp-Resume is sent.

| Location (0.4.0.3) | When it runs | Releases the hold? | 
| LMAO_Punishment_Controller_Script.psc:324 | end of a punishment | No; only the punishment's own hold | 
| LMAO_Utility_Script.psc:598 (DisableMod) | mod disabled | No | 
 

After a plain .Clear(), LMAO_ConfrontingAlias.Confronting stays true. The next confrontation then skips HoldEvents(), so the stray hold lasts until some later ClearConfrontation() happens to unwind it.
OwnedHolds is saved, and receivers save their suspended state too (PalmGear does). A leaked suspend therefore survives save/load, as the timeline above shows.
I could be wrong here, provided that EndCrime() always runs before the punishment-end clears. In this case that row would be covered. I'm not sure it does though.
Might be safer to send every confronting-alias clear through ClearConfrontation() or ReleaseHold(): the punishment end and DisableMod() paths above.

Maybe even add a safety net on game load. Something like: When LMAO holds nothing (i.e. OwnedHolds == 0, no active search, confrontation or punishment), broadcast dhlp-Resume once. A stale suspend from an older session then clears itself. Needs to make sure of course the suspend actually stems from LMAO.
 

 

Edit: Hmpf, the board messed up the tables, sorry 'bout that.
 

 

I'll re-look at this one before I push the next update. Its hard to give these reports the attention they deserve when I am in the middle of a large clean up. 

Generally though reports are best served in the discord - though as noted last page, currently working on a major overhaul of the mcm, seperating out soft integrations into their own patches, and decoupling the need for papyrus tweaks which is currently causing the newest skyrim version to break.  (that being said, i keep an eye on this thread - just in the middle of these large pushes i am less responsive)