La messagerie interstellaire. Fallait y penser !

— Permalink

Une application Python QT pour gérer sa fabrique à histoires (fah) Lunii et Flam, avec les opérations de organisation / importation / exportation / téléchargement du firmware
pour Windows / Linux / MacOs 11
(compatible avec les archives STUdio, avec support de la conversion audio)

instruction tuto en français:
https://github.com/marian-m12l/studio/blob/master/README_fr.md

le but de ce topic est de centraliser nos questions sur le super outil "STUdio" (Story Teller Unleashed") développé par Marian (un grand merci à lui !)

Son outil est disponible à cette adresse : github.com/marian-m12l/studio

Grâce à cet outil, il est possible de créer sa propre histoire sur son Lunii et également de faire une copie de sauvegarde de ses histoires pour les réimporter par la suite.
En quelques clics, vous pouvez également éditez vos propres créations !

Vous aurez alors le choix entre créer des personnages/objets/lieux mais également des histoires à composer (avec des choix à prendre pendant l'histoire).

But : avoir un raspberry pi qui affiche, au démarrage, firefox en plein écran et rien de plus. C'est pour une TV d'information / monitoring.
Pour ça, j'utilise la version «no desktop» de «Raspberry Pi OS» avec un auto login.

sudo apt-get install xorg firefox
echo '#!/bin/sh
xrandr -s 1920x1080
exec firefox -height 1080 -width 1920 --window-size 1920,1080 --kiosk file:///home/pi/index.html
' > ~/.xinitrc
# là, ça devient crade mais ça «marche»
echo 'if [[ -z "$DISPLAY" && $(tty) == /dev/tty1 && "$(pgrep firefox)" == "" ]]; then startx -- -nocursor; fi' >> ~/.profile

Pour éteindre ou allumer la TV :

DISPLAY=:0.0 xrandr --listmonitors
DISPLAY=:0.0 xrandr --output HDMI-1 --off
DISPLAY=:0.0 xrandr --output HDMI-1 --auto

— Permalink

Reste plus qu'a diviser par 2 le RSA au personne n'ayant pas travaillé depuis plus de 12 mois et tout ce petit monde sera bien obligé de reprendre le chemin du travail.
vid{1cd38859c34a298b2caba3b1d08320ebb3fdb6cc16eef693006b02fa688fd9e4}
— Permalink

vid{1cd38859c34a298b2caba3b1d08320ebb3fdb6cc16eef693006b02fa688fd9e4}
— Permalink

Science Advances
20 Sep 2019
Vol 5, Issue 9

DOI: 10.1126/sciadv.aaw9832

La méthode scientifique repose sur des faits, établis par des mesures répétées et reconnus universellement, indépendamment de la personne qui les a observés.

En mécanique quantique, l'objectivité des observations n'est pas aussi évidente, comme en témoigne l'expérience de pensée éponyme de Wigner, où deux observateurs peuvent vivre des réalités apparemment différentes. La question de savoir si les récits des observateurs peuvent être réconciliés n'a été rendue accessible à l'investigation empirique que récemment, grâce à des théorèmes de non-retour qui construisent un scénario élargi de l'ami de Wigner avec quatre observateurs.

Dans une expérience de pointe à six photons, nous réalisons ce scénario de l'ami de Wigner étendu, violant expérimentalement l'inégalité de type Bell associée par cinq écarts-types. Si l'on s'en tient aux hypothèses de localité et de libre choix, ce résultat implique que la théorie quantique doit être interprétée en fonction de l'observateur.

https://doi.org/10.1126/sciadv.aaw9832

Résumé de la vidéo sur les secrets techniques du multijoueur en jeu vidéo

1. La prouesse technique du multijoueur

• Les jeux vidéo multijoueurs, bien qu’ils paraissent aujourd’hui ordinaires, sont une véritable prouesse technique à cause de la difficulté majeure : la latence.
• Faire cohabiter plusieurs joueurs dans une même partie nécessite des astuces et contournements côté développement afin de minimiser la perception des problèmes.

2. De l’hébergement local aux serveurs dédiés

• À l’origine, les jeux utilisaient le système de “host” : un joueur hébergeait la partie sur son ordinateur, et tous les autres s’y connectaient (comme Minecraft ou les LAN parties d’avant).
• Ce système posait des problèmes d’équité et de triche : l’hôte avait zéro latence et pouvait modifier son jeu ; si l’hôte quittait, la partie s’arrêtait.
• Les studios ont donc basculé vers les serveurs dédiés : un serveur officiel gère la logique du jeu, garantissant que tous les calculs essentiels (dégâts, déplacement, etc.) sont faits côté serveur et non côté joueurs, limitant la triche.

3. Latence : un problème insoluble ou presque

• Malgré les serveurs, la latence reste présente et affecte le ressenti : un tir réussi côté joueur peut ne pas l’être côté serveur si la cible s’est déplacée entre-temps, entraînant “l’oreg” (absence de reconnaissance de tir).
• Les jeux doivent choisir qui avantager : souvent, pour minimiser la frustration, ils privilégient le tireur plutôt que la cible, sauf dans certains contextes (ex. zone d’effet où on protège la victime).

4. Astuces pour masquer la latence

• Les développeurs utilisent des techniques comme :
  • Rembobiner le temps côté serveur lors d’une action, pour simuler la vision du joueur au moment réel où il a déclenché l’action.
  • Simulation côté client : le jeu accepte immédiatement l’action du joueur (ex : lancer un sort), puis le serveur vérifie et, si nécessaire, annule a posteriori l’action (ce qui peut entraîner des corrections visuelles et de gameplay).
• Ce sont des “tricheries” volontaires pour rendre l’expérience fluide : annulation douce des incohérences, ajustements des positions, etc.

5. Les limites et la gestion de la triche

• La distinction entre triche et problème réseau est parfois floue, nécessitant des analyses statistiques pour détecter des comportements abusifs.
• Les cheats type “wall hack” (voir à travers les murs) sont parfois techniquement impossibles à éradiquer sans dégrader l’expérience des joueurs à cause de la latence (affichage instantané des ennemis visibles).

6. Exemples de cas complexes

• Les jeux comme Overwatch construisent leur propre moteur réseau et doivent gérer des situations complexes où le temps, la position et les interactions varient d’un joueur à l’autre.
• Chaque type d’interaction (tir, déplacement, zone d’effet) nécessite une adaptation spécifique du code réseau, ce qui explique la charge de travail immense pour rendre un jeu multijoueur compétitif.

7. Pourquoi les petits studios ne font pas de gros jeux multi compétitifs

• Le “netcode” (la gestion du réseau) représente environ 40 % du travail total pour un jeu multijoueur compétitif : beaucoup d’aspects sont à coder à la main, contrairement à des jeux plus simples où des briques toute faites suffisent.
• Cela explique pourquoi il faut de grandes équipes sur plusieurs années, contrairement à Minecraft développé seul.

8. Message additionnel

• La vidéo contient aussi une annonce pour rechercher un monteur vidéo pour la chaîne.

En synthèse :
Le multijoueur est un domaine d’astuces techniques sophistiquées, requérant des arbitrages constants entre expérience utilisateur et justice compétitive, avec une part importante du développement dédiée à masquer la latence et à limiter la triche. Les grandes équipes derrière les gros jeux sont nécessaires à cause de cette complexité invisible pour le joueur.

vid{1cd38859c34a298b2caba3b1d08320ebb3fdb6cc16eef693006b02fa688fd9e4}
— Permalink