Thanks for your response.

should never embed classes within other classes)

Why is this? I have to admit that coming from other languages, it feels dirty, but is there a pythonic good reason for this? The class ‘belongs’ to the FoldableDockWidget class, so I figure it’s the best place to put it.

Thanks. I wondered why I instinctively text-transformed the title of the widget to uppercase! I commented it out thinking perhaps it doesn’t look grammatically correct! Reduced the font size a bit and I think it looks a heck of a lot better now!

Qt automatically handles the conversion of QDockWidgets into tabbed docked widgets when one is dragged over an existing one.

I have a little demo video, but I have no idea where to upload it to!

Awesome! Maybe this should be added to the topic of each language-specific channel?

Why not have one class that has a level for each trait, which are scored 0-100, 0-10 etc. so… self.luck = 7.3 self.anger = 4.0 and so on. And then there’s one method that determines the action. That’s going to be so much easier to maintain, extend, and work with.

class CharacterTraits:
  def __init__(self, luck, anger, magic, ...):
    self.luck = luck
    self.anger = anger
    # and so on

    # maybe keep a list of previous actions which could inform the next action state
    self.history = []

  def get_action(self):
    # do whatever to decide action
    action = ...

    # then add it to history
    self.history.append(action)

    return action

and then the calling code determines what’s output to the screen. So, internally, the class is just responsible for one thing - hte business logic. Maybe another class Game could be responsible for outputting the strings, taking user input etc. If the UI were to change at a later date, the CharacterTraits class stays the same, but only the Game class would need to be modified. Instead of - as I understand it - all the classes currently would have to be updated (a maintenance nightmare!)

I only had a really quick look down the code so I may be missing the point entirely, but that’s the direction I would go down.

EDIT: the get_action method could take in some args, like opponent_traits or some kind of situation, maybe even add additional methods like is_lucky to return a bool as to whether a situation that requires luck has been successful or not. Another method could be has_won_fight(opponent_traits) and the method compares strength, luck, magic whatever, to the opponent to decide whether the character has won. And so on. By keeping it simple like this, it’s a lot easier to work with!

They currently have the parent class “Action” for their common attributes and methods. Does that cover what you are suggesting?

I didn’t see, but if they want a trait that has a completely set of different methods? I’m not a big fan of interface-esque classes unless the API is absolutely solid. In this case it would not be.

Is libtorrent actually installed as a package? I see you’re on windows, but surely there’s an so you need to download or such? Haven’t used windows for many years though.

I’ve only glanced down your code and am not familiar with your previous efforts. Combine insulting and stirred-up to one class. “CharacterTraits” or so. This then makes it easier to add more traits like happiness, warmongering, intelligence, luck etc.

Much. passive. angry.