Help with issues to get FTEQW to run on Linux for modding?

[Julius]

Bunch of minor issues fixed today. It's starting to become quite playable
The skybox and tranparency thing that worked in a .pk3 but not extracted was due to an error I made when extracting the .pk3... yeah that stupid

What I found odd is that animated textures via numbered .skin files (each includes for example "replace "v_proxy" "models/weapons/v_proxy-0.tga"" and so on) works fine for .md3 models, but not for .psk models.

It also seems like .png transparency works fine in the CSQC menu, but in map textures you have to use a q3 shader to get transparency. I guess this might be by design, but for rapid prototyping it's a bit annoying.

[Spike]

broken menu inputs is because of a denormalized-are-zero flag that the fpu is getting preconfigured with, which is breaking all the OP_AND instructions that vanilla qc depends upon. I've a workaround so it still works in this specific case, but I still need to make a proper fix so that other mods don't break.
In the meantime, -TFTE will fix it by allowing the qcc to use actual integer operations instead of trying to reuse floating point operators on ints (which is how come the denormalised floats flag matters).

opaque-by-default is required for q3 compat, and not doing it would break various q3 models. Plus changing the shader just because the texture data has a few different values is logically bad and makes optimising the engine a bit of a pain. Loading all the textures before generating the shaders would also increase load times as it would be much harder to thread it. Plus some formats make it hard to determine if an alpha channel is even present.
2d stuff has a default shader, and any images are generally displayed small enough that eating the cost of the extra blends isn't too much of an issue, especially when much of it is going to be blended anyway.
a func_model with alpha 0.99 or so will have transparency forced upon it in some hideous evil hack.

[Julius]

broken menu inputs is because of a denormalized-are-zero flag that the fpu is getting preconfigured with, which is breaking all the OP_AND instructions that vanilla qc depends upon. I've a workaround so it still works in this specific case, but I still need to make a proper fix so that other mods don't break.
In the meantime, -TFTE will fix it by allowing the qcc to use actual integer operations instead of trying to reuse floating point operators on ints (which is how come the denormalised floats flag matters).

I guess you are talking about the menusys input issue? So I need to compile the menu.src with some parameter ("-tfte"?). Sorry for being a bit dense regarding this
Looking forward to the proper fix though

P.S.: Regarding skeletal animations of .psk/.psa files: is it possible that this is handled a lot different in FTEQW than in DP? Because the DP code for the animation I have looks practically identical to the one for .md3 which I guess is a special feature of DP? So far the .psk models doen't really animate at all, only when initially switching to the weapon they are somewhat played.
I guess I'll try to convert them back to .md3 if that's easier, but having to remake the animations as the .psk/.psa don't properly import into Blender would kind of suck.

[Spike]

either:
fteqcc -srcfile menu.src -Tfte
or:
#pragma target FTE

.psa: FTE respects the framegroups defined by the .psa file. DP does not. Both engines can be made to behave the same by providing a .framegroups file, which provides you with a way to explicitly reorganise the various poses into new framegroups (or individual frames like dp, if each new frame[group] is redefined to be one pose long).

[Julius]

Awesome, in-commenting the already existing "#pragma target FTE" in the menusys menu.src file did indeed solve the menu input issues I had. Thanks a lot for finding this, as it was a major show-stopper for my alpha release target (soonish).

I'll try the .framegroups suggestion. Sound doable. I guess the structure should follow the animations outlined in the specific weapon's .qc file?

P.S.: I found older .md3 versions of the weapons in an earlier release that worked fine for the most part. And after editing all the .qc files and making sure the models get properly prechached, the animated textures also started working for these .md3s. Still a bit at a loss why I can't get it to work with the .psk models as the model format seems unrelated to the .skin files and the related SSQC code, but not really a major issue for now.

P.P.S: the muzzle-fash sprite placement code is really messy in the code-base I have, so I had to disable them for now. Is there an easier way like in Quake3 (with tags) that could be adapted instead? I guess the latter should work of course, some some kind of sample code for a code-abuser (mainly a 3D artist) like me would really help me understand it. (others than Spike can also answer, but the personal support Spike offers for FTEQW is really amazing and one of the reasons it should be preferred over the more or less unsupported DP engine... of course up to date documentation for FTEQW is another story... but I am not complaining ).

[Julius]

I seem to have gotten the .framegroups hack to work (wasn't quite sure based on Spikes short explanation how to do it).
So while normally the .framegroups code has this format:

firstframe numframes framerate loopflag e.g. 0 5 30 1 //starts at frame 0 goes for 5 frames with 30fps and loops

The Darkplaces compatible gamecode I have seems to like iterate through the frames itself as if it was a .md3 and thus the .framegroup compatibility hack for FTEQW looks like this (at least this seems to work for me):
1 1 30 0 // SHOTGUN_DRAW Frame1
2 1 30 0 // SHOTGUN_DRAW Frame2
3 1 30 0 // SHOTGUN_DRAW Frame3
4 1 30 0 // SHOTGUN_DRAW Frame4

So lots of "one frame" framegroups as Spike seems to have had in mind with what he wrote? Also The fps and loop flag seems to not have any effect?

Really not sure if that is the right way to do it, but it seems to show more or less correctly in the game.

[Julius]

Today I fixed most of the sound issues.

For other's reference:
FTEQW is much more strict regarding file extensions in the code. So what I had referenced a lot of XXX.wav files, while the actual files are XXX.ogg. This seems to work fine in DP, but not in FTEQW.

Its also a bit odd that for models you have to specify the full path, e.g. /models/weapons/xxx.md3, while for sounds it is only /weapons/xxx.ogg (actual path /sound/weapons/xxx.ogg). But this behavious seems to be the same in DP and FTEQW.

Last but not least, switching to .ogg files in the code made the FTEQCC compiler throw up a lot more warnings about missing prechaching sounds. I guess it checks if the files really exists and only then gives a warning, so before there was no actual xxx.wav so no warning for it?

[Spike]

Vanilla Quake added its own "sound/" prefix to sound names.
Automatic downloads follow the same rule, so mods trying to bypass that end up getting a bit annoying once a sound is downloaded. Its the same thing with extensions getting randomly swapped around. Ideally extension swapping should only be done for custom replacement content, for the same reason.
Unlike models, the original .wav format will be a higher quality than a compressed format like ogg, so trying to load inferior(albeit smaller) formats is kinda pointless.
But yeah, thanks to downloads, mods being lazy with their paths+extensions is not desirable (another reason to go with package downloads rather than misc files).

QC compilers read only the source/project files. They never read any content.
Or in other words, it isn't checking to see if your .wav files exist or anything.
If you're now getting warnings about precache_sound() vs sound() then its because its seeing a genuine mismatch.
However, fteqcc can only track immediate arguments to those two functions. If you're using a wrapper, or you're passing a variable in one of those places, then fteqcc can no longer 'see' that and will start warning about it being used without a precache or vice versa. you can either just make a wrapper for both sides instead of just one, or just outright disable the warning ( #pragma warning disable FOO4341 ).

[Julius]

Fixed a lot more minor issues, but the water .shaders gave me some headaches. It looks like the original "blendfunc" options don't works very well any more? After completly swapping out the shader with some newer DP sample code, I got it to work, but it looks a bit different from the original. But the "dp_water" function seems to work fine in FTEQW as well

I also tried some early tests with csqc HUD and in game menu code, but gave up for now after some engine crashes. Probably my fault assuming old code written for FTEQW would just work (I tried this: InsideQC Forums • View topic - Tutorial: CSQC GUI Menus )

But the original SSQC vote menu actually works fine, it only has the issue that it relies on the message log on screen, and I have not yet found the option to have it show more than 4 lines at a time as default in FTEQW (the vote menu needs 10 or so to show all the options).

Oh and I got CTF game mode to work. It is rather rudimentary in Transfusion, but works fine for the most part. However frikbot seems to not recognize the team-spawn points and probably doesn't understand the gametype as well. Is there a version that knows CTF that I could adapt?

[Spike]

regarding shaders, if you're copying shaders over from DP then expect them to be broken. DP's q3shader support is aproximate rather than any real 'best effort', while FTE is much more compliant. While there are good reasons for the DP's non-compliance, the implementation differences can bite FTE users far too easily. :/
there is some r_forceprogrammify (aka: dpcompat_makeshitup) cvar, which can be set to 2 to try to get FTE to ignore various parts of the shader as well as add extra texturemaps to it (like specular+fullbrights...). In an ideal world, you won't need to know about it.

I'm not sure what you mean by 'message log', I assume you mean what I know of as the 'console notify' lines that result from spamming the console?..
You can increase the maximum number of those lines with con_notifylines, but you're probably better off (ab)using centerprints instead, like everyone else does. They have better behaviour when you spam repeats to avoid timeout issues, and the number of lines is limited by the screen size rather than some annoying cvar.
In FTE, centerprints prefixed with "/P" are both persistent and have an opaque background so that you can actually read the text instead of having issues in noisy white areas.

Vanilla frikbot doesn't understand CTF rules, nor how to tell if its even enabled. choice of spawn points is NOT something that frikbot itself cares about, but rather that should be handled by your code instead.
frikbot should have some function somewhere where you can change the weights for various items or whatever. You should be able to assign a weight to flags so that the bot actually runs towards them, but I really don't remember if it'll be able to run for the flag/capture point while also trying to kill a player.

regarding engine crashes, run a debug build and let me know the build+address, especially if the mod you're trying to run is no longer available.

[nahuel]

Is there a version that knows CTF that I could adapt?

i did see a frikbot version with CTF time ago (in inside3d, now insideqc), i believe was done by Error

[Julius]

"con_notifylines" works, thanks. Yeah, probably I need to switch to another system sooner or later, but I guess I'll rather use a proper CSQC system then. I'll look into the engine crashes another time, seems not that urgent

Regarding the CTF bots... I did some searching on insideqc and it seems that the RMQ mod has an modified frikbot with CTF, I'll have to dig into the code here:
[remakequake] Index of /src

[Julius]

Ugg, the deeper I dig into the frikbot code, the more I notice how haphazardly it was bolted onto Transfusion... maybe I'll look into something else first

I tried setting up the FTEQW menusys code as a csprogs.dat, and while it compiles fine, it still needs the menu.dat to show the csqc menu and if I add the csprogs.dat it starts showing strange errors in the console about connecting to IPs and downloading files... That is a totally unaltered cspogs.src from the menusys code.

Also @Spike: have you thought about extending menusys to include a simple CSQC HUD also? As nice as EZhud is, it really is more geared towards quake mods, not stand-alone games (and the Transfusion gfx.wad doesn't play along with it very well ).
To me it looks like similar functions to the menu could also be used for a HUD, but I don't understand the code well enough to do it myself without at least some "skeleton code" in place.

Edit: Oh and in the menusys code, is there a way to change the mouse-coursor to a custom image instead of the "+" sign from the conchar.tga file?

[Spike]

csqc tries to download files from the server when you precache something that couldn't be loaded locally. menuqc doesn't, because it generally doesn't assume that its even connected. The server browser also depends upon downloading 'files' over http for q1 servers, just change com_protocolname to something other than quake and it'll no longer try. I've no idea why it would need to connect anywhere other than for that, unless if I left some test code somewhere... I do that a lot.

huds tend to not need lots of generic widgets but rather specialised things that hook directly into the game data, there's no mouse interaction etc either, so its generally much simpler to just write a few drawpic calls and call it done.

here's a crappy example that gives you something quake-like: https://sourceforge.net/p/fteqw/code.../src/cs/hud.qc
there's no scoreboard or fancy weapon flashing, but it should otherwise be okay.

for the cursor, there's some autocvar_cl_cursor variable that you can change in order to use an actual image, the '+' thing is just a fallback.