rail_power/rail_break fonctionnent mal ?

[Coethium]

Bonjour,

il semblerait (conditionnel) que le rail_power ne remplisse pas son rôle d'accélérateur ; voire même qu'il ralentisse le cart par rapport à un rail normal. J'ai mis en place une démo de ce que je constate sur le serveur MFF Classic en 86,1,-355. Avec la power_plant, le cart sur rail_power va plus lentement que celui sur rail normal. Sans power_plant, ils vont à la même vitesse.

Pour le rail_break, dans tous les cas il freine le cart, mais connecté à une power_plant il freine moins bien que sans.

Est-ce une mécompréhension de ma part dans le fonctionnement de ce type de rail ou bien est-ce bel et bien un défaut ?

Bonne journé à tous !

[BetterToAutomateTheWorld]

De mémoire, tu n’as pas besoin des power plants dans notre version de carts pour que les powerrails soient activés, la powerplant les désactive peut etre même, à checker.

Dans leurs fonctionneemnt normal, les rail_brake n'ont pas besoins d'être conenctés à une power plante.

Ce sont certainement des défauts, il nous faut les vérifier et corriger si validé :)

[Coethium]

En regardant de plus près le code je comprends mieux : 1/ les default:rail et carts:rail_power ont les mêmes paramètres, c'est pourquoi je ne voyais pas de différences de comportement : ils engendrent tous deux une accélération par défaut. 2/ effectivement le comportement des mesecons est inversé dans le code : les rails accélèrent sans signal, et n'accélèrent pas avec signal (du coup ça décélère car les frottements sont gérés).

Est-ce le comportement attendu des rails sur MFF ? Dans le cas contraire je veux bien essayer d'apporter des modifs, il suffit de se mettre d'accord sur les souhaits :)

[BetterToAutomateTheWorld]

C'est en effet le comportement attendu.

Néanmoins, et si tu le souhaites, tu peux faire une PR pour augmenter la vitesse pour les carts:rail_power par rapport aux default:rail, il semblerait en effet plus logique que la vitesse avec les carts:rail_power soit plus élevé qu'avec les default:rail (+25% ou +33% me semble bien)

[Coethium]

Je ne connais pas encore bien Git et ne voudrait pas faire de fausse manip, je joins ci-après un patch (vite fait) qui permet 33% de vitesse en plus sur les carts:rail_power.

--- "init (copie).lua"  2016-07-21 11:54:32.195066000 +0200
+++ init.lua    2016-07-21 21:54:43.963118822 +0200
@@ -13,6 +13,8 @@
    old_velocity = nil,
    pre_stop_dir = nil,
    MAX_V = 9.6, -- Limit of the velocity (speed).
+   MAX_V_SILVER = 9.6,
+   MAX_V_POWERED = 12.8,
    TARGET_TOUR_V = 6, -- Target touring velocity, currently unused.
    railcount = 0,
    ignorekeypos = nil,
@@ -415,6 +417,15 @@
   if not a then
       a = 0
   end
+   if a == 1 and self.MAX_V < self.MAX_V_POWERED then --higher limit on powered rail
+       self.MAX_V = self.MAX_V+0.2
+   end
+   if a == -0.2 and self.MAX_V > self.MAX_V_SILVER then
+       self.MAX_V = self.MAX_V-0.4
+   end
+
   local t = tonumber(minetest.get_meta(pos):get_string("cart_touring_velocity"))
   if not t then t=0 end
   if t>0 then
@@ -716,14 +727,14 @@
    groups = {bendy = 2, snappy = 1, dig_immediate = 2, rail = 1, connect_to_raillike = 1},

    after_place_node = function(pos, placer, itemstack)
-       minetest.get_meta(pos):set_string("cart_acceleration", "0.5")
+       minetest.get_meta(pos):set_string("cart_acceleration", "1")
        minetest.get_meta(pos):set_string("cart_touring_velocity", cart:get_staticdata().velocity)
    end,

    mesecons = {
        effector = {
            action_off = function(pos, node)
-               minetest.get_meta(pos):set_string("cart_acceleration", "0.5")
+               minetest.get_meta(pos):set_string("cart_acceleration", "1")
            end,

            action_on = function(pos, node)

`

[Coethium]

Re ;) On pourrait même mettre en place le comportement suivant : default:rail/carts:rail_copper : pas d'accélération, maintient de la vitesse acquise (par rail_power, push, ...), pas de frottements , pas de gravité (ie. ne ralentit pas en montée, n'accélère pas en descente) -- actuellement ce rail provoque une accélération jusqu'à une limite, ce qui implicitement annule déjà les comportements de variation de vitesse. carts:rail_power: accélération (cas actuel) carts:rail_break: decéleration (cas actuel) Suppression complète de la gestion par les mesescons (puisque vous l'aviez déjà plus ou moins ignoré)

[Lymkwi]

@Coethium Si tu arrives à implémenter ça avant que je ne le fasse, je prendrai ton implémentation. L'idée semble bien. La décélération progressive, bien que réaliste, n'est pas si gênante à enlever. Par contre la décélération en montée et l'accélération en descente me semble assez important à garder (juste une opinion). Je vais tenter d'implémenter cela, mais je n'ai jamais bidouillé carts.

[Coethium]

Je peux sans soucis me charger d'implémenter cela dans le courant de la semaine !

[Coethium]

En bossant dessus j'ai constaté qu'une bonne partie du code pourrait être amélioré (optimisé + nettoyé). Le principal concerne l'accelération justement : elle est gérée manuellement dans le code lua (par modification de la vélocité), alors qu'il existe une méthode objet dédiée à la gestion de l'accelération. (Peut être n'existait-elle pas lors du développement du carts d'origine).

[Coethium]

Dans la journée @Cyberpangolin m'a informé qu'un ancien bug est réapparu : quand la vitesse du cart est trop élevée en montée ou descente on peut se retrouver encastré dans le mur en face (aïeuuu). Dans ma branche locale j'ai complètement remplacé carts par boost_carts : non pas en tant que surcouche à carts, mais en effectuant des modifs de remplacement complet.

Indirectement le bug décrit semble corrigé car cette implémentation m'a l'air d'ignorer les collisions : on passe à travers, et on continue. De même deux carts passent au travers l'un de l'autre.

Est-ce que ça peut convenir comme comportement ?

[BetterToAutomateTheWorld]

Dure question, elle nécessite une petite discussion IRC/ici je pense, avec tout le monde : @crabman77 @LeMagnesium @Coethium @Cyberpangolin si possible :)

[ghost]

Il y a aussi des rails dans maptools, il faut aussi les modifier dans ce cas, mais bon si on remplace il faut bien le tester avant (sur chlorine) pour la latence et voir si il n'y a pas aussi le même ou d'autres bug.

[ghost]

Salut,

ça vaudrait le coup d'essayer ce comportement que tu décris @Coethium , c'est un paramètre présent ici: https://github.com/MinetestForFun/server-minetestforfun/blob/master/mods/carts/init.lua#L5

peut-être que ça éviterait de rester coincé dans les murs ou en l'air quand ça descend trop vite. A voir…

[Coethium]

@Darcidride je suis assez facilement dispo les après-midi/soirs donc pas de soucis pour un rdv irc. @crabman77 les rails de carts et boost_carts tel que modifié sont les mêmes, donc il ne devrait pas y avoir de soucis pour les mods qui utilisent les rails. Le changement concerne surtout l'implémentation des calculs on_step() : code plus propre (selon moi) et charge moins le serveur (utilisation des primitives du moteur de jeu). En effet il faut tester, en local ça passe même à très grande vitesse, mais forcément y'a pas les latences dues à une connexion distante. @AcidNinjaFWHR bien vu ! En effet dans boost_carts ce paramètre est à false.

[BetterToAutomateTheWorld]

@crabman77 Les rails de maptools ont été supprimé/aliasés il y a bien longtemps, il ne reste que les rails de carts (et boost_carts) maintenant.

@Coethium @AcidNinjaFWHR Je suis personnellement pour la modification de "passer à travers" si ça peut éviter les soucis de carts et enfin rendre ce mod utilisable sans soucis utilisateurs

[ghost]

@Darcidride Non il y a des unbreakable, 3 rails avec des définitions basées sur "carts".

tiles = {"carts_rail_pwr.png", "carts_rail_curved_pwr.png", "carts_rail_t_junction_pwr.png", "carts_rail_crossing_pwr.png"}, inventory_image = "carts_rail_pwr.png"

https://github.com/MinetestForFun/server-minetestforfun/blob/master/mods/maptools/default_nodes.lua#L494

[Coethium]

@crabman77 Effectivement il va falloir en tenir compte, rien de bien compliqué à première vue.

[BetterToAutomateTheWorld]

Je clos puisque le patch est mergé