my_hat_stinks

This new regulation protects the victim since they’d no longer have to get that information, they can get compensated directly from the owning company. The company can then presumably try to claim damages from the rider, I’m betting there’ll be a clause you agree to when renting which says you’ll have to pay up, but the victim doesn’t have to worry about any of that.

From the article it seems like they’re more focused on damage caused by leaving the scooters in dangerous places anyway, in those cases it’s much harder to identify who caused it. Making sure victims don’t have to wait around for that investigation seems reasonable, that could take a while if the owners aren’t liable since they won’t really care. It might even encourage the company to make sure their scooters are always stowed safely. Probably not, but it’s nice to be optimistic sometimes.

16.2°F

I’ve only just started with Godot so I can’t give you anything Godot-specific, but it sounds like you’re asking for the logic to link things together. I’ll make some recommendations here but you’ll definitely have to adapt it to work for you. There’s a few different ways to do this and it depends on exactly how you want your system to work. From what you’ve said it seems like you have (or want) two classes, a PointManager and an EquipableItem (or whatever you’ve called the class in your pastebin).

What do you mean by groups here? You’ve identified global groups as a potential approach and that does seem to be a reasonable approach to access your EquipableItems from your PointManager, but I’m not sure that’s what you’re actually asking about. You’d have to set up a group for each category of item and add your items to the appropriate groups as they spawn, that seems a bit excessive.

The first approach to grouping objects I’d use would be with enums, this gives you fixed pre-defined categories so is useful for assigning an equip slot to each item, for instance.

/// Set up enum
enum ItemSlot {
    HEAD,
    TORSO,
    LEG,
    // ...
}

// Assign slot to item
@export var slot = ItemSlot.HEAD;

You can then verify this at two points: when you try to equip a new item you can verify that that slot isn’t already used, and when you count points you can make sure you only count each slot once. If you want to put an item in multiple slots (eg a dress is torso+leg) you can look into bitwise enums and bitwise logic, but that’s a little more advanced so I’d recommend getting the groundwork in first.

The second approach I’d use is a tags system, this is more flexible and can be be used for categorising outfits into as many categories as you want. The simplest way to do this is just an array of string IDs or ints, but this is more prone to user error since you can typo the string or enter the wrong number. On the plus side there’s no central enum so you can add new categories whenever you want, even creating a custom category at runtime if you need to.

@export var categories = ["Outfit.Clown", "Color.Yellow", "Type.Fun"] // Any arbitrary tags can be added

My first approach here is just to fire an event to make your PointManager recalculate. Ideally your manager would be doing all of the calculation and the equipped items wouldn’t hold any of that logic, but you would need a function on the items themselves to they can check if they can be counted (ie in the correct position). I believe in Godot that would be using the Signals system, full tutorial in the docs here. Event-driven programming is incredibly useful for game dev, even if you decide not to use this approach here I’d still recommend trying to get the hang of it.

Your drag function is doing a lot so it does need split up and simplified a bit, but for our purposes it’ll be enough to combine the two elif branches since they’re doing the same thing, that lets us fire the event in one place for both successful and unsuccessful drag so we can recalculate the score. You’ll end up with something along these lines:

/* EquipableItem */
signal on_equipment_updated;

func _on_area_2d_input_event(_viewport: Node, event: InputEvent, _shape_idx: int) -> void:
   if event is InputEventMouseButton:
      if event.pressed:
         // [..]
         pass
      else:
         if positionIsPerfect: // add position check here
            position = perfect_position
         dragging = false
         audio_stream_player.pitch_scale =0.5
         audio_stream_player.play()
         
         // Fire the event
         on_equipment_updated.emit() // We can optionally pass this item to the event too if needed

// Might need an export or something to be accessible to point manager?
func is_scoring():
   // Check position or any other issues here, return true to score this item
   return position == perfect_position;

/* PointManager */
var score = 0;

func _on_equipment_updated():
   // Reset score
   score = 0;

   // Get equipment (assuming using groups), might need a bit more to access the item script?
   var items = get_tree().get_nodes_in_group("equipped_items")
   
   // Count scoring objects
   for item in items:
      if !item.is_scoring():
         continue;
      // This is also where you'll check tags/categories/etc for bonus points or preventing duplicates
      score += 1;

The major benefit to using events here is that it almost completely decouples your scoring system from your items, your items shouldn’t need to reference your scoring system at all but they’ll still be counted as needed. You can swap in different items without touching the point manager, and you can write a completely new point manager without having to update anything on the items. There’s exceptions for everything, but as a general rule of thumb the more tightly coupled your code is the harder it is to maintain.

This depends on exactly how you want the items to score together, but we can handle that with the tags we set up before. Let’s say for instance we’re only scoring items with a specific category, we can simply check if the item has that specific tag before we score it.

/* PointManager */
@export var scoring_category = "Outfit.Casual"

func _on_equipment_updated():
   // [...]
   for item in items:
      if !item.is_scoring():
         continue;
      if !item.categories.has(scoring_category):
         continue;
      score += 1;

Or we could use the same idea to, for instance, only score whatever outfit category appears the most

/* PointManager */
func _on_equipment_updated():
   // [...]
   var scored_categories = {}
   for item in items:
      if !item.is_scoring():
         continue;
      for cat in item.categories:
         if cat.beings_with("Outfit."):
            scored_categories[cat] = (scored_categories[cat] or 0) + 1
   // Use best outfit score
   score = scored_categories.values().max()

Obviously this is all very rough but it should at least give you somewhere to start with your logic.

What you’re describing there is an etymological fallacy, a surprisingly literal one at that. By that logic the word “literal” should only refer to written text since it originated from the Latin word for letter, as in alphabet characters. Words’ meanings are defined by how they’re used, you’re complaining about how the word is being used, and you claim anyone using it doesn’t understand the meaning of the word. That is prescriptivism.

Why not? English is full of synonyms. It doesn’t matter whether you think it “makes sense”. Why waste the effort attacking word choice when you knew exactly what they were trying to communicate?

Linguistic prescriptivism is nonsense, you personally not liking how a word is used does not make that usage incorrect.