En gros ça serait cool une nouvelle commande qui définit l'ordre de priorité de supperposition des mobis du style :overlay <nombre> allant de 1 à 10 et 1 étant au dessus de tout. Parce que c'est trop frustrant de build et de devoir changer de mobis juste parce que c'est une victime qui passe en dessous de tout les mobis. (Et le setz n'est pas une solution en soit parce que ça crée littéralement des apparts ou une case sur 2 on peut pas marcher/flotte) Un exemple plus parlant sur la photo de ce pourquoi je crée le post
C'est surtout que le mobis sol n'est pas censé passer au-dessus, il faut reporter lorsque c'est le cas sur CityCom dans bug-catalogue-enable
@Alocasia Peut être que ce cas de figure est un bug mais si je veux poser le tapis au dessus d'un autre sol par exemple c'est compliqué.
dans un monde où tous les mobis sol ont le même index z il suffirait de :setz 0.01 le mobi que tu souhaites voir par dessus
@Tetra la réalité est différente parce que parfois ça marche qu'au bout du setz 0.5 avant que le mobis se décide de dire "ah mais oui je suis au dessus on doit me voir". et c'est juste moche, la commande reste utile non seulement pour les sols mais aussi pour des idées de builds ou on fait des gros assemblages
ma phrase est au conditionnel, je trouve ça ridicule d'ajouter une feature pour patcher le défaut d'une autre plutôt que de patcher ce défaut justement ( ne le prend pas pour une critique ), mais quelque soit l'option choisie le travail requis pour accomplir l'une ou l'autre de ces deux tâches est conséquent et tu n'as quasiment aucune chance de voir une solution un jour
edit : au delà de "pacher le pb" zerty m'a fait remarquer qu'il y a tout de même des applications sympa à cette commande
@Tetra au contraire c'est superfacile à faire je pense une amie à moi l'a fait avec des bg, et de plus, ce nouvel ajout permettra non seulement de corriger un bug mais en plus de prioriser des objets qui ont un setz en dessous des autres mais que tu veux quand même voir au dessus.
on vient un peu d'en parler avec zerty et si l'ensemble des mobis étaient considérés comme des backgrounds on perdrait l'animation des mobis animés ou ceux à plusieurs états et un background pourrait potentiellement lag plus qu'un mobi, si les backgrounds sont à privilégier c'est parce qu'ils peuvent représenter des milliers de mobis en même temps mais pour 1 mobi = 1 background ça risquerait de poser problème
@Tetra et ducoup ça signifie que l'ordre de priorité des backgrounds ne marche pas de la même manière que les mobis ?
Coucou !
De mon côté je trouve l'idée super sympa, après je n'ai pas les connaissances nécessaires quant à la possibilité de sa réalisation.
En revanche je vais regarder le sol en question afin de le régler, si tu pouvais me donner la catégorie dans laquelle il se trouve ça serait top !
J'en profite pour rebondir sur le commentaire de @Alocasia , si vous (ou quelconque joueur) rencontrez un soucis ou remarquez un bug lié à un mobilier, n'hésitez pas à le report.
Pour ce faire : LE SERVEUR DISCORD DE HABBOCITY ⇒ 🔧・bug-catalogue-enable
(détaillez le soucis au maximum, si possible accompagné de screens ainsi que du nom de la catégorie dans laquelle se trouve le mobilier!)
Merci 😊
C'est très chiant
j'ai rien compris mais j'approuve
@Rayan non les bkg se règlent avec des unité en x (verticalement) y (horizontalement) et z (en terme de plan) de mémoire et tu dois régler au pixel prêt, le minimum étant en général vers les 9999 pour que le bkg passe par dessus le sol de l'appartement, donc ça serait définitivement pas possible mdr
Ce sujet est actuellement fermé