Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

743 profile views

bluedanieru's Achievements


Hearthfriend (2/10)



  1. FYI: The Dark Souls perk fix that went in 3.0.1 (#19812 - http://www.afkmods.com/index.php?/tracdown/issue/19812-dark-souls-perk-not-working-correctly-on-some-reanimation-spells/)is a fix for a bug that doesn't exist. The extra effect PerkDarkSoulsReanimateEffect on Reanimate Corpse doesn't do anything and was harmless, being a zero-magnitude Restore Health effect, basically, with no script attached. The +100 buff is applied via the perk directly, which has an "Apply Reanimate Spell" entry point to add the effect PerkDarkSoulsZombieBonus on any reanimated corpses. This can be easily verified in a few minutes in-game by inspecting the AVs directly, or looking in the CK/TES5Edit. Raise Zombie, Reanimate Corpse, Revenant, Dread Zombie, and Dead Thrall all worked with the Dark Souls perk correctly already, without this fix and without (PerkDarkSouls(DreadZombie|Revenant|Zombie|DeadThrall)Effect) being added to them. Also, while PerkDarkSoulsReanimateEffect for Reanimate Corpse has no actual effect and is basically harmless afaict, the other analogous effects which are now added by USLEEP use the PerkDarkPotencyScript script on the effect, which adds a variable buff in addition to the proper buff already added by the perk itself. The actual error to be corrected here is that PerkDarkSoulsReanimateEffect was left on Reanimate Corpse and should be removed, not that these effects should be added to everything else. I have raised a bug ticket to revert this: http://www.afkmods.com/index.php?/tracdown/issue/19937-dark-souls-perk-was-already-working-correctly-on-all-reanimation-spells/
  2. I said this in the other thread, but I'll put it here too. I think you'll be better off, if you're going to release a 2.0.1b over this, to take out the fix completely, and try again with 2.0.2. Don't rush, and rather give the team more time for code review and testing.
  3. The Soul Trap fix in USKP was not applied to the Soul Tear shout in UDGP. Since USKP replaces magicSoulTrapFXScript, and adds new properties, this is going to be a problem. Probably enough to warrant a hotfix, IMO.
  4. I *would* be pretty livid if ASG were added to the list of obsolete mods, considering ASG is not obsoleted by this.
  5. Like I said, it isn't conjecture or a guess on my part. Anyone looking at the code can see that, and as for myself I got a PM from egocarib last August on Nexus asking "hey can I integrate ASG into my enchanting mod" to which I said "sure, go ahead, and send me a link to the mod when you're finished". That was the last I ever heard of it and the first time I saw Enchanting Awakened was yesterday. EA has no mention of ASG anywhere on the project page, but from the look of it egocarib implemented things differently enough there, that I suppose he felt attribution wasn't necessary after all. Okay, fair enough, but all the same the method now used by USKP is the same as ASG, just applied only to black gems and The Black Star.
  6. Ah, you think I'm upset about incompatibility. I'm not. That's to be expected and I had to update ASG for 2.0.0 as well. fragsnippy's issue is not incompatibility - not directly anyway because I can't reproduce the issue he's getting, and with ASG that script normally doesn't fire, ever. That's true even before I released the compatibility update for it tonight. As for my intentions I guess I don't have any, but I am amused that basic attribution was missed on this, considering that Arthmoor is normally Mr. Intellectual Property. To be clear, I'm not upset about it since there was no way for him to know, and I'm sure egocarib tried to act in good faith. So no harm done. But that the work that went into this was (very partially) based off ASG is not conjecture on my part - it is a basic fact.
  7. Wow, this fix for black gems is really something, considering it uses the exact same method for fixing black gems that Acquisitive Soul Gems has been using for two years! I'm not saying it was directly lifted or anything since from looking at the code that doesn't appear to be the case - but inspiration cuts both ways and I hope nobody minds if I use USKP-inspired code of my own from this in a future version of ASG. Presumably I'll be gracious enough to include credit there, but whatever.
  8. Actually, I was wrong. It looks like it is used by Hearthfire for the waterfall salmon, for the roe. But, I don't think anything should be done with ingredients in the OnHit() event handler, only OnActivate(). For OnHit(), the script will place the dead salmon (DeadFXSalmon0X) which already give the roe. The vanilla script seems to actually place the ingredient directly in the world, in addition to the flora object (i.e. DeadFXSalmon0X), which shouldn't be happening. So, the MyIngredient property is used in the OnActivate() handler, and needs to be used; and MyIngredientRef is used in vanilla in the OnHit() handler, but should not be, since those are added directly to player inventory (via the flora or container object placed in the OnHit() handler). Here's what I'm going to put in FloraRespawnFix in a few days: Scriptname FXfakeCritterScript extends ObjectReference {Make fake critters shootable} container Property myContainer Auto Flora Property myFlora Auto ingredient Property myIngredient Auto potion Property myFood Auto string Property myLocationOffset Auto string Property myFakeForceExplosionOffset Auto Explosion Property myExplosion Auto Explosion Property myFakeForceExplosion Auto objectReference myContainerRef objectReference myIngredientRef objectReference myExplosionRef objectReference myFakeForceExplosionRef objectReference myFloraRef int Property numberOfIngredientsOnCatch Auto int property hoursBeforeReset = 72 auto Event OnActivate(ObjectReference akActionRef) self.disable() if myFood game.getplayer().additem(myFood, numberOfIngredientsOnCatch) endif if myIngredient game.getplayer().additem(myIngredient, numberOfIngredientsOnCatch) endif RegisterForSingleUpdateGameTime(hoursBeforeReset) EndEvent Event OnHit(ObjectReference akAggressor, Form akSource, Projectile akProjectile, bool abPowerAttack, bool abSneakAttack, bool abBashAttack, bool abHitBlocked) if akAggressor == game.getplayer() if myContainer myContainerRef = self.placeAtMe(myContainer, 1, false, true) utility.wait(0.01) myContainerRef.enable(false) myContainerRef.MoveToNode(self, myLocationOffset) endIf if myFlora myFloraRef = self.placeAtMe(myFlora, 1, false, true) utility.wait(0.01) myFloraRef.enable(false) myFloraRef.MoveToNode(self, myLocationOffset) endIf utility.wait(0.1) self.disable() RegisterForSingleUpdateGameTime(hoursBeforeReset) endIf EndEvent Event OnUpdateGameTime() enable() if myContainerRef myContainerRef.disable() utility.wait(0.1) myContainerRef.delete() myContainerRef = None endif if myFloraRef myFloraRef.disable() utility.wait(0.1) myFloraRef.delete() myFloraRef = None endif endEvent I've taken out the cleanup for MyIngredientRef from the update event handler, since that's never used anyway, and nulled references to any previously-placed objects. Otherwise, same as before. I did notice another thing though, when looking at this, in the USKP and UHFP. For the waterfall salmon, in the unplugged game (without Hearthfire even) the meat is added via script when killing then harvesting. USKP changes this to adding via the ingredient field for FLOR objects. This is fine, although AFAICT it doesn't make much difference either way. For the UHFP, the ingredient field is changed to BYOHSalmonRoe01, so the player gets the roe instead. However, both the meat and the roe are already added via script (and, indeed, they need to be added via script, since the player is supposed to get two items and you can add only one by using that field). So, if you kill waterfall salmon and then harvest them, you'll get an extra roe - once from the script, and once from the field. That field should be put back as None in UHFP, as it is in vanilla Hearthfire. Then the player will get one of each. If you directly harvest the salmon instead, without killing first, everything appears to work fine I think, because the DeadFXSalmon0X objects never gets placed by fxfakecritterscript anyway.
  9. Thanks for the heads up. FYI (although I guess DayDreamer at least has already seen this): http://www.creationkit.com/Persistence_%28Papyrus%29 I thought using OnUpdateGameTime events for this was going to be considered harmful? Not by me, that is, since I use it in FloraRespawnFix... Strictly speaking, I think it is better to say that "deletion" does happen, whatever that even means, but garbage collection doesn't, since there are still references pointing to it. Although it's really splitting hairs, since it seems like we've been using delete() as though it was free() which apparently isn't the case. It's a pretty interesting thing. Usually a garbage collector just frees up objects if they don't have any references pointing to them, but in this case just because it isn't reachable from Papyrus, doesn't mean Skyrim.exe isn't using the object anymore. So, it seems what delete() really does is tell the executable to let go of the object, but then the Papyrus VM can still hold on to it as well, so you have to clear that out too. At least, that's my working theory - I may have missed something.
  10. FWIW, I thought the same thing about the Matching Set perks, where originally they gave a bonus of AR * 1.2. The "bug" was that the description reads something like "Additional 25% armor bonus when wearing a matched set of heavy/light armor." But, if the "additional" means "in addition to Well Fitted/Custom Fit" this is actually correct, because 1.25 * 1.2 = 1.5 for a 50% total bonus with both perks (so, the perks are additive - Matching Set is additional - instead of multiplicative). I said my piece in the original ticket comments, but USKP changed it anyway. Then Bethesda changed it as well in 1.9. So I was "wrong". (Actually, I think both USKP and Bethesda are wrong on this, and I've changed it to the "correct" values for myself, but there it is.) Sound logic and correct math are the right way of doing things in Skyrim modding only until they aren't. I think in this case, they probably aren't :-(
  11. and then... Okay, this is the second time you've done this in this thread, and while others have addressed it they really haven't put it in strong enough language IMO, and maybe you're not getting it yet. So I will. You're very much out of order, knock it off now. There is no grand conspiracy to "trick" or otherwise coerce mod authors into parenting USKP for whatever nefarious motives you've dreamed up. The thought of it is so fucking bizarre - it's easily the stupidest thing I've read in a good while, not counting anything on reddit of course. And, if it were true, how could you possibly think that posting a thread asking about this stuff would make any difference? If we really are the mustache-twirling villains you're making us out to be - hell-bent on... well whatever reward you get out of tricking people into adding your mod as a parent of their own (could you help me out with this btw I still don't get the motive...) - if that were the case do you really think we'd actually admit it? So either you're wrong, in which case bringing it up just alienates everyone, or you're right and there is no point in trying to reason with us anyway. There just isn't a scenario in which making this kind of accusation advances your cause at all. Anyway, you have your totally wrong opinions or suspicions or whatever and you're entitled to have them. But you must understand - and by that I mean you must understand, if you want to participate in society - that accusing people like that puts them on the defensive. It absolutely and immediately kills the prospect of collaborative work. It doesn't make people want to help you. Even if you're right (which, again, you really obviously aren't). Do you really not get that? Because if you don't, and if you don't I'm going to assume that you have some kind of mild illness, do please try to keep it in mind in the future, on an intellectual level at least if isn't just an intuitive thing for you. I mean, it was hard to write this post, because on the one hand it's possible that social stuff doesn't come naturally to you for whatever reason, and I don't want to be cruel. But on the other hand, you need to hear this stuff. It's for your own good.
  12. The credits for the project are as follows for 2.0.0a: I don't know to what extent that's being actively updated, but I've done a couple more things than just the Ancient Knowledge Fix. And really, while maybe when Kivan put that there for the 1.0.0 release it was a bigger portion of the patch, now it's such a small thing compared to everything else that I'm actually a little embarrassed that it's still even there. Personally I'd prefer just a "contributors" portion with everyone involved just lumped in there, and then perhaps a few shout-outs to the more heavyweight contributors. If anyone disagrees then fine please don't lump them together, but at least change mine to "for a small number of small fixes to small bugs" or something. Thanks.
  13. I have, on one started since 2.0.0a. No problems with bear traps at all. Although, I seem to be immune to bugs these days. People are reporting CTDs with Acquisitive Soul Gems that I can not reproduce :-( So, YMMV.
  • Create New...