At the times all scripts errors are handled using exceptions, this is not compatible with coroutines.

When playing in a non full screen window, the mouse might go outside the window and when you click you lose the focus (and your fight 😄 )

It could be great to constrain the mouse inside the window when playing. To move the window outside the window, press escape or open the chat.

Il serait utile de colorer les messages envoyés par les joueurs dans le chat en une couleur (par exemple le rouge, bien que cela soit un peu agressif pour les yeux), les faisant ressortir. Éventuellement, la taille des caractères de ces messages pourrait être augmentée.

Because of this collision, I died using the potato launcher, I died using the grapain on it and falling to the spikes, etc.

Tu le sais déjà (vu que je viens de te le dire :kappa:) mais l'ajout de LuaDoc permet vraiment d'améliorer grandement l'autocomplétion et la compréhension de certaines méthodes.

L'idée est donc d'avoir une documentation générée avec LuaDoc, les IDE / éditeurs de code sont capable de lire cette documentation et de fournir de l'autocomplétion ainsi que de la prévention aux erreurs.

Voici un exemple, j'imagine que ça fonctionne aussi avec Visual Studio ;

Use the mouse wheel to change weapon makes me lose time, so I play like a noob, it would be cool to be able to select weapon with classic shortcuts like 1, 2, 3, etc.

À investiguer

Grapple was very difficult to use in the last online test (failed to trigger 3/4 of the time)

[ERR.] [1273.523] [S] [Match local@T14823] [Entity 24] Attack callback failed: cannot resume non-suspended coroutine
stack traceback:
[C]: in field 'CreateEntity'
[string "gamemodes/base/sv_init.lua"]:41: in method 'SpawnPlayer'
[string "gamemodes/base/sv_init.lua"]:12: in function <[string "gamemodes/base/sv_init.lua"]:9>

je sais pas si c'est parce que j'utilise wine mais il me manque quelque sprite comme celui du téléporteur et de la caisse

I don't know how it works, but at first I can't pass throw the door.
Then, the emmentalibur is rendering behind the door "void" and frame

[INFO] [432.777] [C] [Match local@T7661] SirMynixVanBan has left.
[ERR.] [434.516] [C] [Match local@T7721] PlayerJoined callback failed: [string "gamemodes/deathmatch/cl_scoreboard.lua"]:7: attempt to call a nil value (method 'GetPlayerIndex')
stack traceback:
[string "gamemodes/deathmatch/cl_scoreboard.lua"]:7: in method 'RegisterScoreboardPlayer'
[string "gamemodes/base/cl_scoreboard.lua"]:23: in function <[string "gamemodes/base/cl_scoreboard.lua"]:17>

Je fais cette issue pour garder une trace de ce qui a été dit en live.

Lua pose quelques petits problèmes, au niveau de la VM, du fait qu'il n'est pas statiquement typé ou de certaines bizarreries du langage.
(Pour ma part, le fait de n'avoir aucune autocomplétion, au niveau des méthodes par exemple, ça m'ennuie)

J'ai/on (a) proposé plusieurs choses :

• https://nekovm.org/ - Langage de scripting designé pour être embarqué, facilement extensible avec C → N'est plus maintenu, remplacé par Haxe

• https://haxe.org/ - Langage de programmation, fortement typé qui compile vers un autre langage
  Les extensions de fichiers sont en .hx, le lange semble bien être pris en charge (avec VSCode ou les IDE's Jetbrains)

• https://nim-lang.org/ - Langage de programmation statiquement typé, inspiré de C++ et Rust, qui doit être compilé
  Il y a beaucoup de contributeurs et le projet semble bien évoluer, il y a d'excellent plugin pour Jetbrains & VSCode. Mais je pense que ça va être difficile à intégrer avec BurgWar

• https://wren.io/ - Langage de scripting léger, basé sur les classes

• https://github.com/dibyendumajumdar/ravi - Langage inspiré de Lua, avec un système de typage statique optionnel, compilateur JIT & AOT

J'ai l'impression que c'est assez difficile de trouver un bon langage qui correspond complètement au besoin.
Pour ma part, je pense que Ravi est un bon choix si on souhaite garder quelque chose de simple et facilement intégrable. Mon choix préféré reste Nim mais je ne sais pas s'il est bien adapté pour le use case.

L'issue est juste là pour garder une trace et servir de discussion.

It would be interesting to use Docker to compile the game more simply.

If you are interested, I can create a dockerfile that will automatically download Nazara and its dependencies and compile the game automatically.

For example with a build folder that will contain the compiled game.

What do you think?

Décrivez le bug
Quand ont lance le jeu ont obtiens cette erreur dans la console

Étapes pour reproduire le bug
1.lancer le jeu
2. aller dans la console

Comportement attendu

Screenshots

Environnement

• Système d'exploitation / Distribution : [Windows 10 2004]
• Version du jeu : [beta 0.1.1]

Informations supplémentaires
Ajoutez des informations contextuelles sur le problème ici (étiez-vous en partie solo, en multijoueur, etc.).

Those lines are preceded with # TEMP: Install nazara legacy dependencies and were added temporarily by #64.

Décrivez le bug
J'ai téléchargé les sources depuis Git et j'ai lancé la compilation avec xmake -v. Cette dernière plante lors de la compilation du moteur Nazara.

Étapes pour reproduire le bug
Les étapes pour reproduire le bug:

1. git clone https://github.com/DigitalPulseSoftware/BurgWar/
2. cd BurgWar
3. xmake -v
4. Voir erreur lors de la compilation

Comportement attendu
Une description claire du comportement que vous attendiez.

Screenshots

Environnement

• Système d'exploitation / Distribution : Archlinux 5.13.5-arch1-1
• Version du jeu : 4517ae7

Informations supplémentaires
Ajoutez des informations contextuelles sur le problème ici (étiez-vous en partie solo, en multijoueur, etc.).

• lors de la compilation du projet.

Si ce bug provoque des erreurs dans la console ou un crash, merci de poster les logs ici.
https://haste.zneix.eu/yvuviguvob

I could be cool if we can have an immunity at respawn (e.g 3 seconds) to avoid spawnkill by players or by mines.

Examples:

• Create a weapon wheel
• Allow to switch weapon with 1, 2 , 3, ..

Instead of using Debian based image for runtime version of BurgWar's server docker image, we should use alpine which is lighter.

I already tried multiple times without really succeeding while doing #64. Here are my tries:

Build image

This image is having issue with 7z build on xmake during RUN /home/burgwar/.local/bin/xmake config --mode=releasedbg -y --build_mapeditor=false.

FROM alpine:latest as build-env

# Update system
RUN apk update
RUN apk upgrade

# Install all we need ...
RUN apk add alpine-sdk curl git unzip bash

# TEMP: Install nazara legacy dependencies
RUN apk add --no-cache openal-soft-dev libsndfile freetype sdl2 xcb-util-cursor-dev xcb-util-wm-dev xcb-util-keysyms libx11 mesa-dev mesa-gl assimp

# Install xmake with root (so it will install dependencies)
RUN curl -fsSL https://xmake.io/shget.text | /bin/bash

# Add user
RUN mkdir -p /home/burgwar
RUN addgroup -S burgwar
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home /home/burgwar \
    --ingroup burgwar \
    burgwar
RUN chown -R burgwar:burgwar /home/burgwar

# That's ugly ... but we need it to install xmake :/
RUN mkdir -p /tmp/
RUN chmod -R 777 /tmp/ 

# Switch to burgwar user
USER burgwar
WORKDIR /home/burgwar

# Install xmake for burgwar user 
RUN curl -fsSL https://xmake.io/shget.text | /bin/bash

# Build server
COPY . /home/burgwar/

RUN /home/burgwar/.local/bin/xmake config --mode=releasedbg -y --build_mapeditor=false
RUN /home/burgwar/.local/bin/xmake -r BurgWarServer

# Compile every default map
RUN /home/burgwar/.local/bin/xmake -r BurgWarMapTool
RUN /home/burgwar/.local/bin/xmake run BurgWarMapTool -c /home/burgwar/maps/*

RUN /home/burgwar/.local/bin/xmake install -v -o build/ BurgWarServer

Runtime

This step (if run after a debian build) generate a segmentation fault during start. After investigations, it looks like it's recieving a command line argument (that is not existing) and making crash the image.

##############################
# Runtime image
##############################
FROM alpine:latest

LABEL org.opencontainers.image.authors="Jerome \"Lynix\" Leclercq;Axel \"Elanis\" Soupe"
EXPOSE 14768/udp
HEALTHCHECK --interval=1m --timeout=3s CMD netstat -nltpu | grep -c 14768

ENV LD_LIBRARY_PATH=/srv/lib:/lib64

# We need some gcc libs
RUN apk update
RUN apk add libgcc libc6-compat net-tools

# TEMP: Install nazara legacy dependencies
RUN apk add --no-cache openal-soft-dev libsndfile freetype sdl2 xcb-util-cursor-dev xcb-util-wm-dev xcb-util-keysyms libx11 mesa-dev mesa-gl assimp

# Add user
RUN mkdir -p /srv
RUN addgroup -S burgwar
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home /srv \
    --ingroup burgwar \
    burgwar
RUN chown -R burgwar:burgwar /srv

USER burgwar
WORKDIR /srv/

COPY --from=build-env /home/burgwar/build/ .

# Copy mods and scripts from bw repo
COPY --from=build-env /home/burgwar/mods/ mods/
COPY --from=build-env /home/burgwar/scripts/ scripts/

# Copy every default map
COPY --from=build-env /home/burgwar/bin/linux_x86_64_debug/*.bmap /srv/

# Set entrypoint
ENTRYPOINT /srv/bin/BurgWarServer

Seems like a bug in Nazara Engine

J'suis coincé, j'pense que y a un bug de hitbox quand on remonte très vite par le trou

It would be cool to allow us to cancel the connection to a server, in case when for example the server doesn't respond, or if we make a mistake about the server we connect to

It should be easy to build and publish Burgwar server Docker image using Github Actions along with current build steps.

Depuis hier, Burg'War supporte le modding, c'est-à-dire un ensemble cohérent de fonctionnalités qui viennent s'ajouter (ou non) au jeu.

Le fonctionnement actuel est le suivant :

1. Au lancement du jeu, la liste des mods est chargée en explorant le dossier de modding (par défaut mods/) et en essayant de charger le info.json de chaque mod (un dossier = un mod différent, le nom du dossier étant l'ID interne du mod), pour l'instant ce fichier info.json contient le nom, la description et l'auteur du mod.
2. Au lancement d'un serveur, un certain nombre de mods peut être activé dans un ordre particulier (actuellement tous les mods sont chargés dans un ordre indéterminé, mais ça va évoluer).
3. Lorsqu'un mod est activé, le contenu de ses dossiers assets et scripts vient se superposer au contenu des dossiers assets et scripts du jeu (via le système de fichier virtuel de Burg'War).

Cela signifie que les mods peuvent rajouter des fichiers Lua dans autorun, des entités, des modes de jeux et des armes (et à terme pourquoi pas des maps), ils peuvent également rajouter tous les assets qu'ils souhaitent.

En plus de ça, ils peuvent override des fichiers du jeu (changer un asset, un script, etc.), et par extension des fichiers d'autres mods (le dernier mod à être chargé est prioritaire).

Ça a été très simple à implémenter, et c'est un début, mais ça n'est pas optimal.

Voici une liste des problématiques dont j'aimerai parler dans ce fil de discussion :

Le support des dépendances

Actuellement les mods n'ont aucune dépendance.
Il pourrait être utile de permettre à un mod B de dépendre du mod A, afin de ne pas charger le mod B si A n'est pas présent (et logger une erreur du coup).

Quid des dépendances cycliques ? Si un gros mod est séparé en plusieurs petits mods, est-ce qu'on autorise le cas où A dépend de B et B dépend de A (pour que les deux ne chargent que si les deux sont présents).

L'override des fichiers

Chacun ayant développé des mods sur GMod se souvient de la règle "nomme tes fichiers de façon unique pour qu'ils ne se fassent pas réécrire par un autre mod", c'était vrai pour les assets, les scripts, etc.

C'est le fonctionnement actuel des mods de Burg'War, mais comme on me l'a fait remarquer on peut faire mieux que ça.

On pourrait faire en sorte que les assets et scripts de chaque mod soit propre à celui-ci, et que les fonctions interagissant avec un path fonctionnent de façon contextuelle.

Par exemple, si le mod X appelle la fonction assets.GetTexture("box.png"), le jeu va d'abord chercher dans le dossiers mods/X/assets/ le fichier box.png, et s'il ne le trouve pas va remonter jusqu'au dossier assets du jeu.
Avec une gestion des dépendances, on peut également avoir le mod Y cherchant dans son propre dossier, puis dans le dossier de chacune de ses dépendances (X) puis enfin dans le dossier du jeu.

Bien sûr du point de vue du script, cela serait totalement transparent.

Conséquences de ce fonctionnement:

1. Si deux mods indépendants proposent un asset avec un nom identique, celui-ci ne causera pas de conflit, chaque mod étant capable de retrouver son propre asset.
2. L'override d'asset/de scripts n'est plus possible, ce qui pourrait être intéressant à autoriser par la suite, en le rendant explicite par exemple (comment ?).
3. Il faut revoir la façon dont les assets et scripts sont partagés avec le client pour que ça soit possible techniquement, les caches d'assets et de scripts ne seront toutefois pas affectés (grâce au hash qui fait partie de leur nom).

Un contexte Lua par mod ?

Pour rendre les mods parfaitement indépendants, il faudrait également soit interdire la modification des états globaux de Lua (définition ou override d'une variable globale), soit faire un contexte Lua (un lua_State*) par mod.
Cette seconde approche est la plus safe, mais également la plus coûteuse en mémoire (puisque chaque fonction du jeu doit alors être enregistrée pour chaque mod).

En revanche, séparer les contextes Lua pourrait ouvrir la voie à du multithreading (chaque contexte Lua étant de base monothreadé) par la suite.

L'ordre de chargement des mods

J'avais dans l'idée de proposer une interface à la RimWorlds pour activer/désactiver/paramétrer les mods, et potentiellement changer l'ordre dans lequel ils seraient chargés.

Cela a beaucoup moins d'importance si les mods sont totalement indépendants, excepté peut-être pour l'override de fichiers.

Les permissions des mods

Un point important du modding est également de ne pas laisser les mods faire n'importe quoi. Par exemple dans l'état actuel un mod pourrait utiliser les fonctions d'I/O de Lua pour créer / supprimer des fichiers sur l'ordinateur du joueur, ce qui est évidemment une faille de sécurité dont certains pourraient profiter si le jeu se popularise.

Pour contrer cela, chaque fonction Lua exposée depuis le C++ devrait être associée à un type de permission. Par exemple "filesystem" pour accéder au système de fichier directement, "assets" pour charger des assets, etc.
Les permissions requises par un mod seraient enregistrées dans le manifeste.

Le joueur pourrait ensuite accepter ou refuser, par mod, les permissions demandées.
Ce fonctionnement serait proche de ce que les OS téléphone proposent.

Les mods client-side

Il serait bon à terme d'autoriser des mods n'ayant d'existence que côté client, ceux-ci pourraient ajouter des fonctionnalités intéressantes en terme d'affichage, de statistiques, etc.

Néanmoins, pour éviter la triche, il faudrait que le serveur puisse autoriser ou interdire la présence de mods clients (en fonction du mode de jeu par exemple).

On pourrait aussi imaginer une façon plus précise d'autoriser ou interdire les mods clients, en définissant côté serveur une liste de permissions autorisées pour les mods clients (par exemple, on pourrait interdire la permission "input" nécessaire pour toucher au système d'inputs du jeu, bloquant les auto-aim).

Cela demanderait d'avoir des permissions beaucoup plus précises (et on pourrait alors dire que certaines seraient autorisées par défaut, pour éviter d'avoir à demander au joueur la permission d'accéder à des détails techniques, et ne demander son accord explicite que pour les permissions dangereuses, type chargement de DLL, accès au système de fichier, etc.).

Décrivez le bug
Ont peux rester collé aux murs

Étapes pour reproduire le bug
Les étapes pour reproduire le bug:

1. Créer un serveur
2. aller sur les plateformes en hauteurs
3. Sauter sur un coté d'une plateforme
4. Ont reste sur le coté de la plateforme

Comportement attendu
qu'on ne s'accroche pas au coté de la plateforme

Screenshots

Environnement

• Système d'exploitation / Distribution : Windows 10 21H1
• Version du jeu : dernière

Informations supplémentaires
cela a été testé sur beta_map mais peux surement se reproduire sur toute les maps.

De plus, en esseyant de le reproduire, jai trouvé un bug de focus caméra

Est-ce que votre fonctionnalité est liée à un problème ?
/

Décrivez la solution que vous souhaiteriez
Je propose l'intégration de Discord Rich Presence qui permet d'ajouter une prévisualisation du jeu qu'on joue sur Discord. On pourrait par exemple avoir le nom du serveur, le pseudo, le mode de jeu, enfin pleins d'informations.

L'intégration est plutôt simple, il me semble que Discord propose même un SDK avec les binding pour C++.

Contexte additionnel

Décrivez le bug
Il est impossible d'utiliser le grappin lorsque nous sommes en dessous d'un soin. Le burger joue pourtant l'animation du grappin et semble s'attacher, mais il ne le fait pas.

Étapes pour reproduire le bug
Les étapes pour reproduire le bug :

1. Allez en dessous d'un soin
2. Utilisez le grappin

Comportement attendu
Le soin ne doit pas posséder de physique, le grappin devrait passer à travers.

Screenshots

Environnement

• Système d'exploitation / Distribution : Windows 10 2004
• Version du jeu : Beta RC 3

Informations supplémentaires
Ajoutez des informations contextuelles sur le problème ici (étiez-vous en partie solo, en multijoueur, etc.).

Si ce bug provoque des erreurs dans la console ou un crash, merci de poster les logs ici.

When we write a message, we can't cancel it, we must delete all and then press enter.
It is really annoying when someone comes beat us, we're really vulnerable if we want not to send the message.

After a throw from the physics bun.