AC - Rally timing framework

First Official Post

    Salut à tous

    Aujourd'hui pour faire du rallye en AC on a plein de pistes et voitures formidables, mais il y a 1 élément essentiel qui manque: la compétition.

    La seule possibilité de vraiment se mesurer en spéciale c'est sur des serveurs qui sont toujours temporaires.

    J'ai donc entrepris de combler cette lancune... mais comme je suis nulle en programmation moi-même, je cherche des gens ayant la même passion et les compétences nécessaires.

    J'envisage 3 phases de développement:

    1. Système de timing personnel optimisé pour le rallye

    2. Classements en ligne pour des pistes et voitures supportées, avec assez de mesures anti-triche, des replay et temps differentiels

    3. Organisation des rallyes à plusieurs étappes, avec des temps et conditions météo variables

    L'idée originale c'était de faire une version 2.0 du "codriver mod". Patrick Brunner a pris sa retraite, il veut bien mettre son code disponible et donner d'avis - mais vue la complexité du logiciel il sera plus simple de supprimer la partie timing du codriver mod, et de travailler "en tandem".

    Un peu plus de détail sur la première phase, les éléments qui sont déjà prêts (ou en test):

    - procédure de depart exigeant l'arrêt dans le mètre avant la ligne de départ

    - option de remise de voiture sur la piste en cas de sortie (avec temps de pénalité)

    - sauvegarde du meilleur temps par piste+voiture. Option de rouler contre meilleur temps differentiel par voiture à choix

    Reste à faire en première phase:

    - sauvegarde de replay des meilleur temps + données télémétriques

    - détection de coupures; temps de pénalité si 4 roues hors de la piste sauf en cas de sortie de route (=perte de temps/vitesse)

    - optionnel: visualisation graphique (au lieu de numérique) du temps gagné/perdu par rapport au meilleur temps cfr Deltabar

    - optionnel: barre de progression avec un nombre de splits réglable. Sections verts/rouges cfr DR2.0.

    Si vous êtes intéressé d'aider dans ce projet en large ou petite mesure, ou si vous connaissez quelqu'un > contactez-moi!

    meilleures salutations

    Salut wimdes !

    Excellente idée! Un peu ras le bol de tourner en rond sur Dirt2.0...

    Perso je suis incapable de faire ce que tu demandes... Par contre, JCRR a balancé l'idée de faire des skins liés à ses spéciales, et la je peux peut être mettre ma pierre à l'édifice.

    Peut être serait il possible d'associer toutes ces idées? Même si le plus important pour l'instant est de mettre les bases en place.

    803.png

    Chacun sa route, chacun son chemin, passe le virage au frein à main.

    MES SCREENSHOTS

    Hello

    Bravo! Excellente initiative!!!! Si j'ai bien compris...oui c'est bien de permettre une petite sortie qui permet de revenir sur la route tout seul... si c'est possible.... Et bien sûr de pénaliser des "coupes volontaires"...

    Trés bonne initiative effectivement..! :++:

    Wiki très informatif... merci.. :+++:

    Me mettre au rallye dans Assetto me trotine depuis quelques temps... il faut que je le prenne ... le temps..!! :hihihi:

    Windows 11 , I7 13700k , RTX 4080 Super , DDR5 32go

    Moza R21 V2 + GS V2, TH8A, BJ Steel GT, Cockpit en Profilé Alu.

    • Official Post

    Si tu trouves quelqu'un qui a déjà développé un mod AC, ça te fera gagner du temps. :)

    J'ai réfléchi un peu à ton projet et regardé des trucs par curiosité, quelques documentations de base pour le dev :

    - Tuto de base pour créer un mod AC en Python

    - Documentation Python AC (une autre plus complète)

    - Documentation AC Shared Memory (version PDF peut-être plus complète)

    wimdes a écrit :

    L'idée originale c'était de faire une version 2.0 du "codriver mod". Patrick Brunner a pris sa retraite, il veut bien mettre son code disponible et donner d'avis - mais vue la complexité du logiciel il sera plus simple de supprimer la partie timing du codriver mod, et de travailler "en tandem".

    Tu veux dire quoi par "en tandem" ? Avoir 2 plugins, CoDriver + un nouveau ?

    Si l'auteur de CoDriver est OK, je te suggère plutôt de faire un seul plugin sur la base de CoDriver. Genre au départ de la spéciale CoDriver a un décompte, il ne sera pas possible de mettre aussi un décompte dans ton plugin, ça ferait conflit, donc autant n'utiliser que CoDriver non ?

    A noter qu'il faudra que le plugin puisse marcher même si ya pas de notes sur la spéciale, je sais pas si c'est le cas de CoDriver actuellement mais c'est un détail.

    Ya du boulot en tous cas, et comme je te disais dans l'autre topic, c'est la partie anti-triche qui me paraît la plus problématique. D'ailleurs tu veux faire quoi des données télémétriques ?

    wimdes a écrit :

    sauvegarde de replay des meilleur temps + données télémétriques

    L'idée originale c'était effectivement de créer une nouvelle version Codriver pour n'avoir que 1 plugin (Patrick Brunner était d'accord)

    Mais l'architecture est ainsi que casi tout est fait dans la module en C# qui retransmet tout vers la partie Python.

    Il faudrait un développer vraiment expert pour être capable de travailler dessus.

    Le décompte du codriver là on n'a pas encore de solution facile effectivement.

    Les données télémétriques, s'il y aurait des soupçons sur un temps, ce serait autre moyen de vérification (avec le replay)

    Chaque transmission cryptée...

    • Official Post

    S'il a tout fait en C# il a peut-être utilisé cette bibliothèque que j'ai vu pendant mes recherches.

    Le C# n'est pas un langage complexe, si on connaît déjà un langage orienté objet comme Python il suffit de s'adapter à la syntaxe. J'ai déjà fait un projet en C# sans rien y connaître, donc faut pas que ce soit disqualifiant.

    wimdes a écrit :

    Les données télémétriques, s'il y aurait des soupçons sur un temps, ce serait autre moyen de vérification (avec le replay)

    Oui faut encore trouver quoi en faire. :D Coder des algos qui vont faire un minimum de vérifications avec le replay et les données télémétriques, c'est un sacré truc... ^^

    wimdes a écrit :

    Chaque transmission cryptée...

    Pas sûr que ce soit une sécurité en soit.

    D.Laurent a écrit :

    Le C# n'est pas un langage complexe, si on connaît déjà un langage orienté objet comme Python il suffit de s'adapter à la syntaxe. J'ai déjà fait un projet en C# sans rien y connaître, donc faut pas que ce soit disqualifiant.

    La partie C# de CoDriver compte environ 10 000 lignes d'après Patrick. Si on trouverait quelqu'un de son calibre, tant mieux, mais je n'ose pas y compter...

    D.Laurent a écrit :

    Oui faut encore trouver quoi en faire. :D Coder des algos qui vont faire un minimum de vérifications avec le replay et les données télémétriques, c'est un sacré truc... ^^

    Je n'essayerais pas d'analyser automatiquement... sauf si peut-être si on trouverait un nouveau Patrick :D Je pensais simplement sauvegarder ces données en ligne (comme replay et temps différentiels). Ce serait cool pouvoir regarder les replay des autres, et disons prévoir une forme de contrôle social.

    L'encryption, question d'empêcher quiconque de s'introduire dans la communication entre le client et le serveur?

    Mais on est encore loin de là... d'abord il faudra mettre au point le timing personnel/locale

    • Official Post

    Je regarde un peu la documentation de Co-driver et je découvre qu'il y a déjà un système d'upload de chronos avec classement : http://patrick-brunner.net/codriver/besttime.php

    D'ailleurs on retrouve le chrono de Franconen sur la dernière spéciale de JCRR. :)

    La page est un peu rudimentaire et mériterait des options de filtre/recherche, mais sinon Co-driver a l'air de déjà faire le job non ?

    J'en ai discuté avec Patrick, là aussi il estimait que vue la complexité du logiciel et les grosses modifications nécessaires ce serait plus simple de séparer le chronometrage et la fonction copilote. D'ailleurs on peut démarrer le décompte copilote depuis un autre app (communication UDP avec la module .exe/C#)

    Ca reste un option de continuer sur CoDriver (ce qui pourrait se faire sur la partie Python, sans toucher la partie C#) - mails il faut des bénévoles avec les compétences adéquates

    Moi je n'y connais rien dans tout ce que vous faites et comment vous le faites, mais je suis admiratif.

    Alors voici mon petit message de soutien.

    En espérant vous croisez bientôt sur une spéciale AC. 👍

    Bravo les gars !

    880.png

    • Official Post
    wimdes a écrit :

    J'en ai discuté avec Patrick, là aussi il estimait que vue la complexité du logiciel et les grosses modifications nécessaires ce serait plus simple de séparer le chronometrage et la fonction copilote. D'ailleurs on peut démarrer le décompte copilote depuis un autre app (communication UDP avec la module .exe/C#)

    Quelles grosses modifications ?

    Le chronométrage étant déjà codé dans CoDriver, je me demande pourquoi réinventer la roue.

    Il faut aujouter des fonctionnalités comme détection de ligne de départ, ajouter une procédure depuis l'arret au ligne (maintanant on peut se lancer à 150km/h), verification de coupures, chronometrage différentiel,...

    Patrick veut bien mettre sa code à disposition mais après pas mal de délibérations il recommande de travailler à côté.

    Vous savez que vous êtes le bienvenu si vous voulez relever le défi!

    • Official Post

    Comme déjà dit j'ai pas le temps de me mettre sur un autre projet, mais je veux bien participer aux discussions. :)

    Perso j'aurais recommandé de modifier CoDriver car l'essentiel y est déjà codé, ça ferait gagner du temps de développement, et vu que c'est en C#, qui est bien plus performant que Python, je serais resté sur ce langage.

    • Official Post
    wimdes a écrit :

    Un peu plus de détail sur la première phase, les éléments qui sont déjà prêts (ou en test):

    - procédure de depart exigeant l'arrêt dans le mètre avant la ligne de départ

    Tu as réussi à gérer ça ?

    Hier j'ai regardé plus en détail l'API de AC, et je ne vois pas comment tu peux récupérer les coordonnées de la ligne de départ.

    Je continue ici :hihihi:

    Je ne vois pas comment faire un timing fiable s'il est dépendent du point où on à démarré le recording?

    Le plus beau serait si le recording des notes enregistrait les positions départ/finish au même XML, mais pour l'instant on n'a personne capable de le réaliser.

    JCRR les coördinées XYZ en AC, tu sais s'ils ont une échelle fixe? Est-ce en mètres?