Feature request: Implement BUILD_YOUR_WORLD daily task.

[tickBit]

What do you want to see in the API?

There are new furniture categories coming, this is not to be implemented yet

From the API user’s perspective, the task should be completed automatically when a player saves a room layout that meets the task requirements. The client should not need to call the UI daily task endpoint for this task.

How do you think this should work?

When a player saves a room layout, the backend should check whether the saved room qualifies for BUILD_YOUR_WORLD.

The task is completed when all of these conditions are true:

• The player saves the room layout/appearance.
• The room contains at least three furniture items.
• All furniture items in that room belong to the same furniture set/collection.

Furniture set detection should be mapped explicitly in backend code instead of relying only on fragile string splitting. Current known furniture set categories appear to be:

• Muistoja
• Taakka
• Uni
• Rakkaus
• Kylmä_tulevaisuus
• Neuro
• Schrodinger
• Kipu
• Polarity

The mapping should be maintainable and scalable, so sets can be added, removed, or renamed, and furniture items can be added to or removed from sets without rewriting the task logic.

When the conditions are met, the backend should emit/update the reserved BUILD_YOUR_WORLD daily task for the player.

Any additional info?

BUILD_YOUR_WORLD currently exists in ServerTaskName, which fits this approach.

A likely implementation point is the room layout save flow, especially where room furniture updates are handled. The controller/service may need access to the logged-in player id so the daily task progress can be emitted for the correct player.

Add BUILD_YOUR_WORLD to the server task refresh/generation logic as well.

Suggested implementation for mapping furniture sets:

Create an explicit furniture set enum and mapping instead of deriving the set only with string splitting.

Example:

export enum FurnitureSet {
  MUISTOJA = 'Muistoja',
  TAAKKA = 'Taakka',
  UNI = 'Uni',
  RAKKAUS = 'Rakkaus',
  KYLMA_TULEVAISUUS = 'Kylmä_Tulevaisuus',
  NEURO = 'Neuro',
  SCHRODINGER = 'Schrodinger',
  KIPU = 'Kipu',
  POLARITY = 'Polarity',
}

Then either add furnitureSet directly to itemProperties:

[ItemName.SOFA_RAKKAUS]: {
  name: ItemName.SOFA_RAKKAUS,
  furnitureSet: FurnitureSet.RAKKAUS,
  ...
}

or create a separate mapping:

export const itemFurnitureSets: Partial<Record<ItemName, FurnitureSet>> = {
  [ItemName.SOFA_RAKKAUS]: FurnitureSet.RAKKAUS,
  [ItemName.ARMCHAIR_RAKKAUS]: FurnitureSet.RAKKAUS,
  [ItemName.BED_RAKKAUS]: FurnitureSet.RAKKAUS,
  [ItemName.SOFA_KIPU]: FurnitureSet.KIPU,
  [ItemName.TABLE_KIPU]: FurnitureSet.KIPU,
};

Recommendation: add furnitureSet to itemProperties, because that keeps item metadata in one place and scales better when new items are added.

The task logic can then stay simple:

const furniture = items.filter((item) => item.isFurniture);

if (furniture.length < 3) return false;

const sets = new Set(
  furniture.map((item) => itemProperties[item.name]?.furnitureSet),
);

return sets.size === 1 && !sets.has(undefined);

This avoids fragile parsing such as name.split('_').pop(), which would break or become ambiguous for names like Carpet_Old_Muistoja, Muistoja_Ficus, and Hologram_Kylmä_Tulevaisuus.

[BillTheBeast]

#979 I added a list of the furniture currently located on the client side onto this issue.

This avoids fragile parsing such as name.split('_').pop(), which would break or become ambiguous for names like Carpet_Old_Muistoja, Muistoja_Ficus, and Hologram_Kylmä_Tulevaisuus.

In my opinion we could just use the underscore explicitly as a divider between the set name and the furniture name inside that set and that it shouldn't be used for anything else.