Jump to content

CliftonJD

Members
  • Posts

    5,350
  • Joined

  • Last visited

Everything posted by CliftonJD

  1. esl is meant for light mods, think hsh might be too much for an esl
  2. if you wanted to share your work for me to look over for anything that might be causing this behavior, i could look into that, but ordinarily i couldn't think of any reason for that. many mods have added dialogues to other npc's that also get added to slaves. tdf has it, wenches have it, slen has it. then there's even my home is your home that was made for follower, but had to be prevented by use of an addon patch for slaves so they don't break that's the subtle difference between essential and protected. essential npc's can't be killed, but protected npc's or slaves can only be killed by the dragonborn(player). psq has a similar drain feature to sancrosanct, but with psq there's an mcm option to disable kill by drain
  3. ok, busy day again tomorrow so i likely won't get to look over it til friday. BB_GetRapedDialogueMainBranch04Topic01 "Let's take care of business first, then you can have me right here." [DIAL:0500C527] has 3 dialogues, 0500C528 0500C529 0500C52a, with identical tif's and all properties in those tif's need to be removed from both the esp and the tif's to fix a problem reported above. might be easiest from tesedit, but the idea is to rename the script to this: BB_RapeBranch4Topic1_TIF.psc BB_RapeBranch4Topic1_TIF.pex
  4. yes, that's a bit of dreaming. the faction being restored on its own isn't so bad, but changing all the scripts and esp functions that look for that spell to instead look for a faction or faction rank is what would require a huge rewrite of the mod oh, that's normal that a spell has no aliases assigned in a quest. pah quest is loaded with faction properties that have no aliases either. think of that alias position as being reserved for if/when a quest alias should be assigned as a property....normally if its not a quest property, the option for an alias won't even appear when assigning the property from the ck i haven't looked close at it yet, but i could assume that the allure spell as you describe the event is set to attract the first client...wouldn't want the clients requesting sex during the dance would all depend on the tif being called. when i had to make new dialogues in pahe, i reused the same tif's for some dialogs and renamed the main tif to show myself later what that tif was for. did that for sandboxing and for stripping and for strip and rewear dialogues....with tdf i haven't yet come across any identical tif's that could be re-used tho this is the part of the error that matters here when the log says a tif no longer contains the property, you only need to look at the dialog mentioned in the error 0C00C528 and compare it against the tif to determine if the property should be there or if it was removed by mistake....in this case, it was remove from the tif before it was removed from the dialogue---a ck user who's not familiar with xedit would not be able to remove an obsolete property from an esp once its already been removed from the script, you would need to remove it from the dialogue in the esp first, then remove it from the script and recompile it that type of error i would recommend sharing instead with hentai as there's nothing there to indicate why hentai has those errors or what lead upto it think that would be best
  5. same experience factions will still exist so i believe it should transfer over, but on that i dunno either, think it should keep the training and i know it would if it were pahe, but never checked their experience after a reset in tdf....thinking since it says quest reset, that the training factions remain unaltered
  6. you can start early by finding which dialogs can already share the same tif's as the scripts we just fixed and make note of which those are, so that it eliminates possible re-occurrence of the bugs nonseen reported the 2 additional source files i determined only needed to be made readable incase we need to make changes to them down the road ok, the quest attached to the dialogue should prevent them from getting the dialogue if they're not already in BB_RoamingHookersControlQuest "City Prostitution Management" [QUST:07030689] the older dialogue conditions state they additionally should only get the dialogue if they don't have the BB_RoamingHookerJarlIdentificationSpell [SPEL:0703BE3E] And only then if they have BB_HookerPracticalExperienceFaction "BB Hooker Practical Experience Faction" [FACT:07017C9B] 25 or higher your changes in the latest esp make it so they still need the same experience, but now they get the dialogue only if they're a hooker in any 1 of those cities Or if they don't have the BB_RoamingHookerJarlIdentificationSpell [SPEL:0703BE3E] i think in order to get the conditions set as you're looking for, you would need to remove the checkmark for "or" in the last city of the list, winterhold. (this can be done from the ck or xedit, which ever easiest for you) should really start with the scripts we're already working on as we add them, like the first in the list would be bb_tif_HookerDragonbridge Or my favorite would be bb_HookerDragonbridge_tif <<this method identifies to us its intended purpose first then identifies that its just a tif last so that all bb_HookerDragonbridge scripts are listed in the same place if/when we need to change Dragonbridge scripts later had to fix a typo in 1 of the script reference commands and the scriptname in the script needs to match the script filename so here's the first: AIBB_TIF__0508D6DF.psc compiled becomes this: AIBB_TIF__0508D6DF.pex if we rename it, we get this: BB_HookerDragonbridge_tif.psc compiled becomes this: BB_HookerDragonbridge_tif.pex same typo in the next file that still needs to match the script name to file name: AIBB_TIF__0508D6E1.psc AIBB_TIF__0508D6E1.pex renamed becomes these: BB_HookerIvarstead_TIF.psc BB_HookerIvarstead_TIF.pex next up these: AIBB_TIF__0508D6E0.psc AIBB_TIF__0508D6E0.pex and these: BB_HookerRiverwood_TIF.psc BB_HookerRiverwood_TIF.pex next: AIBB_TIF__0508D6E2.psc AIBB_TIF__0508D6E2.pex and: BB_HookerOldHroldan_TIF.psc BB_HookerOldHroldan_TIF.pex next i thought what if there are more than 1 hooker tif for that town so i devised that these: AIBB_TIF__0508D6E3.psc AIBB_TIF__0508D6E3.pex would become these: BB_HookerRorikstead_TIF__0508D6E3.psc BB_HookerRorikstead_TIF__0508D6E3.pex next up these: AIBB_TIF__0508D6E4.psc AIBB_TIF__0508D6E4.pex BB_HookerKynesgrove_TIF__0508D6E4.psc BB_HookerKynesgrove_TIF__0508D6E4.pex next: AIBB_TIF__0508D6E5.psc AIBB_TIF__0508D6E5.pex BB_HookerNightgate_TIF__0508D6E5.psc BB_HookerNightgate_TIF__0508D6E5.pex finally these: AIBB_TIF__0508D6E6.psc AIBB_TIF__0508D6E6.pex BB_HookerSkaalVillage_TIF__0508D6E6.psc BB_HookerSkaalVillage_TIF__0508D6E6.pex
  7. ok, i'm back to a point i should be able to compile again. but we need to check the scripts properties attached to the quests: BB_GetRapedDialogue [QUST:05001D98] BB_PimpingQuest "BB Pimping Quest" [QUST:05002DDA] BB_PimpingQuest2 "BB Pimping Quest 2" [QUST:05005904] BB_PimpingQuest3 "BB Pimping Quest 3" [QUST:05005905] BB_RoamingHookersDawnstarScene [QUST:0501E16C] <<only problem on dawnstar is its assigned to the wrong scene, should be>>BB_RoamingHookersDawnstarScene01 [SCEN:0502FA5A] here's the scripts i optimized along with the bugged scripts reported by nonseen: TDF Independent Prostitutes Legendary SLEN scripts optimized.zip
  8. all those errors posted above by nonseen are inherited from the original mod, looks like it was already held together with duct tape and string, condition its in now won't be any worse than it was the very best anybody can hope for on a running save with the independent addon would be to take any gold from their prostitutes, tell all their prostitutes to stop working there, wherever there happens to be....before removing the addon client experience should all be saved to the main esp so that should be fine, but they might also need to reset all running quests from the tdf mcm after the upgrade
  9. imo its not ready yet, those properties i told @Pfiffy didn't match up between the add-on and the original mod need to be filled still according to the scripts...and there's more properties that neither filled. agreed, for now we'll have to set it aside. this would be better worked with a faction, but would require a huge portion of the mod to be rewritten to change it from spell to faction now i can remove the property from the script and recompile it....its not even being used in the script so original scripter made a slipup there, the source doesn't match the script, according to the source script, the property is unused and its not trying to set faction rank. set this aside for now, will require a script rewrite to even looking into fixing that problem now that script atleast has matching source and script so i can clean it later. i can see by the source the scripter atleast tried to comment out the command that's giving you errors. it "should" have ignored that command completely and never gave you any error ya and i just rechecked the quest does indeed have the dancer set as an option alias...along with all the watchers so no idea either same as bug 2 these scripts same problem as bug3 screenshot where you're getting that cuz on my screen that spell is a property and it has been filled hmm, looks like your message cutoff or you had wrong thing in your clipboard to paste
  10. likely something wrong with your install then. maybe try reinstall the mod and restart it from the mcm
  11. falmer, among many others races in skyrim have their armor defined as their skin. only solution would be to get 1 of the mods that replaces falmer
  12. i discovered this same bug once when you tell pardo to have an auction that all slaves in the restless hunter will be gone if you leave. even if its a 2 second teleport to your house to unload some gear from your slaves. its as if using that dialog with pardo sets a flag in the auction scripts to clear all slaves on the cell change event instead of waiting until the auction is over to set that same flag and clear the slaves then give the money from the sale to pardo to wait for the player's return. this would also be why other users have found a bug that pardo sometimes or often doesn't have the money from sale if you weren't there for the auction...cuz there were no slaves to sell after you left
  13. rename her first so she has a name again, then reclone her so she separates from the other mod should work if she's a slave, she shouldn't have either ai control so that could be a huge issue with her there, she should have pahslave ai all current versions include a folder for help files
  14. maybe call those 3 sluts as companion sluts that the player helps to train before they can become independent ok, can look into that when time permits it oh the lovely tif's. in pahe i discovered that i can make some dialogs share the same tif's instead of cluttering up the mod with more tif's(and instead of spending more time scripting and compiling them)---for the meantime, see what happens if you change 1 of the working scenes to the same tif script as scene1. so try changing scene 3 to use the same script as scene 1 --if that works to share the same script in the scenes for tdf like it does in the dialogs for pahe, then i can rename the script and recompile it so that all the scenes can use that same script without confusion when we look back later as to why the scenes are all scripted as scene1
  15. ahh, that makes sense as well. the 2 poses of straitjacket versus cuff tied slave would conflict. unfortunately, i can no longer prevent this bug from happening without a joint effort from musje for hsh--i could add conditions to the dialogs preventing it, but hsh also adds its own version of the tie-up dialogs to pahe slaves in the future i could add conditions to the dialog preventing this from happening to pahe slaves i forgot hsh has prevention built-in to much of its scripts for hsh slaves, so hsh might already be prepared for this circumstance with pahe slaves as well its a known visual bug in dd for npc's. for player wearing those items, this bug is prevented by preventing the player from fighting with her hands no other known problems, but you'd need to check the dd thread on that to be certain
  16. you could try a reset from the slave menu in the mcm, but can't say if she's broken without a papyrus log
  17. you stated she was a custom follower twice so that makes her questionable unless she's custom, but not scripted....custom followers are ok if you know they're unscripted yes, mhiyh is known for causing name bugs on slaves. that's the whole reason for that patch in the downloads - to prevent you from using those dialogs on slaves odd....still seem to remember them sandboxing better. they do walk around, but don't seem to do anything else and the 1 time i saw 1 walk around the parkway she had her head facing me instead of watching where she was going...thinking blabla's line of site training here might be effecting their sandboxing: so i'll try removing that for next update and see what we get
  18. thanks, my biggest issue is indeed the time to help with it. i optimized the scripts a bit for readability when i needed to see why some of the properties were removed, then as i made it more readable i discovered a few ifs and elseifs that could be combined for better performance...just got a little side-tracked with combining the other parts of the mod so i'll send you the updated scripts after i get a back to the properties i needed to look at them for the more we dig into this tho, the more i wonder why independent hookers have been added, but not the normal hookers the player gets..that's what i'm thinking we should look into after we get done merging it all
  19. bug would be if you tied he and suddenly she became untied to have a 3-some. tdf doesn't know you have her tied to prevent her from being called for a 3-some so she just lays there as she was told.....at some point down the road i spose we could make tdf prevent her from being called for a 3-some when she's tied to prevent that bug from happening
  20. ahh, think last it tried it i hadn't worked out the kinks in sandboxing yet so it was still just a duplicate wait dialog
  21. ahh, that atleast explains where the none keyword stacks are coming from - another user reported that error as well, couldn't figure out why then makes sense if she's not wearing it and more so with the errors preventing the script from detecting she should be wearing it already have changes in the script for next update, looking to fix that error. now that you've found the cause for the bug i might also be able to use this as a point to re-equip the devices
×
×
  • Create New...