Downloaded the zipped version of the source code today specifically to peek into Woohooer, but apparently 2 cs files concerning the Woohooty text were absent so it wouldn't compile? No biggie since all I had to do was remove them from the project but just thought someone should know.

Now on to my main question: I recently released a mod making the Eiffel Tower from EA usable as a rabbithole (using the code that was always there but never actually used), and was wondering what it would take to make it Woohooer compatible.

Well, technically it already is since the Eiffel Tower class is derived from the Restaurant class which is already covered by Woohooer's version Visit Rabbithole interaction, which does show up on the Eiffel Tower fine. Thing is the Eiffel Tower has 2 kinds of "Visit" interactions (Take Elevator and Take Stairs), neither of which Woohooer's VisitRabbitHoleEx interaction replaces like it would for other rabbitholes with a visit type interaction. Then again, since these interactions differ from the generic EA Visit Rabbithole ones (they both add a moodlet, Taking the Elevator charges money, Taking the Stairs provides Athletic skill, etc.) replacing them with Woohooer's generic Visit Rabbithole interaction is something I'd rather avoid. After peeking into Woohooer's VisitRabbitHoleEx, I thought adding about a new entry to the Parameters Dictionary just for the EiffelTower class, but since it's not a RabbitHoleType, that wouldn't work.

So, I'm guessing to replace the Eiffel Tower's visit interactions with ones that not only offer Woohooer's changes while retaining their original benefits would require a separate module for Woohooer? (The visit interaction injected by the base mod onto all Restaurant rabbitholes will need to be hidden as well, I'm guessing)

Kind of just thinking out loud here, would really appreciate the opinion of someone knowledgeable on the workings of the mods here.

My apologies for the woohooty issue. That's a feature I am testing and it shouldn't have been in the project file.

Ditto to what SimAd said, a module is your best bet. Changes to the base mod for an optional object can cause crashes and is just a messy practice. I can't say any of us know the workings of the mod yet though. I have heavily studied it but only just started trying to extend it myself.

Okay, thanks guys, guess I'll start looking into modules then if and when I tackle this. The vastness of the Woohooer project really floored me the first time opening it, really looked like changing one line would send the whole thing crashing into a ball of flames! Hopefully a module will be much more manageable...

Well I started looking into this today, and as far as I can tell (and I honestly can't tell much) the modules are basically derived classes of the base mod's interactions with a WooHooLocationControl that basically tells the base mod that it's a separate object to be listed in the list of Woohoo locations (which is kinda unneccesary in my case since the Eiffel Tower should just count as any old rabbithole).

So I tried making my own classes for VisitRabbitHoleEx, VisitRabbitHoleWithEx and WooHooInRabbitHoleEx deriving from the originals, modified to add all the extra code from the Eiffel Tower's interactions, and thought that I could take advantage of the fact that the original Eiffel Tower basically comes with no interactions (EA simply removed all interactions from it) and get away with just injecting my derived interactions. Of course I totally forgot that the base mod would have first add the original VisitRabbitHoleEx interactions to the rabbithole and all I get is a ScriptError telling me "An element with the same key already exists in the dictionary."

Considering the original VisitRabbitHoleEx was written to cover all rabbitholes, deriving from it just to handle one separate case (and one that already derives from a class the original handles) may not be the way to go? I really don't know. I'd 'love' to continue stabbing in the dark at this problem, but RL beckons so it'll just have to wait for later.

Look at how Twallan did the "WooHooInResortTowerEx" code. It's a rabbit hole but EA put a custom WooHooInResortTower interaction on it, thus he couldn't use his mass handler. That may be of some help although I recognize the default WooHooInRabbitHole interaction on the tower is incomplete. I don't see why you couldn't axe it and inject your own though. You can setup a new module the way the others are, grab that code and edit it to inject the interactions onto the Eiffel tower.

Oh, I didn't even realize there was a separate WooHooInResortTowerEx, thanks for pointing that out. But taking a look into it, it looks like a standalone object woohoo interaction and not a visit rabbithole type woohoo interaction (where you have to use the Visit interaction first before you can choose to Woohoo with other sims in the rabbithole) that I need.

Well, good news guys, I managed to make my separate interactions work (turns out I was having the same problem as with my original Eiffel Tower mod. where deriving directly from the interactions I wanted to replace wouldn't work, but deriving from the classes the originals were derived from did). Still have a few concerns though:

1) If I try returning CommonWoohoo.WoohooLocation.RabbitHole as the Woohoo Location (just as in the original VisitRabbitHoleEx and WooHooInRabbitHoleWithEx classes), Woohooer throws the "An element with the same key already exists in the dictionary." ScriptError, BUT my interactions do show up and work properly. However now I get 2 identical Rabbithole rows showing up in the locations tab in the Karma Simtra challenges.

2) To overcome this, I tried returning CommonWoohoo.WoohooLocation.EiffelTower instead, which requires "Eiffel Tower" to be added to the list of enums in the base mod's CommonWoohoo.WoohooLocation, basically creating a new Woohoo location for the mod. Worked as expected, the new location showed up in the locations tab (untranslated), and woohooing in the Eiffel Tower using my interaction should be recorded properly there (I say should because I forgot to change the PostWoohoo line in my interaction so it still counted as a Rabbithole Woohoo instead as one in the new location, but I'm guessing it will once I change that). I did want to avoid doing this though since I'd have to alter the base mod (possibly only minimally, but still), but considering what happened in 1) I guess it might be necessary? Can't think of any other way besides perhaps adding a "if(target is EiffelTower), use my code instead" in the original VisitRabbitHoleEx which would be even more invasive.

3) Each of my interactions use a CustomInjector to both inject them onto the Eiffel Tower and remove their original base mod counterparts, but is it a guaranteed thing that the base mod interactions are injected first before mine (otherwise there would be no interaction to remove, if mine happened to go first)? There was twice while I was testing where the original Visit Rabbithole interactions appeared instead of mine, but those were because I tripped up somewhere in my copy and pasting and after fixing things my interactions would appear properly again.

If all goes well, this does look releasable as a module, the base mod would need to be updated to accommodate a new location though, unless knows a way around problem no 1? All it would need is the base Woohooer mod since all it does is inject the custom interactions to the Eiffel Tower class.

Do you need to visit a rabbit hole for the woohoo option to show? Interesting. Can't say I've used it myself.

If you are going to make a custom location, yes, editing the enum is your only option. Can't edit enums at run time. Unless you'd rather add a check around where the locations get added for values existing in the dictionary which is okay too. The Eiffel Tower seems like a special place to lump into the rabbit hole category but that's your call. I don't see it as an issue to edit it. Did you also implement a LocationControl class?