Fixed Can't sell fish

[cheesebehemoth]

I got the new fishing scene but can't sell the fish I got from it.

 

[Theron]

You're sure you didn't eat the fish?

Also, the event is supposed to be repeatable 'from the interaction menu, with a cooldown'. What interaction menu?

Edit:
1 The menu that repeats the event is only available once you've taken a walk with Carrie. 'Swimming Hole' only appears if you chose 'Build It' (i.e. started the Bad End).
2. The appearance of the menu is random and is often superseded by the Shower invitation. Which you can do from the 'interaction menu'.
Maybe make the 'interaction menu' the standard once the conditions are met? Might need to add 'Blowjob' to it, as well.

 

[cheesebehemoth]

Yeah,

You're sure you didn't eat the fish?

Also, the event is supposed to be repeatable 'from the interaction menu, with a cooldown'. What interaction menu?

It's right there in my inventory.

I think the bug might have to do with my inventory being full when I got it, repeating the scene with room in my inventory has the fish show up on the sell menu as normal.

 

[Skunkupine]

It's not the inventory being full - my Steele has 15 of 20 slots used, fish is in the inventory, and yet the fish does not show up when interacting with Smee.

 

[Theron]

It seems to be Spotted Grout, specifically, that cannot be sold.

showShop({
                    items: [],
                    shopkeeper: smee,
                    saleableFilter: function(e) {
                        return ["SpottegGrout", "BlueSteerpike", "PaleAlito", "GoldenFanfin"].includes(e.getClassName())
                    },
                    onInspect: rs,
                    shopMode: _.yO.SELL

"SpottegGrout" > "SpottedGrout"

 

[Skunkupine]

It seems to be Spotted Grout, specifically, that cannot be sold.

Then there should be some form of notification that it cannot be sold.

 

[Theron]

Then there should be some form of notification that it cannot be sold.

It's a typo in the Shop code. See the edit to my above post.

Additionally
1 The menu that repeats the event is only available once you've taken a walk with Carrie. 'Swimming Hole' only appears if you chose 'Build It' (i.e. started the Bad End).
2. The appearance of the menu is random and is often superseded by the Shower invitation. Which you can do from the 'interaction menu'.

 

[Jacques00]

Just to clarify, it's only the Spotted Grout that's not appearing as a sellable item, correct? This should be fixed for the next release.

 

[Theron]

Just to clarify, it's only the Spotted Grout that's not appearing as a sellable item, correct? This should be fixed for the next release.

When I 'cheated' in all 4 fish, the Spotted Grout was the only one that couldn't be sold.

 

[Skunkupine]

It seems to be Spotted Grout, specifically, that cannot be sold.

showShop({
                    items: [],
                    shopkeeper: smee,
                    saleableFilter: function(e) {
                        return ["SpottegGrout", "BlueSteerpike", "PaleAlito", "GoldenFanfin"].includes(e.getClassName())
                    },
                    onInspect: rs,
                    shopMode: _.yO.SELL

"SpottegGrout" > "SpottedGrout"

Ugh. As an object-oriented programmer of several decades, this is very ugly. Why not just give the objects a flag "isNTFish" and test for the presence of that flag? That way, all tests, both for leaving the planet and for selling, are the same, AND you can add new fish at any time without touching the code.

 

[Jacques00]

Ugh. As an object-oriented programmer of several decades, this is very ugly. Why not just give the objects a flag "isNTFish" and test for the presence of that flag? That way, all tests, both for leaving the planet and for selling, are the same, AND you can add new fish at any time without touching the code.

Understandable critique, and I do agree. But this project, since the Flash times and after the JavaScript code migration period has always been a bit of a slap-dash approach--mainly for readability when old code is revisited and new code is tacked on for unique content. I'm sure the dev team will agree that if and when a new project is created, that there will be a more formal and neater way of coding, especially with all the experience built up so far. But as it stands right now, unicorn sections of the code can remain bespoke if there doesn't seem to be any future expansions to the respective content (fish in this case--if this was a fishing simulator or had multiple fishing events, yes, that coding critique would hold more weight!).

There have been a few attempts (as in many, many waves) to refactor the code by different contributors, but that usually led to headaches when one coder can't make sense of another coder's refactor (due to change of habit or honest illegibility), and can also introduce a pile of other bugs that need hunting down and correcting. At this point in the development cycle, we've made peace with the mess we've made. Yes, the code is spaghetti, but it is our spaghetti and we know how it works (for the most part), so we'll know how to fix it if things get too tangled.

Edit: And for adding a new flag, while it sounds simple enough, and works well for expandable content, our save system will need to account for that, so adding one flag for a simple item object may add that flag to multiple items, especially those that don't even use it, and will bloat save data (like in the case of chameleon tech items). So it's weighing the cost-benefits of the change as well. If it's a flag worth putting in, it can be added, if not, then don't bother and just use straight code to parse things instead.

 

[Skunkupine]

Edit: And for adding a new flag, while it sounds simple enough, and works well for expandable content, our save system will need to account for that, so adding one flag for a simple item object may add that flag to multiple items, especially those that don't even use it, and will bloat save data (like in the case of chameleon tech items).

Considering the amount of data in the creature object that almost never gets used (e.g. pregnancy data, shopkeeper data, etc) and the amount of stuff that gets serialized in the saves as a result, "bloat[ing] save data" is a bit of weak argument.
But I agree - this late in a project, you have to balance paying off technical debt vs. just finishing the project and declaring technical bankruptcy. BUT: If you aren't going to finish the project, then a derivative of the old aphorism applies: "The best time to write clean code was a decade ago. The second best time to write clean code is now."

 

[Jacques00]

Considering the amount of data in the creature object that almost never gets used (e.g. pregnancy data, shopkeeper data, etc) and the amount of stuff that gets serialized in the saves as a result, "bloat[ing] save data" is a bit of weak argument.

Yes, agreed--though I wasn't trying to make an argument, just stating the team's rationale of why things are the way they are at current. Tacking on things that can potentially be serialized is just another concern to add to the list of concerns. For me personally, I would rather not add more bloat if it can be helped, though these fish items are probably not the best example for that.

But I agree - this late in a project, you have to balance paying off technical debt vs. just finishing the project and declaring technical bankruptcy. BUT: If you aren't going to finish the project, then a derivative of the old aphorism applies: "The best time to write clean code was a decade ago. The second best time to write clean code is now."

Yep, and we are definitely still cooking, even if it feels like slow cooking from the outside. We'd rather not have janitorial duties that lead to more janitorial duties while in the final stretches (and as mentioned, we've had numerous waves of custodial tasks before that we'd rather not re-experience) that ultimately slows the project down even more. For a newer project, hopefully it'll be a much smoother and well-regulated experience compared to this decade-old project.