TMPhoenix

@diogopam: Did you install all the folders from the archive? There should be 3 folders, including zCaptivityEvents.

It is happening with events that I trigger right away, using the same id. Hadn't even considered longer term references. Good to know about the skill as a tag.

With the new companion system, is there a way of making sure the game targets the same companion between stages? I have set up an event that targets a companion; as a test I give out some relationship bonus; this stage then triggers a second event and here I again refer to the companion (I used the same id if that matters) and again give some relationship bonus. I noticed that this second companion is generally not the same as the one in the first event. Is there currently a way of ensuring follow-up events refer to the same companion? And is there currently a way to reference the companion in text, such as {COMPANION_NAME[<companion_id_here>]}?

carnalitas was updated... that's why it's not working. You probably need to alter your trait to set the trait flag and remove your modified trigger file.

I think you made a little copy-paste error in the attribute section of the asset. You have min there twice. I suspect one of them needs to be max (both in the attribute and the blend shape). Edit: Also if you wish to create a gene morph for it; you could use something like this:

I was testing Visual Studio Code and the CWTools extension on my own private mod and I noticed a lot of minor (and some major) issues with MASSA, would you like a link to a version of the mod where I've fixed some of the issues? If not I can still recommend the VSC + CWTools combo to debug issues with Stellaris mods.

@kortjakje: I think it's this: http://beverlyallitsims.tumblr.com/post/149006882065/afterparty-a-6-person-group-pose-you-will

Well I'm by no means an expert on animations but in a Maxis game animationElement definition they have this: 02d5df13:00000000:647c7ff6ab2a1561 as an asm_key, yet in your file you use: 02D5DF13-00000000-A60A24C37EDA9158 As you may notice the difference (aside from the exact id): 1. (probably irrelevant) caps vs no caps 2. : vs - as separator I suspect number 2 is relevant.

For the alien skins: I had a crash when an alien child was born. I traced it to the skins and after removing the tone entries from the package it no longer crashed and the skins look fine in game. P.S. Hope your cat gets well soon.

many thanks. It works not only on a fresh Game. Good to hear.

Okay, I've made, what I believe to be a functional fix; try this: LH_154_fix.7z I just tried it on a fresh game and it seems to work.

I believe the current problems are caused by some changes to the SL scripts. So far I've found that at least one property got renamed from "animation" to "animations", so that will require a fix to the scripts to get it working again. If someone could post a papyrus log of an attempt to use SL1.54 + LH with the force known animations option enabled, I could take a look.

Hey redneck2x, Could you please add a check for menumode on the 2 second "surprise". I have the button set to right shift and my char was happily enchanting. I was deciding on what to name the item and while I was thinking I must have held down the shift button long enough. That triggered the animation, unfortunately my character was stuck afterwards. Still, kinda funny.

That should be Lovers Comfort.

I've never not had Fuz-Roh-Doh install, and I still 100% disagree. Your function makes it less efficient and spend a an excess amount of time performing actions that shouldn't take 60 seconds to begin with. An actor not making the failsafe in time isn't even a major problem, the animation will continue on regardless, the only difference will be voice handling. Meanwhile holding them for 60 seconds in a failed thread is a lot of time that is going to break other mods attempting to claim the actor. If your "fix" for actorwait resolved your issue, I assure you your problem lies elsewhere, and not actually with actorwait itself. All you did was sweep the problem under the rug. But what do I know, I only hand wrote every scrap of code that exists in the mod. EDIT: If I'm coming off as an asshole here, I apologize, entirely not my intention. No need to apologize. I am not trying to attack you or your work. I just offered the snippet to give you an idea how I solved the issue is was having. Let's just agree to disagree, if that makes you feel happier. I'll keep my changes and I won't have the issue, which makes me happy. I assure you my changes are not less efficient. My loop is O(N), yours are in fact O(N^2). (for notation look up http://en.wikipedia.org/wiki/Big_O_notation) Both our approaches kick out of the loop at the end of the failsafe, so they do not differ there. My approach only checks each ActorSlot until it is in the desired state and if not it will wait half a second giving the actor thread hopefully enough time to finish whatever it was doing and going to the state we are looking for. During that time one (and possibly more) actor threads will get a chance to run. Your approach checks all slots up to the "failing" slot again (because of the inner loop) and if it encounters a failing slot it will wait 0.1 seconds in the outer loop. While 0.1s should certainly be enough to give papyrus the chance to have another thread to run, I personally feel it is better to wait fewer times but perhaps a little longer, as that should give other threads more time to do their thing. I completely agree the actions should not take 60 seconds, and they don't. I just feel that a failsafe should not be too close to the line. I could have gone for 30 seconds and it probably would have been fine as well. The failsafe itself should ideally never even be hit. It's just there to break the characters out of a potential infinite loop.