Xonotic Forums - Xonotic - Development

Update to Autobuild seems to stuck?

Aguaumreal — Tue, 12 Nov 2024 12:14:50 +0000

I currently try to update my game however wenn running the script it is stuck at:

"targetting the normal autobuild version"

Any clue what's the problem? I'm using Arch, and it used to work before.

**Edit**
NVM i just waited and finally it started updating. Though it took super long till finally something happend.

How can I analyze demo file or CLIENT TO SERVER packets?

vighill9 — Thu, 20 Jun 2024 02:48:07 +0000

Sorry, apologies in advance. I'm newbie for inspecting Xonotic codes (quakeC, darkplaces) and I'm struggling with code analysis because I want to make detection tools like aim hacks and suspicious user perfermances. it will be very absurd question but can I make the demo files to csvfiles that can be easily statistically analyzed? I have seen the perl script to cut or edit demofiles in xonotic open source, but it only works for those purpose. I made a script based on the script but saw the only part of the readable data and failed to make csv file. And in other options, I also found that there is a "stooge bot" for packet hijacking(?) proxy server.

But, I might be wrong, because analying the client to server packets and demo files is obsolete for detecting aim hacks and it's really complicate in the sense that a lot of variants like dedicated server sending back clients data after applying physics.

In my search, triggered by command the clients recording data is allowed to sent to server. And filtering the packets and writing the data to demo files. The recorded demo files can be read at playback process in client. And the demo files parsed into client readable message. I think I will get clues more for the parsing functions.

It's really tough things to read C codes and QuakeC codes but interesting and if I understood the whole structures about data transfering processs through the all paths between client and server, between server and server progs.dat, I would acheive my goal. Before I die to time pass to do that, I want some tricks or opinions about the question from this forum users of full experiences in this game development.

0.8.6 and git - Stutter points / Profiling / Code Optimization

dagelf — Sat, 08 Jun 2024 16:32:03 +0000

Hi All

Has anyone built ops around benchmarking the darkplaces or Xonotic codebase?

I stumbled on Optimizing my game so it runs on a potato where a Godot game dev details things he did to get his fps up from 15 to over 100 fps...

Was thinking that I should just plain profile the code, and maybe take a bash at it, maybe one of those tips (like randomizing the times at which bots do their path calculation - if its not done already) - maybe there's still some scope for improvement?

Does anyone have any tips / are there any existing profiling scripts or documentation, specifically aimed at programming?

I noticed that darkplaces has a "make profile" option, but that's as much as I could find, without diving into doing it myself... (nothing on any related issue trackers)

(I'm not talking compilation flags like here https://forums.xonotic.org/showthread.php?tid=3178)

Hello guys! I need Xonotic Debian repository, not snap

SerW — Thu, 02 Nov 2023 18:02:41 +0000

And not Flathub.
Could you, devs, please add a repository for Xonotic? :-))

I (sort of) converted the QC bytecode to native exec, but unfort w/o perf improv

oblector — Fri, 20 Oct 2023 23:12:51 +0000

The game code is implemented in QuakeC (not the same language as C, which is used to implement the Darkplaces engine), and clients interpret a "bytecode" derived from it, so that players are able to play modified versions chosen by server owners, without having the install a separate Xonotic for each server.

However, servers only run a fixed QuakeC source chosen by its owner (because clients can't send code, only receive it).

So I was wondering how much the server performance is impacted by Server QuakeC, and if it was possible to recompile it to a native executable or at least to use a just-in-time compiler.

Initially I tried to do some analysis of which entity fields may be present in which entities, hoping to save memory. However because of many `find` operations, which may return a priori arbitrary entities, doing such analysis would be complex and demand many manual annotations, which would be exhausting to do to the large source code of Xonotic.

So I decided to simply try to change the `prvm_executeprogram.h` part (which interprets the bytecode) into something that transpiles to C. Well, not simply.

Because in the QcVM bytecode every variable is global, and stores some number (which may be, for instance, a float or a function index). It is not a register machine or a stack machine. So I tried the following:

* RETURN and PARMn globals are always converted to C locals (hopefully stored in registers);
* the "locals" of QuakeC are converted to C locals, except in a few functions, that instead store them in globals so that they "leak" to certain other functions (mostly secret functions created by GMQCC to implement variadic functions);
* if a global is never modified by the QcVM code, then it's inlined IF it is not an engine global nor an autocvar;
* similarly, dynamic function calls are replaced by static calls if possible (Only now I noticed only that I forgot to check if the function index is not stored in a engine global...; I'll fix it later. EDIT: fixed it in `maybeConstCalledFun`, generated code is identical);
* each non-builtin function is compiled to a C function "W f«n»(prvm_prog_t *prog, U i0, ..., U i«s-1»)", where s is a number between 0 and 24, and where W stores vector+error; a dynamic call needs a bitmap to know which QcVM arguments are floats and which are vectors, so that they are correctly written to the C arguments;
* most builtins call the engine, but some (like max, min) are inlined;
* field access is unmodified;
* some information like number of entities (used in bounds checking) may change after calling builtins, so it needs to be re-accessed regularly, but the C code marks the operation that access such information as "pure", so GCC will coalesce consecutive calls that aren't interrupted by builtins.

You may find the transpiler QcNat.hs here: https://gitlab.com/-/snippets/3613556 + some cludgy Darkplaces patch that does not respect the formatting guidelines. The QcNat.hs is very slow (specially the const global detection), and the resulting C code is very loong.

I tried it, the game sort of worked (maybe I forgot to mark some global as mutable), however the performance was the same. (EDIT: found it, variadic functions access the PARMn's without defining them, how i missed that? need to adjust the transpiler.)

What do you think? Maybe the QcVM interpreter is not a bottleneck? Or my fault?

Thank you, developers!

Xonotic Roadmap

cushinga — Sat, 18 Mar 2023 23:18:34 +0000

Alr, I've decided the contents of this post were dumb, but I do think the devs do need some sort of more transparent roadmap of future plans instead of just a milestones list on GitLab.
That is all.
Thank you,

Xonotic 0.8.5/DarkPlaces "Issues"

Baker — Fri, 24 Feb 2023 07:55:07 +0000

This will be an ongoing thread related to engine code in Xonotic/DarkPlaces.

(I don't see a issue report ability on the github for Xonotic. I engine code a lot and will be maintaining a modified DarkPlaces for the foreseabe future. If there is a number like "1008", I used that as personal tracking # in the code. I wish to thank the Xonotic team for their years of advancement and hardening of DarkPlaces

x. darkplaces-wgl.vcproj has 2 errors upon compile on 0.8.5 (prior version did not).

vid_shared.c The fix is simply 1.0 ---> 1.0f

Code:
void VID_ApplyGammaToColor(const float *rgb, float *out)

{

int i;

if (cachecolorenable)

{

for (i = 0; i < 3; i++)

out[i] = pow(cachecontrastboost * rgb[i] / ((cachecontrastboost - 1) * rgb[i] + 1), 1.0f / invpow(0.5f, 1 - cachegrey[i])) * cachewhite[i] + cacheblack[i];

}

else

{

for (i = 0; i < 3; i++)

out[i] = pow(cachecontrastboost * rgb[i] / ((cachecontrastboost - 1) * rgb[i] + 1), 1.0f / cachegamma) * cachecontrast + cachebrightness;

}

}

x. Intel Integrated video -- DarkPlaces spams "Fragment shader compile log: No errors." Now perhaps the video driver is at fault for returning "No errors." as the result of a shader compile, but this is Intel Integrated video and there are probably 200,000,000 computers with them. Anyway, the fix ...

gl_backend.c

Code:
if (compilelog[0]) { // Baker 1008 - fix when it reports "no error" and the next line only sees that it contains "error" and prints a false warning.

 if (developer_extra.integer || (developer.integer && strcasecmp(compilelog,"No errors.") !=0 )) {

if (strstr(compilelog, "error") || strstr(compilelog, "ERROR") || strstr(compilelog, "Error") || strstr(compilelog, "WARNING") || strstr(compilelog, "warning") || strstr(compilelog, "Warning"))

{

int i, j, pretextlines = 0;

for (i = 0;i < numstrings - 1;i++)

for (j = 0;strings[i][j];j++)

if (strings[i][j] == '\n')

pretextlines++;

Con_Printf("%s shader compile log:\n%s\n(line offset for any above warnings/errors: %i)\n", shadertype, compilelog, pretextlines);

}

}

}

x. darkplaces-wgl.vcproj should have /LARGEADDRESSAWARE in linker options. When compiled without this, memory allocations can fail when crossing the 2 GB mark.

x. I have never seen this in occur in Xonotic because uses the viewzoom field, but DarkPlaces has a very odd zoom effect starting a map in Quake.

The fix is initializing the viewzoom field.

cl_main.c - CL_ClearState

Code:
// set up the float version of the stats array for easier access to float stats

 cl.statsf = (float *)cl.stats;

cl.num_entities = 0;

cl.num_static_entities = 0;

cl.num_brushmodel_entities = 0;

cl.stats[STAT_VIEWZOOM] = 255; // Baker 1006

x. On a Windows 10 computer, I have experienced a situation where video restart from windowed mode to fullscreen while the engine has the mouse captured causes the mouse to forever more move the player and never mouselook. This does not occur if the mouse is not captured. This applies to 0.8.3 for sure, I have not tested 0.8.5. If I think of what I want to look for, I'll find out the issue, solve it and post the solution here.

x.The official DarkPlaces engine download does not have a "DarkPlaces" icon in the top left corner of the engine window and instead has the "missing icon" icon. Xonotic does have a window icon in the top left corner.

x. DarkPlaces: The Mac version download does not have a valid digital signature. If you set the Mac to allow it anyway,, where is DarkPlaces looking for the data? I have not actually been able to get DarkPlaces to work on a Mac. This is compounded by Mac not really allowing command line parameters for a gui application, so I can't -nohome it or do -basedir .

x. In both Xonotic and DarkPlaces, if you are holding down +attack (like mouse 1) and ALT TAB out of the window in Windows, you will be firing forever until you quit the engine and restart it.

Solve: vid_wgl.c

Code:
// Baker 1002.2

void Key_Release_Keys (void)

{

int      keynum;

    for (keynum = 0 ; keynum < MAX_KEYS /*1024 in dp*/; keynum++) {

if (keydown[keynum])

Key_Event (keynum, /*ascii*/ 0, /*down*/ false);

}

}

Code:
if (!fActive)

 {

VID_SetMouse(false, false, false);

Key_Release_Keys (); // Baker 1002

if (vid_isfullscreen)

{

if (gldll)

ChangeDisplaySettings (NULL, CDS_FULLSCREEN);

vid_wassuspended = true;

}

VID_RestoreSystemGamma();

}

Xonotic port/reboot in Godot - roadmap

ballerburg9005 — Fri, 27 Jan 2023 23:04:21 +0000

A while back I have suggested to port Xonotic to Godot, in order to move it away from legacy tech and make it accessible to a wider dev community, resource base & tons of new huge features and possibilities (like physics, in-game map editor, crafting, building, limitless modding, etc), but it became quite clear that no one from the current dev team/community is really interested in that (or only in an "after the fact" manner, maybe). Especially not so it seemed, the more they had already contributed to current Xonotic code, which seems understandable, but would be the least fortunate grounds to start porting with. I think the idea is very exciting and tempting, but still for just one single person it is too much work to get to a really satisfactory result. Also as Xonotic is very rich in tons of features, some of which tie deeply to the Darkplaces engine, there can never be a total 100% port of the game if it concerns the mostly unused cvars / fine-grained details and it would of course totally break any mods and compatibility. Think of when Mozilla switched Firefox Classic to Firefox Quantum on Desktop 10 years back, which was also a total rewrite of a very old and grown program. To 90% of people the browser remained the same for all intents and purposes, but to a very small minority the switch was a totally insulting outrage, because it broke addons and old features and was clunky at first especially to powerusers. Porting Xonotic to Godot would be a very similar situation. But on the long haul it will be worth it and pay back twice over (but it is lots of work at first, that some people have to do). If you were to put in less effort, you can easily jumble some sort of Quake shooter with Xonotic assets together on the weekend alone with Godot, but it would probably suck by comparison. My take on it is that you need at least two people to put in some serious manhours for some weeks to make it true to the original and take off, or it is just too much overkill for one person. This is why a Xonotic port will probably not happen any time soon, or at all.

I am not trying to port the game right now, but I am making a Duel trainer in Godot 4 (it is sort of a funny mini game) with some of the assets.

I want to give an overview here what works, what is available and what is not. Maybe that will give people a better idea of what all the fuzz is about.

What works:

3D model import from Blender with animations, etc (via glb2.0)
any sort of run-of-the-mill FPS stuff
Converting bsp to map with q3map2

Sort of works:

map import via Trenchbroom Loader plugin (needs Copy&Paste to Valve 220 in netradiant-custom) + bash script to convert dds -> png & normalize weirdo paths in map file (only brush, no patch support & with a few brushes missing randomly) - also Qodot has v4 version now but not tested and should suffer from identical shortcomings
basic Quake movement code BUT without 100% original collision code (100% original code can be done but you have to bypass standard physics functions for it and do everything manually like in Darkplaces, which is rather messy by today's standards and most people don't consider this to be "worth it")
3D Performance with Godot 4 has been reported to be bad, depends on what features you use, but this is "intentional", since Godot 4 is still beta - it doesn't say much at this point

What does not work / exist:

sandboxed modding (Godot has absolutely no sandboxing yet - writing modding API would SUCK so bad by comparison, imho better to just sit this one out until Godot 4.1 or 5.0 or whatever. New: As pointed out in this thread, there is a Godot Lua API for sandboxing. However, I would be hesitant to go that route, for performance concerns and bugs. It would be MUCH nicer if Godot made this an engine feature using Gdscript, which is destined to happen "somewhen".)
networking code (because you have to write it all from scratch, the engine doesn't have any special features for this that make it easier. You have tons of code examples of course and you can steal high-quality code everywhere, but only to a certain extent, since Xonotic is input-based, which is too unusual. Of course it is still modern code and NOTHING alike writing QuakeC. Stats & Gamelist count as network code and also have to be reimplemented. If you want to see a quick intro how networking code works in Godot 4, see this post: https://forums.xonotic.org/showthread.ph...4#pid89284 )
all non-trivial shaders like skyboxes and lava need to be set up from scratch (I can imagine that you can crudely convert q3 shader logic via script in 60-80% of cases maybe to get at least some sort of passable surface.)
cvars (all cvars need to be reimplemented manually)
loading assets directly (all assets need to be imported by devs into a Godot "scene" via editor for them to work, even maps. So without sandboxing or custom map-loading code, at this point you are not able to load any untrusted community maps.)
game logic of course has to be written by hand. There is nothing in TBLoader that tells Godot what a jumppad means, a door or a portal.

Could conceivably work, but untested:

dynamic bsp loading (hint: loading bsp maps already works via q3map2 conversion to .map file, then conversion to Godot scene)
doing stuff from within the game you can only do in the editor (editor/plugin code works 100% identical to script code, the editor basically is a "game" itself)

Welcome Message Dialogbox

Cooper Hawks — Wed, 18 Jan 2023 09:40:16 +0000

hey there,
since v0.8.5 there is this dialogbox where you can choose if you want to join or spectate when entering a new match. Can this dialogbox be disabled, so that it works like in v0.8.2?

“Extended Translation Pack” is Possible

NaitLee — Sun, 04 Sep 2022 17:01:26 +0000

I gave it a try to make “Extended Translation Pack” in my own language, here’s the repo.

Update: The repo is renamed and have script infrastructure for variations.

Non-English players that have hard time with English can feel ease, if they see their local language.
(Or say, maybe weird, if they don’t see any strange foreign script…)

Detailed explanation below.

I’m working on localization work these days and noticed that stuffs like Campaign description can’t be translated via “standard” approach (official Transifex team).
Singleplayer Campaign is the very first experience to new players. But what’s the point if it can’t be understood?

So workaround should be done. I know about that the game/engine have concept of “packs”, those .pk3 files or .pk3dir directories. This made it convenient for modding, for example.

In the meanwhile, a big majority of Xonotic functional assets are text files. In my opinion it’s a good matter: they are much easier to learn & modify, in contrast to those static code.
This also shows how devs here care about flexibility. Big thanks!

So that I just search for those related files (e.g. maps/campaignxonoticbeta.txt), copy & modify the strings inside, put to external pack, raise its priority to override the original, then it will work.

However, there’s a significant drawback: those functional bits are also being overridden, if affected files have official updates, they won't take effect until players update the pack (after my update, of course).

At the moment it does no harm, for affecting only few files. But be careful anyway, as a non-functional game (edge case) can be worse if English makes less or no hassle.

I wish better internationalization ability will be offered officially. Great game like Xonotic ought to be known by global gamers — and let’s don’t forget Software Freedom.

[Idea] “Knockout” gametype

NaitLee — Sun, 04 Sep 2022 16:11:52 +0000

There’s some kind of new gametype in my mind: a “pyramid” fight.
I call it “Knockout” but may have better word.

Several players will join the game.
Only 2 players are simultaneously “released” and fight each other. Others will spectate.
When one get fragged*, he/she is lost and will spectate. Now, announce the winner, and “release” the next player (reset the winner’s weapons too).
Keep fighting. The game ends when the final winner is elected, the “King”!

* For some sort of enjoy-ability, may start with 200 HP + 200 Armor like Clan Arena.

I put this to my wishlist, and maybe one day I can get time to work on such thing (not guaranteed though) (maybe with other “gametype” ideas around here).

P.S. This is what a “duel” was in my mind, before I knowing about “duel is just 1v1 deathmatch and no more”.
(Poor kid like me can’t see a public server with ping < 200, and never experienced playing there)

Where are Weapon skins?

NoClue — Thu, 07 Jul 2022 18:26:00 +0000

I would like to do some skinning myself however i don't seem to find any texture files is there any tutorial to follow about skinning? I kinda figured that the skins might be included in iqm? But i'm not sure if this is right. Setting up Blender just to do some skinning seems to be annoying as well since it doesn'T work by default with xonotic.

Speech to text, or almost voice chat

oblector — Thu, 30 Jun 2022 23:29:16 +0000

I describe how to chat while playing, by speaking (not typing), without the necessity of the recipients installing additional software. As it is a kludge, you may want to change the details.

First install some speech to text software, such as nerd-dictation. Remember to download models for one or more languages.

As far I know, for security Xonotic can not execute external programs. So we'll have a script for executing nerd-dictation when some specific files in the .xonotic directory get changed.

Consider the following script (depending on inotify tools), which you may need to adapt, as it presupposes some directory names and that the models you have are named model-en and model-pt.

Code:
#!/bin/bash

set -eu

xondir="$HOME"/.xonotic/data/

diagn() {

  printf "%s\n" "$1" >> /dev/stderr

}

main() {

  cd "$xondir"

  outfile="$xondir"/voiceout

  nerddic="$HOME"/gits/nerd-dictation/nerd-dictation

  while true ; do

    diagn "Waiting signal..."

    # Change the languages here:

    file=$(inotifywait --format %w -e modify en pt)

    diagn "Received start signal: $file"

    echo -n > "$file"

    {

      model="$HOME"/gits/nerd-dictation/model-$file/

      res=$("$nerddic" begin --numbers-as-digits --vosk-model="$model" --output STDOUT | tr '\n' ' ')

      diagn "Writing text...: $res"

      printf "set nerddic_text \"%s\"" "$res" > "$outfile"

    } &

    diagn "Waiting stop signal..."

    inotifywait -e modify voicestop

    diagn "Received stop signal"

    echo -n > voicestop

    "$nerddic" "end";

  done

}

main

Inside the .xonotic/data/ directory create the empty files: voiceout, voicestop, en and pt.

Add the following (or similar) to .xonotic/data/autoexec.cfg:

Code:
set nerddic_text ""

set lang en

alias voiceask "condump $lang"

alias voicestop "condump voicestop"

alias voicerecstart "cprint Recording voice... ($lang); voiceask"

alias voiceexecres "exec voiceout"

alias voicerecend "voicestop; cprint Processing, wait how much I do not know"

alias voicesayres_ "say ${nerddic_text}"

alias voicesayres "voiceexecres; voicesayres_"

alias voiceshowres_ "cprint ${nerddic_text}"

alias voiceshowres "voiceexecres; voiceshowres_"

alias voiceteamsayres_ "say_team ${nerddic_text}"

alias voiceteamsayres "voiceexecres; voiceteamsayres_"

Then start the bash script, and run Xonotic.

Note that some files are modified with condump, which writes the entire console history, a bit inefficient. Anyway, speech to text demands more power and time.

You may change the language with the Xonotic console command lang pt. You may bind some of these commands to some key presses; the command voiceshowres shows the interpreted text before publishing.

You may want to change the code to automatically send the text after recording; caution with race conditions.

It seems to be slightly practical (not much in phrenetic games). I couldn't test it rigorously because I'm not a fluent anglophone, nor I have a quality microphone.

Thanks for the attention. Suggestions? Also, I'm grateful for this marvelous game.

Xonotic reboot/port in modern engine

ballerburg9005 — Mon, 27 Sep 2021 12:18:43 +0000

Please tell us shortly if you are interested in porting Xonotic to a modern Engine, what your skills are and how much time you could invest initially and on the long run.

I think we can all agree that there is no good strategy to go forward with this. The two options I see are:

Xonotic "Quantum" (stealing all the old assets, porting just the bare minimum code to get 1:1 gameplay, breaking all the mods and implementing only like 5% of the cvars)
QuakeC wrapper (or semi-atomatic converter) to transform at least some legacy code from portions of source code into modern code or at least run it as binary

Which engine? Godot 4 seems the only good choice to me.

What comes next? The new Xonotic will essentially evolve into Fortnite on the long run.

Also I think we should name the first 1:1 port "Yonotic". And when it becomes more like Fortnite, we name it "Zoonotic" and it will default to fully customizable furry player models.

How to create a command - DarkPlaces engine C programming

LegendGuard — Sat, 27 Mar 2021 22:26:50 +0000

Hello, all!
It's the first time I've touched engine code to test something simple.
IMPORTANT NOTE: only modifies engine part.

1. Open a file called console.c in xonotic/darkplaces folder

2. Write the following in the line 842 (NOTE: This line is specific, if you see something not empty, don't do. The code may change in some time due to the development, so don't write inside the functions, write it outside the functions)

Code:
//LegendGuard first time using engine code 27-03-2021

/*

================

Con_Hello_f

================

*/

static void Con_Hello_f (void)

{

   Con_Printf("HELLO XONOTIC! I'm LegendGuard, touching console code in the engine! :D\n");

   return;

}

3. Write the following line to call the command function in the line 917 more or less where says "// register our commands":

Code:
Cmd_AddCommand ("hello", Con_Hello_f, "output a hello message");

4. Save console.c file and go to console MSYS2 (as I use Windows)

5. In the console, while you're in xonotic/darkplaces directory, write and execute  make sdl-release
(optionally, you can use  ./all compile -r   when you're in xonotic directory but IT'S NOT RECOMMENDED, since it compiles all contents and is slow to check the results of your code in the engine)

NOTE: about  make
sdl-release = xonotic-sdl
sv-release = xonotic-dedicated
You can compile graphical with glx or sdl interface or non graphical dedicated good for servers without a windowing system.

There are differences:
make sdl-release uses sdl2-config (in my system is version 2.0.12) (uses -ljpeg)   - USE THIS COMMAND IN xonotic/darkplaces DIRECTORY -
./all compile sdl uses xonotic/misc/builddeps/win64/sdl/bin/sdl2-config (version 2.0.10) (doesn't use -ljpeg)   - USE THIS COMMAND IN xonotic DIRECTORY -

You can see more info in the makefile

6. After compiled successfully, go to xonotic directory and run the game with ./all run

7. Press Shift + Esc, type  hello and ENJOY!!!