niston Posted March 12, 2019 Share Posted March 12, 2019 (edited) There's no such thing in Papyrus, is there? Maybe some technique for "faking" it exists? Edited March 12, 2019 by niston Link to comment Share on other sites More sharing options...
Reneer Posted March 12, 2019 Share Posted March 12, 2019 (edited) It would be helpful to describe what it is you are trying to do that would require multiple inheritance-like functionality. But to answer the question, no, I don't think there is any kind of multiple inheritance within Papyrus. Edited March 12, 2019 by Reneer Link to comment Share on other sites More sharing options...
pra Posted March 12, 2019 Share Posted March 12, 2019 You KINDA have multiple inheritance, if you attach multiple scripts to the same object. If you have two scripts which extend ObjectReference, you can attach them both to the same object, and then cast it to either. Link to comment Share on other sites More sharing options...
niston Posted March 12, 2019 Author Share Posted March 12, 2019 (edited) Figured as much, heh. Suppose I have two base classes, ByNPC and ByPlayer. Suppose I then add two derived classes, DooHickyByNPC which derives from ByNPC and DooHickyByPlayer which derives from ByPlayer. Suppose both of these derived classes share some of the functionality they add. It would have been helpful to put that shared piece of functionality into it's own DooHicky class and have both DooHickyByNPC and DooHickyByPlayer inherit from DooHicky, in addition to ByNPC or ByPlayer. I tried using an Import instead, but it seems to me one can only import functions and not variables etc? Also thats of course not real OOP xD Pra: I'm using the technique you suggest to let a control panel script interact with a backend script. The control panel is optional, and as soon as it's attached to an object that has the backend script already attached, it'll automatically link up. I don't think it's going to satisfy my desire for a clean design re the situation above, tho. I think I might attach DooHicky to a holotape or something instead, and then have a property for DooHicky on both DooHickyByNPC and DooHickyByPlayer. I can make these properties mandatory, so it wont be possible to have DooHickyBy... without DooHicky. Still, multiple inheritance would have been a so much more elegant solution. Love the immersive teleportation 2 mod btw :smile: Also Reneer's Radio mod much appreciated here :smile: Edited March 13, 2019 by niston Link to comment Share on other sites More sharing options...
pra Posted March 14, 2019 Share Posted March 14, 2019 The closest thing I can think of is now: make a new class derived from DooHickyByNPC, let's call it DooHickyFakeDualInheritance. Then, in that class, whenever you need functionality from DooHickyByPlayer, do a "self as DooHickyByPlayer", and make sure that the actual objects have both DooHickyFakeDualInheritance and DooHickyByPlayer attached. Link to comment Share on other sites More sharing options...
niston Posted March 17, 2019 Author Share Posted March 17, 2019 (edited) I could make DooHicky extend ObjectReference, and then have both DooHickyByPlayer and DooHickyByNPC cast like (Self as ObjectReference) as DooHicky, to access the common functionality in DooHicky. My concern re clean design was however to forbid, or make it impossible for, the user to use either DooHickyByNPC or DooHickyByPlayer in CK without also using DooHicky. Essentially a design time constraint, such as would be imposed by mandatory properties. But without MI, all the possible solutions will be both slightly half-baked and slightly retarted in some ways. This is sort of like "OOP" worked in Visual Basic 5 :smile: Edited March 17, 2019 by niston Link to comment Share on other sites More sharing options...
Recommended Posts