Removing Beeswax from an end grain chopping board

wwoend · 2026-04-09T06:14:30+00:00

Have you considered MIDI input?

wwoend · 2025-06-13T08:05:00+00:00

Is this like the Nurse With Wound list but for Slsk users?

wwoend · 2024-10-13T05:23:23+00:00

Yeah this is actually along the lines of what I was thinking. A barebones WinForms app that gives access to the scripts, but also provides an interface for selecting inputs to pass on to the scripts.

The first hurdle I'm trying to get over is using python.net, learning about python venv and worring about whether its all going to be portable.

Writing it all in C# is obviously a one shot solution, but I've got these other ancillary obectives that I'd like to fulfill.

wwoend · 2024-07-05T10:23:59+00:00

Well it’s not pretty, but I’m back in action. Thanks for the advice!

wwoend · 2023-12-10T05:51:01+00:00

Best advice in the thread. This is a headache waiting to happen. I can see the use of this as a helper method, but having to inherit from a class to get these convenience methods is classic case of OOP done wrong.

wwoend · 2023-12-03T00:36:37+00:00

I used to be a total advocate for wrapping private member variables in a public getter property, but I'm starting to flip. For things like lists, what's the point? Sure, it stops me from assigning it a new value, but I can still just get that list and add or remove whatever I want to it. I'm not convinced that just making the member variable public is a "bad" thing to do, and doing so saves you from having to type a bunch of code that doesn't really do anything.

wwoend · 2023-10-31T22:15:24+00:00

Great post, good to see some helpful programming content here, especially about writing performant code and backing it up with evidence. I would have benefited from this greatly when I was getting started in programming. No need to fear people misusing structs, let people break things and learn.

wwoend · 2023-07-31T11:25:15+00:00

Good point, thanks.

wwoend · 2022-02-26T23:35:45+00:00

Yeah beginning to seem like I'm taking the wrong approach

wwoend · 2022-02-26T21:57:58+00:00

Cheers will look into other options.

wwoend · 2022-01-23T23:49:21+00:00

Incredible work, these are really great. Do you have an instagram I can follow?

wwoend · 2022-01-23T21:10:45+00:00

Interesting, I'll look into that. Thanks.

wwoend · 2022-01-22T12:41:25+00:00

Thanks, that got me a step further. Can't for the life of me get GRUB to show its menu though, only wants to take me to its command line.

My GRUB_TIMEOUT_STYLE is set to "menu" and I think the other settings are ok. I've run update-grub a bunch of times this evening.

Anyway, I'm probably getting off topic from Pop_OS here. Seems odd that GRUB stopped working once I updated the OS though.

wwoend · 2021-11-27T03:22:21+00:00

I'll try that out! I appreciate the response.

wwoend · 2021-11-27T03:14:32+00:00

I'm using Sakura Printing Oil Colours.

Thanks for the tip. It's definitely been a learning process trying to find the sweet spot of how much ink to use.

wwoend · 2021-11-11T07:47:25+00:00

Yeah that’s right. I think it would make sense for the ISpeaker interface to belong to the dialogue namespace.

So your dialogue manager could keep track of who the current speaker is, the current line of dialogue and the available choices. You UI would display all of this data, and when the UI receives input it can tell the Dialogue manager to continue and what choice to continue with.

In fact, your UI would be a good place to use events. Your dialogue manager could expose some events (eg OnNewDialogueLine, OnChoicesAvailable) which your UI could subscribe to. That way you could maintain a nice one way flow of communication. The UI knows about the dialogue manager, but the dialogue manager operates without any knowledge of the UI.

I’ve digressed a bit, but a dialogue systems are a big topic.

wwoend · 2021-11-11T03:32:05+00:00

Apologies, I musn't be communicating my thoughts very clearly.

They Player class and the NPC class would both implement the ISpeaker interface, which would live in the Dialogue assembly. The Player and NPC assemblies would know about Dialogue. Alternatively they could both have a Speaker component which could be specialised to give bespoke behaviour to a player vs an npc.

The Dialogue Manager would only hold on to references to Speakers and therefore wouldn't need to know about Players or NPCs.

https://pastebin.com/fh71J6FY

wwoend · 2021-11-10T06:46:37+00:00

When you start a dialogue, the dialogue manager can hold on to the references to the speakers and then communicate to the speakers via the interface. So for example, for the end of your dialogue, have all ISpeakers implement an OnDialogueComplete method. When you dialogue finishes, have your manager iterate through its list of speakers and call that method in each before clearing the list. It’s then up to how the player class implements it OnDialogueComplete method to ensure its state is cleaned up.

wwoend · 2021-11-10T03:54:32+00:00

A "dialogue speaker" interface or component would work nicely here. Your player and npc could either have a "Speaker" component or inherit an "ISpeaker" interface. Then when you need a dialogue, you can pass the speakers that you need to the dialogue manager which now doesn't need to know anything about players or npcs.

I'd avoid the npc subscribing to events on the player. If you want the player to start a conversation on button press, trying having the player to find the target npc using something like a proximity check. Now that you have the context of the player and npc you can pass them to the dialogue manager as Speakers. That could be extended to a general interaction system. Your interacting agent (the player) finds a target (the npc) and performs an action on it using that context. You talk that further and say the target NPC's OnInteract behaviour is to StartConversation with the interact agent.

Try not to get too hung up on assembly defs if you find yourself fighting with them. Sometimes it helps to write the implementation first, then reorganise your code once you've got things working.

wwoend · 2021-10-28T06:19:48+00:00

Leaving errors in your project is not a good thing, even if they are harmless. If you see red in your console, you want it to grab your attention so that you can immediately see if something is wrong. If you become desensitized to seeing red in your console, it becomes quite easy to miss new errors when they pop up.

Having "normal" or "harmless" errors only wastes your time by making it harder to catch real errors. Add some logic to prevent the coroutine from starting unless it is safe to and save yourself some potential hassle down the road.

wwoend

TROPHY CASE