Papyus, change Actor height and... design patterns???

[Papitas]

Hi!

 

This is my first forum participation, even though I've been around here for a long time.

I come to you with questions because I know this is a friendly and SERIOUSLY knowledgeable community on Papyrus programming.

 

On to business.

 

Changing player height

I made a mod that changes player weight to gain muscle (Sandow Plus Plus at the Nexus -note to moderators: it's not my intention to come here to spam. Please, feel free to erase my link if you consider it pertinent-) and it works as intended, no questions on how to do that.

BUT, one user suggested me that my mod could also gradually change the player's height; and before considering designing how to integrate that, I need to know if it's even possible.

Since SexLab can do that, that's why I come to you.

 

As far as I have seen, it seems there's an SKSE function that can do that, but it doesn't change the player's bounding box.

Is there some way to do proper height changing?

 

And how about CTDs? I ask about that because SexLab warns about possible CTDs when using the feature to average actors height when entering sex animations.

 

 

Design patterns. Are they even possible in Papyrus?

I know Papyrus, being a scripting language, was never intended to be a full featured programming language, but it also seems odd to me that it has rudimentary inheritance capabilities but no straight forward way to instantiate new scripts/objects (well, by the veeeeeeery little I know about the way Skyrim was designed, it's not that odd, actually).

 

You see, my aforementioned mod's implementation its quite monolithic to my tastes and I think it applying design patterns would really make it easier to make expansions to it.

 

I would like to make some easy patterns based on object composition and such to be able to cleanly change algorithms at runtime and things like that. Nothing too fancy, really. I don't even need Interfaces to simulate multiple inheritance or whatever.

But since there are no "new <Whatever>" kind of capabilities for Papyrus, the only ways I can think of pulling what I want is to make scripts extending Quests (which would mean having one quest for each functionality) o even worse, permanent invisible actors lying around.

 

Is there some way to implement something that can resemble what I want to do that doesn't involve those two kind of things?

Are Quests my best bet, as I suspect?

 

And... if that's not possible, how can I move some of my code out from the main script, so it looks cleaner and is easier to maintain and expand? 

Do I necessarily need to make all those functions I take out Global?

 

 

Thanks in advance. 

Have a nice day!

[Holzfrau]

2 hours ago, Papitas said:

I would like to make some easy patterns based on object composition and such to be able to cleanly change algorithms at runtime and things like that. Nothing too fancy, really. I don't even need Interfaces to simulate multiple inheritance or whatever.

But since there are no "new <Whatever>" kind of capabilities for Papyrus, the only ways I can think of pulling what I want is to make scripts extending Quests (which would mean having one quest for each functionality) o even worse, permanent invisible actors lying around.

You wouldn't necessarily need multiple quests, you can attach multiple scripts to the same object.  If you already have a main script, you can attach your algorithm scripts to the same object, just make sure they don't have events that they will be firing - put the events in the main script and let it decide which algorithm to use instead.  In your main script, there are two ways to get at your algorithm scripts.

1. Add a property for each one (e.g. "MyAlgorithmAScript Property AlgorithmA  Auto"), and then set that to the same object both scripts are attached to (or it can reference the script on a completely different object if needed, like if you use a separate quest to act as a shared library).
2. You can do some typecasting wizardry to get the other script if they're on the same object.  For example, if your scripts are all on a quest you can do it like so: (self as Quest) as MyAlgorithmAScript

You can simplify your algorithm selection code by making a base script with empty functions (the Papyrus equivalent of an abstract class), and using your various algorithm scripts to extend it.  Then you can use Papyrus' polymorphism support to hot swap which algorithm script you're using on the fly.  I can detail this further if you're not sure how to accomplish it.

 

Alternatively, you could use script states for hot swapping as well, if you don't mind having the code for all of your algorithms crammed in a single file.

[Papitas]

5 minutes ago, Holzfrau said:

You wouldn't necessarily need multiple quests, you can attach multiple scripts to the same object.  If you already have a main script, you can attach your algorithm scripts to the same object, just make sure they don't have events that they will be firing

Oooooh... thank you so much!

I haven't tried it yet, but I conceptually understand how method #1 works.

 

I have another question about attaching multiple scripts to the same object:

Does that mean all of those scripts should descend from Quest too? Or can they be descended from another class, like... I don't know... Actor, for example?

 

Quote

I can detail this further if you're not sure how to accomplish it.

Thank you so much! I think I got this.

Since there are no true abstract methods, interfaces, etc, I should write my abstract methods as empty functions.

My "high level communication" between "interfaces" would be calling generic parent algorithms with empty functions.

That's exactly what I wanted to do! :3

 

Quote

Alternatively, you could use script states for hot swapping as well, if you don't mind having the code for all of your algorithms crammed in a single file.

 

I think I can even cram all states in a parent algorithm and let its descendants implement whatever things to do in those states, so my code could be even cleaner.

 

Thank you so much! 
I really appreciate your help

[Holzfrau]

11 minutes ago, Papitas said:

I have another question about attaching multiple scripts to the same object:

Does that mean all of those scripts should descend from Quest too? Or can they be descended from another class, like... I don't know... Actor, for example?

They would have to descend from whatever form type you're attaching them to.  So likely Quest, yes.

Quote

I think I can even cram all states in a parent algorithm and let its descendants implement whatever things to do in those states, so my code could be even cleaner.

I'm not really sure how state changes work alongside inheritance, you'd have to try it for yourself if you want.  States are intended as multiple modes of operation within a single script, so it doesn't sound to me like any sort of inheritance is needed here.

 

PS:  When you need to break apart a quoted post so you can reply to individual parts, add two line breaks and it will split apart for you.

[Papitas]

4 minutes ago, Holzfrau said:

They would have to descend from whatever form type you're attaching them to.  So likely Quest, yes.

Cool! Now I totally understand all of this.

 

4 minutes ago, Holzfrau said:

I'm not really sure how state changes work alongside inheritance, you'd have to try it for yourself if you want.  States are intended as multiple modes of operation within a single script, so it doesn't sound to me like any sort of inheritance is needed here.

I'll test it and report results to all of you

 

4 minutes ago, Holzfrau said:

 

PS:  When you need to break apart a quoted post so you can reply to individual parts, add two line breaks and it will split apart for you.

Honestly, I wrote this fragmented post just to see how that looked like  ?

 

Thanks again!