Xonotic port/reboot in Godot - roadmap

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)
  

I did some cursory looking around.

I found a video of someone trying to make a CSGO-like port, but he abandoned the effort because it was too hard for him.

I found this and looked through the code ...

https://github.com/axel37/godot-quake-movement

As I understand it, in Godot you will have to write the network code in gdscript and what DarkPlaces does in the engine like predicton and collision will have to be in gdscript.

This is a 5-alarm red flag if true.

QuakeC is not particularly slow if it is used for what it is good at and not used in excess for the wrong things.

Now imagine something possibly slower than QuakeC also doing networking, collision and other things that DarkPlaces does in the engine in script instead of compiled C.

If you have links to something where someone got something solid started, please share.

It does not look like Godot was ever designed with any thought of supporting first person shooter style play and the performance needed to pull it off.

Reading through things Godot seems like the only "modern" open source engine around and it seems like it was meant for platformers and making isometric games for phones. 

I would love to be totally wrong about all of this, btw.

(I've watched Xonotic as an outsider since day 1 and have great respect for what Xonotic has achieved.  I like development discussions by intelligent people so I kind of like reading the threads here.  I have the suspicion that within a days or 3 weeks -- I get on coding tangents easily ---  I will probably be releasing a modded DarkPlaces with numerous minor conveniences added, but probably nothing that would interest you personally except perhaps for alt-tab toggling fullscreen/windowed mode.  I would rather these changes be in official DarkPlaces but I have been unable to establish email contact with the author thus far.  Honestly, now that I think about it -- getting the changes in Xonotic would be about the same thing -- I use the Xonotic source code, haha)

GDscript is only slower if used in a naive way, e.g. when reimplementing bubble sort by hand. In actuality however, programmers use sorting functions provided by the library and those execute with quasi-native speed. If you find yourself doing lots of for-loops in GDscript, your programming approach is probably just misguided, and you are reimplementing the wheel instead pf using the engine. In Godot, you literally write "scripts" for objects to behave a certain way in a "scene". It is not a tool to do heavy computations by hand, this is just wrong and unnecessary. QuakeC on the other hand is a very raw and basic laanguage and it doesn't ship with any utilities or functions that execute at native speed. Therefore anything written in QuakeC suffers considerable penalties, and simply using QuakeC "too much" causes slowdowns.

However so ... suppose you wanted to e.g. have real C64 emulator inside the game as a minigame. Then you can do this via native library.  You can do anything via native library, but it rarely makes sense at all if you understand what you are doing.

Godot also lets you use C# instead of GDscript, which is reasonably as fast as C++. Like I said, when used in an ordinary way there is virtually no performance gain compared to GDscript. But when you do a primitive speed comparison with for-loops, it is about 4x faster.

Links to functioning games were already provided. But there are just so many shooters done in Godot  it is impossible to link them all.

Engines like Godot or Unity are not "specialized" on FPS for PCs, there hardly is any such thing, unless we are talking about really small fringe engines like Darkplaces. Big modern engines only need to be optimized for 3D and networking, they work for anything 3D or 2D. The engine is also not 20 years old like Unreal or Unity. But I think to say in essence that it is or could be by design too weak/naive to pull off an FPS game that runs on 20 year old specs, that's just far-far-out reaching for straws, it is nonsense.

The only thing making Godot slow, in terms of being an inconvenience, is that it is bleeding edge, or you want to use bleeding edge. If you use certain render pipelines for example or particle effects, right now in the beta those are/were essentially bugged and cause like 50 fold performance losses. This will go away and it is not a huge deal, switch it on switch it off, it doesn't break the game.

One has to be very mindful of the fact that programming a Doom clone is one of the simplest and easiest things you can do in game programming. Quake is basically Doom with beefed up graphics (handled by engine and assets already exist). From this point on, that is, the easiest thing to do in terms of game programming, we are only one single step away from it with Xonotic. What then makes Xonotic code special?

1. trialed unusual network code
2. lots of customizations (most of which are unused, so not immediately important)

Now granted, coding a game is work, yes. But it is not like we are trying fo port Fortnite here, Sim City 5 or Elder Scrolls. We are trying to port a customized version of Doom/Quake into an Engine that already ships with almost everything prepared for such a game. This is something that one single person could do in reasonable time if paid for it. And what multiple people can do in their spare time if somewhat invested.

Looks like these guys are making some progress ...

https://www.youtube.com/watch?v=fo-1uduEsEY

If that gets more traction in the coming months, it would be a solid blue print.

How do you make a map in Godot?  You've said you've used it for 18 mos.

Like if I had a q3 .map would I be able to convert it?

What map editors does it support?

Can you create supermassive worlds in it?

How do you make a map in Godot?  You've said you've used it for 18 mos.

Like if I had a q3 .map would I be able to convert it?

What map editors does it support?

Can you create supermassive worlds in it?

The short answer is: Yes you can load any map, .map or bsp it does not matter. But you have to do some awkward-ish tricks first and the results will in most cases have a few flaws which are mostly visual in nature. I would say as the tools are right here and now, 50% of the maps will be ok-ish and 40% will be ugly-ish but almost perfectly playable, and maybe 10% might need some rework to be playable. Not sure though. It is not *that* much work to code Patch support into Libmap for Godot, so this could easily be improved on dramatically, so that maybe 90% of the maps look ok-ish with minor visual flaws off the bat and 100% are playable. For a start, the way the tools are right now, it is just a done deal. No one really cares about those minor visual flaws. Missing Patch support, this is not vital to get the ball rolling, but it should be added way way down the road at some point of course since we are talking about some basic geometry missing here. Anything else like texture misalignments here and there, you could totally roll this into production, it would not really matter and no one really cares.

What people really care about are all the new features and possibilities to the game, like in-game level builder and more interactive persistent and interconnected virtual worlds where people can meet to talk and have fun. Like you could have an entrance lobby where you can shoot ducks, spray graffiti to the wall and do private chats in rooms easily while you wait for duels and TDM match to have enough players. When the match ends, you could drop back to the lobby for social interaction. Just an idea, but the possibilities are endless with Godot. Just a matter of drag & dropping the scenes together. If you have ever used Godot, you would know that it is basically like crafting a table with deluxe power tools versus crafting a table with only a Swiss army knife. That's how god damn easy anything in it really is. It is not like in Darkplaces, where you have to turn the entire engine inside out and upside down to accomplish such features, and then you have 10x slowdowns because you can't really use QuakeC this way. That's the whole point of switching away from it.

If you want I can post step-by-step instructions how to load maps into Godot.

Trenchbroom loader and Qodot currently only truly support Trenchbroom, which is an alternative to Radiant. Godot itself can be used as a map editor as well, similar to Blender 3D but with logic attached, which is very useful for all kinds of things, but especially important and useful when you are thinking of creating maps dynamically inside the game based on map styles (a very desirable feature you could add in a Xonotic port of Godot). With the Godot scene editor, you can for example create a style for a wall, which will put pipes and broken bricks, windows, etc. into this wall automatically based on rules you define in a script. All this will be displayed live in the editor. This way with the help of complex script rules, a player could simply block out a map inside the game with giant blocks, and have it decorated by the style automatically. The result would be very similar to regular maps, but every player could become a mapper and it could become a social thing to meet in the game and design the world around you. Also the styles could be modded by anyone to make maps more unique looking. Simply by dragging objects around in the editor and point-and-click loading textures, etc. the entry barrier would be much lower for people and there is no limit to possibilities, unlike mapping with Radiant. No other in-game map editor can parallel what you could accomplish with Godot, and the ease at which such things are possible and accessible to a very very wide audience of devs and users is absolutely key to success.

You can create supermassive worlds in Godot, but it would require extra manual effort. There are no really special features in the engine for this for all I know. Dynamic level loading maybe is a thing. I think supermassive worlds are not really a consideration right now, but only until the game would really be polished in a production stage for a longer period of time.

I mean it is all just talk at this point, and the contemporary shortcomings of the engine were already outlined. But just saying, if this was to take off...

If you don't mind and have the time, yes please post instructions.

I imagine loading models into Godot is easy, but I am concerned about map development.

I have invited the main developer of Liblast, unfa, to participate in this thread.

We will find out if he is interested in posting here.

https://godotforums.org/d/32089-liblast-...oftware/45

I have invited the main developer of Liblast, unfa, to participate in this thread.

We will find out if he is interested in posting here.

https://godotforums.org/d/32089-liblast-...oftware/45

Hey, thanks for the invitation

Long time no see!

If you don't know me - I've been playing Xonotic for years and years, but didn't play much for years now (though I think one of my music tracks is still part of the Xonotic OST).

2 years ago I've finally got my own project off the ground - Liblast. The core idea is to make an online FPS that will be friendly to new players and limit the effects of skill inflation, revising what doesn't work about classic arena shooters in the long run.

Which boils down to: after a few years the core playerbase becomes so good that no new players can break through in deathmatch, because they get their butts handed to them over and over, so bots is the only thing they can really enjoy.

My game design for Liblast is aimed to limit that and make a game that will hopefully be still very much enjoyable for new players, even a decade later, when there's real veterans around who know the game like the back of their hand.

In regards to mechanics it's highly inspired by UT'99 and TF2. In aesthetics, I think its probably quite similar to Xonotic - going for a slightly stylized, simple yet detailed (paradox, huh) Sci-Fi visuals. The game has a simple story and setting and revolves around private humanoid robot armies battling for resources around the universe.

The game is *not* an arena shooter, and it's *not* a movement shooter, though the movement speed is rather fast and everyone has jetpacks. No bunnyhopping, walljumping, kicksliding etc though.
It's *not* a direct remake/FOSS clone of any existing game, it's an original thing, taking design cues from various places and hopefully creating something unique and good in it's own right.

Still in early stages though

The game is fully open-source, licensed under AGPL (like GPLv3  with the added feature of extending the license to server software) , and assets are CC-BY-SA. Everything, including assets is created using open-source software, and asset sources are in the git repository, so anybody can revise them. One issue I see with many FOSS game projects is that assets are still make with random proprietary software and they are not editable once someone contributes. Which also makes it so nobody can improve their game content after they are out of the project, and the game artstyle suffers.

The game is made with Godot 4 (been in Godot 3 first but ported it as soon as Godot 4 stopped crashing every 5 minutes). So far there's a unfinished TDM game mode, which is a stop gap to the core game mode I want to make which is something between domination and control points - again, this is to take game's focus off of fragging newbs, making killing others means to an end, and not the goal itself, to let new players just keep their distance and not get hurt (as much).

In classic DM the weakest players are a honeypot for getting easy frags. It's an absolutely merciless game design that incentivizes squashing beginners, which in turn stops the playerbase growth. Add item control and you have what I think made arena shooters go out of style. It's not about fast movement, abstract level design or frantic fights. It's about alienating new players.

So as much as I love UT, Xonotic etc - I think copying the classic arena shooter design just won't work in the long run.

In Xonotic you can go to a public server and get absolutely destroyed in DM and the nice people there will even apologize for steamrolling you, but the can't help it - the game is about destroying the weak! There's nothing you can do except for creating different incentives for players, that'd create a safer space for newbies to learn in.

That's why in Liblast in 1.0 I plan to first offer only Control Points and maybe Duel (which is always fair, even if brutal). No DM or TDM, to have a chance at implementing the game design that'd make the game fun for the decades to come.

I'm a sole programmer right now with some others contributing art and stuff - if you're interested in contributing, I would gladly onboard you into Godot to help me make this game faster and better for the community to enjoy

https://libla.st

A.M.A!

I'm about to sleep ...  I'll do a proper reply when I wake.

Wanted to say thank you for replying.

I just completed an engine mod release so I'm a bit sapped, at the moment.

https://www.moddb.com/mods/zircon-engine

The engine release is to support a larger mod.

https://www.moddb.com/mods/zircon-galaxy-alpha-10

Ill tell you what, if Ballerburg is wiling to help also, I'll join your team. And I'll help both of you get what you want as best I can.

I haven't used Godot or gdscript, Ill need some help learning the ins and outs of Godot, getting setup.

I also want to try to use Trenchbroom with Godot to see map how maps work with it, but I will need pointers from Ballerburg.

Ballerburg are you down for this?

Here are the instructions for loading .map files from Xonotic into Godot:

1. Download netradiant-custom (not Xonotic netradiant)
2. If you only have a .bsp file, convert with q3map3 (distributed with netradiant-custom) to .map

Code:

Q3map2=; ~/netradiant-custom/install/q3map2 -convert -format map -game xonotic revdm3.bsp

3. unzip dds folder content within xonotic zips into new ddstextures.pk3dir directory & extract textures:

Code:

cd /usr/share/xonotic/data/
find xonotic-*.pk3 -exec unzip '{}'  'dds/*'  \;
mv dds ddstextures.pk3dir && cd ddstextures.pk3dir
find ../xonotic-*.pk3 -exec unzip -o '{}'  'textures/*'  \;

4. open the map in netradiant-custom (#1)
5. Go to Preferences -> Brush -> New map Brush Type - and set it to Valve 220
6. Click File -> New Map, which opens a new window (#2)
7. now go to the first window #1 and disable Hints (and maybe Clips) for testing in View -> Filter
8. select everything in the map by dragging over it with Shift + Right Mouse Button
9. copy & Paste the stuff from #1 into #2 and save the .map file as e.g. maps/revdm3-valve.bsp inside your Godot project folder
10. go into your Godot project folder and use this abomination to copy the textures:

Code:

MAP=maps/revdm3-valve.map; cp "$MAP" "${MAP%.*}-godot.map"; for i in `sed -En "s/.*\)[[:space:]]+([^[:space:]\(\)]+)[[:space:]]+.*/\1/gp" "$MAP" | sort -u | uniq`; do FILEN="$(echo $i | sed -En "s#.*/([^/]*)+\$#\1#gp" | sed "s#-#_#g")"; FILEN2="$(echo $i | sed "s#-#/#g" | sed -En "s#.*/([^/]*)+\$#\1#gp")"; FILEP="$(echo $i | sed "s#-#/#g" | sed -En "s#(.*)+/[^/]*\$#\1#gp")"; ACTUAL="$(find /usr/share/xonotic/data/ddstextures.pk3dir/textures/ /usr/share/xonotic/data/textures/ -iregex ".*${FILEP}/${FILEN}\.\(tga\|png\|jpg\|jpeg\|dds\)" -or -iregex ".*${FILEP}/${FILEN2}\.\(tga\|png\|jpg\|jpeg\|dds\)" -or -iregex ".*$i\.\(tga\|png\|jpg\|jpeg\|dds\)" | head -n 1)"; if [[ "$ACTUAL" == "" ]]; then echo "Not found: ${FILEP}/${FILEN} ($i)"; else echo "Found: '$ACTUAL'"; sed -Ei "s#[[:space:]]+${i}[[:space:]]+# /${FILEP}/${FILEN} #g" "${MAP%.*}-godot.map"; mkdir -p textures/${FILEP}; convert "$ACTUAL" textures/${FILEP}/${FILEN}.png; fi; done

(note: this is sort of makeshift, since there are a buch of weirdo path conversion rules I don't really know)
11. In your Godot project, install Trechbroom Loader (Godot 4) or Qodot (3 and 4 now also?), activate it and then load and convert the map (revdm3-valve-godot.map) as instructed



Hint: Only few maps actually load for me in Trenchbroom (hangs). This could be fixed with better bash script, or maybe by using Qodot instead of TB Loader.

Hint: Whenever I extract maps from the internet to load in Netradiant, I extract them to /usr/share/xonotic/data/ - the root folder of the installed game - in order to keep my user directory clean. This folder is also scanned by the script for textures.

If you only have Windows, install Linux instead. If not possible, use MSYS2:

1. Download and click though the installer
2. Open MSYS2 MINGW64 (drops you into Linux shell)
3. pacman -S imagemagick zsh && zsh # try pacman -Sy if it produces errors
4. Navigate to folders in shell and match the Unix paths to the Windows paths

3. unzip dds folder content

I guess you can just unpack  xonotic-20220627-maps-mapping.pk3

there are a buch of weirdo path conversion rules I don't really know

If I understand correctly, real texture paths should be read from quake 3 shaders (the "scripts" directory), as well as other surface properties (which may be tricky to implement in Godot)

Hello Unfa, nice to have you here in the conversation.

I want to emphasize again that a Godot Xonotic port is not really on the table right now. This is just me messing around and trying to explain the benefits and what is possible with Godot and what I have discovered to work well in the minigame I am working on.

I like Xonotic and I want to keep the old maps and style alive, bring them to a new era. I have lived through the death of OpenArena and Warsow and it sucked, so I don't want this to happen to Xonotic as well. I wish it could evolve, move to the frontlines again, get rid of all the limitations that are holding it back. With Godot the possibilities are endless! Every custom map can essentially be a custom game, like a second-life environment, minecraft environment, metaverse, aimlab, level-builder, etc. and it totally is childsplay to do this, just like ordinary mapping with Netradiant is "childsplay" once you learn a few tricks to use it. You know those LEGO Mindstorm robots that 8 year olds can program? This is how easy Godot is compared to programming in bare C.

Yes getting the basic game and network code running is still hard work though (but code-stealing obviously speeds things up).

Anyway, maybe you could say something about your network code design and how much help the engine gives you for network code?

Also what is your grand vision for Liblast, what innovative ideas will it ideally have? Do you want to e.g. make a metaverse-ish hangout lobby for socializing when you join the game, community servers with rating system, battle royale, in-game stuff like level-editor, item systems, customizable characters, experience points/player stats, alchemy, single-player missions, swarm-intelligent enemies, hack mechanics, crafting and building? Which game will it be most comparable to (Fortnite, CS, COD, etc)?

I don't know if I really want to invest myself into your game, but I have thought about it. I don't know though, I couldn't live with your development approach I think. I believe that stealing code and assets from other games, where it has already been trialed, this is the only way to get anywhere in reasonable time. Or else you need like a paid team of 10 people to make it look good and feel good. It is just too much effort to like design guns by hand and compose sound tracks. I can't even produce any real artwork myself. Also I want to start now and be finished tomorrow, and then do new stuff that has never been done before. It is all about getting to the second part of it. Not having a goal post in reach, where the game would be remarkably better than what we already had before from other open source games, this would be too awful for me to endure.

Btw. do you know how many man hours it takes to make a serious map for Xonotic? (answer: probably at least 50, maybe much more..) Other assets are not that different. This is not something you can make from scratch in your own game, it just has to be there to begin with or your game won't really be there to begin with. I mean, yes, you can make all sorts of fun shooters in your spare time, even with minimalist maps and assets. But it is not like they will be Quake Champions rivals or Fortnite rivals. Xonotic somewhat could be or already is, at least in the free software dimension. That's what really matters to me.

Plus I love games to be challenging, but it is very bad if less skilled people are given undue credit, like a fat person winning the olympics by making his track shorter - that's just wrong. There are three awful mechanics to mitigate skilled/veteran players: 1. max out on random chance, everything becomes just a dice roll (random item drops, unpredictable weapon behavior, etc.) 2. remove elements of the game that require skill (e.g. aim -> autoaim, remove strafe-jump, remove armor, remove finessed movement code), 3. match making 100% to same skill level with other players (makes everyone lose exactly 50% of the time at average, no matter what they do, they can never accomplish anything more or less than being just mediocre).

Visible handicaps are ok-ish (e.g. people with handicaps get like one or more veteran stars). Also separating the players into leagues you can climb, this is good if the playerbase allows for it. Alternatively you could make noob servers and regular servers. There is this one server called "Xonotic 0.8.2 server" that has banned all the good players. Also you can add other mechanics and skills into the game, like noobs could hide in a corner with a shield / constructed shelter or they could support team mates with healing spells or what not. Or you have different classes all together like snipers vs meele vs vehicles, but this is very hard to balance and would not work on classic arena maps.

3. unzip dds folder content

I guess you can just unpack  xonotic-20220627-maps-mapping.pk3

there are a buch of weirdo path conversion rules I don't really know

If I understand correctly, real texture paths should be read from quake 3 shaders (the "scripts" directory), as well as other surface properties (which may be tricky to implement in Godot)

If a regular texture is not enough, you can define shaders in the .script file to e.g. create lava, skyboxes or transparent windows. Those files are in q3 shader format, more or less, and this format is not trivial. In a Xonotic port, I really would not want to reimplement this format, but instead parse the script files with bash/python, which puts them into broader categories (skybox, liquid, transparent, etc.) and then just have one surface configuration for every category. This will yield reasonable and visually not broken results with minimum effort, while not bloating the code base with legacy implementations.

.script files are only necessary and commonly used for special surfaces. The paths in the .map file however are weird in this way: exomorphx/floor-metal_floor-04c.dds can become something  along the lines of exomorphx/floor/metal/floor04, but also /exomorphx/floor/metal/floor-04c or exomorphx/floor/metal/floor/04c. I guess for legacy reasons, the rules are inconsistent.

Maybe I don't understand something, but I don't see any inconsistency

The paths in the .map file

All the .map files I saw contain the q3 shader names, not the paths. For example, "exomorphx/floor-metal_floor01" refers to the "textures/exomorphx/floor-metal_floor01" shader defined in "scripts/exomorphx.shader". This shader has line "map textures/exomorphx/floor/metal_floor01" which contains the exact texture name, so there is no need to use any conversion

along the lines of exomorphx/floor/metal/floor04, but also /exomorphx/floor/metal/floor-04c or exomorphx/floor/metal/floor/04c.

According to my grep, all these forms are never used in the xonotic .map or .bsp files

Ballerburg, thank you for the instructions.

Maybe I don't understand something, but I don't see any inconsistency

The paths in the .map file

All the .map files I saw contain the q3 shader names, not the paths. For example, "exomorphx/floor-metal_floor01" refers to the "textures/exomorphx/floor-metal_floor01" shader defined in "scripts/exomorphx.shader". This shader has line "map textures/exomorphx/floor/metal_floor01" which contains the exact texture name, so there is no need to use any conversion

along the lines of exomorphx/floor/metal/floor04, but also /exomorphx/floor/metal/floor-04c or exomorphx/floor/metal/floor/04c.

According to my grep, all these forms are never used in the xonotic .map or .bsp files

Ok thanks for explaining this particular instance to me, but there is more to this story which creates the outlined path conversion issues. But this isn't really something to figure out in this thread. 

Like I said this is only makeshift and it fits the purpose well in being totally ignorant about q3 shader format and script files. If we were to actually write a Xonotic port, someone would have a closer look at it and write a more sophisticated script to transfer shaders into Godot, like explained earlier.

I guess you can just unpack  xonotic-20220627-maps-mapping.pk3

No, please only use the support package if you are making a new Xonotic map from scratch and want to use the common texture styles. Always use the unpacked textures from the pk3s directly from your game and map files if you open existing maps, or you risk running into missing textures.

No, please only use the support package if you are making a new Xonotic map from scratch and want to use the common texture styles. Always use the unpacked textures from the pk3s directly from your game and map files if you open existing maps.

Well, then it's better to download the original textures (and the original .map files) from gitlab instead of this weird reverse-engineering. Unpacking pk3s only makes sense to get resources that are not available in vanilla xonotic

No. For this purpose we want whatever we see in the game to load to easily work without exceptions or complation or sources of error. And if you are working with Netradiant regularly and load existing maps from the internet, this is also what you want most of the time. There are several pitfalls, like the nexcompat package missing, that just overcomplicate using/explaining any other method.

Hint: I updated the instructions to extract not only dds but jpg as well.

we want whatever we see in the game to load to easily work without exceptions

This implies that you should never use .map files (and therefore TBLoader and/or Qodot) because the game doesn't actually use them

Is there a good bsp plugin that can import xonotic maps?

we want whatever we see in the game to load to easily work without exceptions

This implies that you should never use .map files (and therefore TBLoader and/or Qodot) because the game doesn't actually use them

Is there a good bsp plugin that can import xonotic maps?

As instructed, q3map2 can convert .bsp to .map very very reliably (results range from "100% flawless" to "100% playable with minor visual flaws, like few textures misaligned or rotated wrong"). This is the way to go and potentially load any map you want into Godot. Of course as outlined, the Godot plugins currently are missing support for a certain type of geometry that is mostly and rather sparsely used for decorative purposes called "Patch". So this is something you would really need first to actually match those flawless results in Godot for most maps. To simply play the maps however for testing and to and have fun, tons of maps would work even without it.

Otherwise in the first post, there is also a Godot plugin for direct .bsp loading made for the original Counter Strike. Interesting ground work, maybe if the port is complete one could consider conversion-less map loading from old pk3s. But really this is just not something you would want in a first version and something that just overcomplicates things.

Meh, conversion looks too stupid to me.

By the way, Godot seems to natively support dds (though not in runtime yet) and TBLoader automatically picks it up. Is there a reason why you do the dds→png conversion in your bash script?

Andreymal, I feel such minor details belong into chat rather and are not actually relevant, considering that this is not even actually a "project", much less something where implementation and development would be a topic. Those things are the way they are, because it somehow worked better/faster/easier/only this way, or just randomly so.

This thread is meant to provide basic information and insights into new technologies, in order for people to develop a better concept of the possibilities.

Also conversion is not stupid at all and q3map2 works with extreme precision. You have to remember that Godot is alien technology to Darkplaces. It is a miracle that those tools run so much stuff so well almost out of the box. We should be greatful for this and cease the opportunity. Also the most important factors to a new game are keeping codebase clean, maintainable and small versus player (not developer) satisfaction reasonably high. If that means having the light from the skybox shine at the wrong angle, or the water shaders all look the same style, this is perfect and further improving this at the expense of losing time elsewhere or making the code more complex is wrong and just bad development attitude in the beginning. Player experience is all that matters. Truth is players will have just as much fun even with here-and-there missing textures, imprecise lighting and what not, even if that will certainly be improved upon later anyway. Make it work for most people in things they actually care about, keep up with the train forward and don't backtrack for small details - at least not until a version 1 or 2 will be released. When porting the game, you really don't want to look at what Darkplaces has and shines at, but what it *doesn't* have and will never have. This is what a port is all about, and why you want to take the fast lane to overtake it, rather than precisely matching speed and direction with it. Nothing could be more wrong than the latter, it is a bad backwards mentality against progress.

If you're thinking about "porting the game", the first thing to take care of is implementing the most important things that the current version of the game has.

For me personally, these things are movement, warpzones, sandboxed modding (CSQC) and lots of existing content since 1996.

Obviously, we can replicate almost all of Xonotic's gameplay on another engine (it doesn't matter if it's Godot or not) because it's basically just a first-person shooter. But if you lose some unique features because of the current engine limitations - would it be worthy of being called Xonotic? I'm not sure.

Even if there will be Vulkan, PBR, RTX, lobby, voice chat, blackjack and beautiful female player models - does it all matter if I can't just connect to a non-vanilla server and play weirdcube_v2.bsp?

So for me the list of major things looks something like:

- Do something with sandboxing, modding, mutators etc. This is probably the most important thing that may affect the entire architecture of the game, so I think this should be the very first thing to investigate.
- Do something with bsp, q3 shaders and maybe other assets. The current state is very far from "99% success rate" - almost every map will have some ugly bugs because of the limitations of the current plugins. The process of loading resources at runtime will probably be closely related to modding and mutators, so I think this should be the second thing to investigate.
- Do something with warpzones. I know it's possible to implement some warpzones in Godot, but since it's a pretty complicated thing, I'd like to make sure it's fully compatible with the Xonotic gameplay.
- Do something with movement and related things like client-side movement prediction. I hope this is relatively easy to implement, but since the Xonotic movement is not the same as either Quake or Nexuiz and the movement prediction is not trivial, I think it makes sense to pay some attention to it. By the way, players can move through warpzones.
- Last but not least is optimization. I know that Godot 4 is not optimized yet, but will it be well enough optimized in the future? Is GDScript fast enough? Will sandboxed modding fast enough? Liblast is literally unplayable on my PC due to lots of freezes. I hope this will change in the future, but if the "new Xonotic" can't be as fast as "good old Xonotic", then most players will probably stuck at DarkPlaces just because of performance.

Many other things (gameplay, weapons, graphics, netcode etc.) are minor to me because liblast has already proven that it's possible to implement them in Godot.

(Damn, why did I spend three hours writing this post? I think I'll leave this topic and come back only when the first two items on the list above are resolved.)