News | Forum | People | FAQ | Links | Search | Register | Log in
FTE Engine
This engine needs its own thread... also!

FTE's homepage:

This thread is for the discussion of using FTE's enhanced features, and/or drawbacks, for Quake level design/modding and/or gaming in general.

First | Previous | Next | Last
Glad to have the option for the physics and that was what I was trying to remember after all! I recall trying to make some very specific jumps to a very narrow ledge and slipping off a bit. I am so used to NQ with QS that it's extremely noticeable. I have quite a few jumping puzzles in the map I am testing.

mmmm thats bad how the lighting setting would need tweaking to look right in the first place for users .

I did some experiments with breakable furniture, i guess it dosnt look to bad when its not casting a shadow, the AO these new compilers have kinda helps it not look to shitty.

Its always fun to play with new toys tho, especially all the render option this one has, is there an FGD file for the entitys i wouldnt mind playing around with it. 
@Spike - Thanks For The Info 
I'm not concerned with DP, just wanted to know what translated that I already knew. This would simply be for FTE only mapping. 
.fdg files are a human-friendly and easily editable. It's very to edit a .fgd file to add what you want.

Beginner level mapping stuff, really. Open one and look. 
Great Job! 
Just wanted to say that r_softwarebanding is a seriously awesome feature, very similar to gl_tonemap=5 in GZDoom (

Just wish it would be ported to Quakespasm (maybe the "Spiked" fork?) someday. It's the only "feature" that's still missing from DOS/WinQuake.

On another note, how did you fix the texture seams when upscaling the HUD in Hexen 2? It's still broken in Hammer of Thyrion after all these years. Did you change GL_CLAMP to GL_CLAMP_TO_EDGE or what was it? 
Surprisingly Good 
I've heard positive things about FTE, so i decided to put it to the test. Not only did it load both really large maps shib3 and shib5, it performed really well, marginally better than Quakespasm. Of course FTE does have it's minor problems.

Many distant scenery had details missing, and there were odd holes in the cliff side wall. In addition, at some point transparent textures and static entities disappear. Could this be hitting an efrags limit?

Shib 5 had less visual issues, but more prominent ones. The mountains in the background disappear completely until you get fairly close to them, which you typically cannot do, so the scenery looks really bland.

Despite these visual defects, the maps themselves run fine with no gameplay issues

The other odd issue that can be game breaking is every so often, the player will just spontaneously warp to a completely different spot in the map, either inside or outside. It just happens randomly without rhyme or reason.

But despite these small setbacks, it appears to be a terrific engine with lots of customizable options to suit the needs of any players. 
Shib requires gl_farclip 256000, which FTE doesn't seem to support. 
all that jazz and no VR support?

these older games play really well in VR for some reason if VR is modded in correctly the new quakespasm sdl2 works great.

hacky injected forced VR however is poison 
Mirrors, True Rotation, Etc. 
Spike once said FTE has recursive mirrors. (99% on this).

FTE also has true rotation available and ericw-tools map compiling tools true rotation as an option. (To get the most out of true rotation -- like doors and drawbridges and such -- requires QuakeC, the Remake Quake game code QuakeC has that available ). 
Am I reading that right?

Just need to add RMQ's rotation QC code to a progs compile and all the pieces(ericw tools + progs + FTE) are in place for true rotation? 
Re: #17 
I already tested this so, it worked. No need for a reply.

Such an easy setup. Only downside left is the "choppiness" of the rotation. But every Quake rotation has this as well. 
That is correct. Should work in DarkPlaces as well. DarkPlaces also supports true rotation.

Rotation particularly is required for, say, func_door. You have to modify the door code.

As I understand it, it's probably a notch or 2 above novice level -- so if you are completely QuakeC clueless/coding adverse you'll either need to commit to doing a QuakeC tutorial or 2 to move yourself above novice --- or find a QuakeC literate friend and either bribe him/twist his arm to doing the task or helping you along the way.)

If you use something like WinMerge (a user-friendly file app to compare files or whole folders) to compare versus vanilla progs 1.06 source code to the below, you may find this useful as a start ... (ignore all the engine code on that page like world.c, sv_phys.c -- that ain't QuakeC).

Nothing about it is "hard". But will require a medium commitment to detail.

I, in fact, was quite newbie writing that tutorial and used WinMerge to extract the door rotation QuakeC from Avirox's source code. I doubt I understood much about the actual QuakeC -- but I didn't need to. Then I made a test map with Rubicon wad setting angle and such.

The QuakeC source is included with the sample map. 
Choppiness of the rotation should be able to be fixed. It needs higher precision angles.

I would expect that in DarkPlaces it may be smooth as silk because I believe DarkPlaces protocol 7 uses precise angles by default.

FTE may need some kind of "hint" to cause smooth angles.

I don't know how to do that.

Hopefully Spike notices your angle precision needs. FTE has protocol extensions (etc.), but I am not versed on those. 
You might be able to do "sv_protocol 999" in FTE. It may immediately resolve it if it is available, although if 999 is available in FTE, I'm not sure that FTE doesn't have something better available that would be a better choice in the long run. 
Spike can confirm, but I think it's "sv_bigcoords 1" 
Silly Me 
I had vsync enabled(hate screen tearing), it is smooth as silk now.

Thanks Eric, Baker, Spike and the RMQ peeps. 
gl_maxdist 0 will give you an infinite projection matrix, at the cost of depth precision.

@damage_inc / Baker
sv_bigcoords 1 is equivalent to sv_protocol 999, but also applies to fte's qw protocol too (and is required for the server to use dpp7, also).
this setting provides both 32bit coords and 16bit angles.
enabling vsync or setting cl_netfps lower, or making the thing rotate faster can avoid two sequential snapshots with the same angle (ie: the rotation periodically stops), giving better use of the precision that's already there. 
I'm not sure what that command has to do with what I described, considering its always on 0 by default. 
-lux Light Question 
Ok, I've been testing with this since I started this thread. Here's something I'm curious about.

I have a completely stock install of FTE making sure that these are set in my autoexec.cfg, and are working as intended:

gl_load24bit 1
gl_specular 1
r_glsl_offsetmapping 1
r_deluxemapping 1

Compiling, Light gets this:

-lux -extra4 "$bspdir/$file"

Nothing else, as far as the engine and the mapping, is changed for this test.

I am of course using some replacement textures each with normal maps and one including a specular map(floor).

My issue is, you know how we use "muzzle flash" from the weapons to light up dark areas? Or even just general rocket/grenade usage that lights up areas as well...

That doesn't seem to work for me mapping like this. Or it's inconsistent.

The dark areas most of the time just stay really dark(black/unlit) or... for no reason will light up occasionally and then stop again.

This of course looks strange.

Any thoughts on what I can do to correct this? 
I Tried To Screenshot It... 
... but no matter what window mode I select, FTE writes only a transparent image and my Windows "Print Screen" button seems disabled(?) as well!

Hope the info I provided is enough. 
I used OBS to record and grabbed images from video: 
How Deep The Rabbit Hole Goes ... 
rabbit holes, explore 2 or 3 with an advanced engine ... eventually ... you don't return at all.

Quake is successful because of the limitations (256 colors, etc.) and the many things you cannot do force an author to limit the scope of their project.

With an advanced engine, what starts as a project morphs into exploration drift -- then you find bugs or limitations.

I mention this because it is very uncommon to find a completed project that targeted DarkPlaces or FTE.

The specs of the project increase and increase, exponentially growing the labor hours required for the result --- until the number of labor hours passes the event horizon ... never to return.

A paradox ensues --- offering more capabilities dramatically increases the possibilities but decreases the probabilities.

So planned projects that plan to target the engine capabilities increase, but completed projects that actually do target the engine decrease --- usually to a specific number --> zero.

/Thought of the day 
Yes And No 
Having an engine with more advanced capabilities seems a dubious problem. Evidently there are projects built on UE4, CryEngine, Source, etc that do get completed.

Having the capability to mod the engine is IMO more of a problem. But blaming the engine is only half the story. Mod teams need to exercise discipline and restraint too. 
Limits Didn't Define Quake 
quake defined the limits higher.

This is accurate, in my limited experience. I have since imposed a set of limits on my project so that it will be coherent and actually make it to completion. IMO, setting limits was a great move both logistically and creatively. 
Weapon Bob In FTEQW 
Is it possible to change the weapon bob in FTEQW? Quake's default bob is annoying, the weapon just goes up and down, but it looks like it's stretching or some crap. Is it possible to change it to something like Doom, left and right?

I've noticed that DP has something similar:

FTE has cl_bob, cl_bobcycle, and cl_bobup. 
Fancy Weapon Movements 
If you're willing to write some CSQC code, you can just set cl_bob 0 and then implement whatever crazy viewmodel movements you want.

All you really need to do is avoid the MASK_VIEWMODELS flag in addentities and to then add an entity yourself using something like:

static entity ent;
if (!ent) ent = spawn();

The maths your mod uses are then entirely up to you.
(RF_VIEWMODEL is responsible for sticking the ent to the view, which avoids the need for matrix stuff, RF_DEPTHHACK messes around with the ent's projection to prevent it from poking through walls.)
(note that the above code lacks interpolation, its .frame2+.lerpfrac for that, but it makes examples messy. use .frame1time and frame2time if you want control over framegroups.)

Shpuld's TurboQuake mod is a good example of the value of csqc controlling viewmodels:
That said, its worth noting that using the vanilla content for it is more painful than it otherwise should be - like spinning the SNG barrel (read: spinning the entire model around a point which is not its origin). 
Where's FTE irc located at now?
The quakenet one listed at the site is empty, not even a bot in there.
I needed some assistance with FTE cvars and can't reach out it's chat hangout place, bummer. 
“also make sure you don't have both vid_conwidth+vid_conheight lingering from other engines - those other engines tend to have screwed aspect ratios. As a general rule you should only use ONE of them, with the other set to 0. “
true if the engine does console sizing correctly it will
autoadjust the height based on the proper
aspect ratio 
What's best place to find you for questions or documentation for FTE? Here? The Wiki seems pretty out of date. Is Sourceforge still the best place to report bugs?

5121 Win64 Dell Win10 laptop. I'm having keyboard input issues similar to buttons being held down. I confirmed the physical keys are fine and this behavior doesn't happen in other ports. I had changed some video settings prior to the issue. Restarting app had no effect. 
Is there any sane way to animate weapons and models from QC? Without having to tie frames and game logic and without having to declare each and every frame as a var and then as a function? 
Best way to poke me is generally via #qc, if I'm on. Or if you're on discord I got harassed into joining the Quakeworld one.

I don't know what would be up with the keyboard input. you could try toggling in_rawinput (followed by in_restart) which may or may not help, but I've not seen similar issues in the windows builds. I also don't use win10, but hey.

framegroups would be the obvious answer there.
however, animating with framegroups from ssqc is kinda messy as there's no way for the server to force a framegroup restart, which makes firing animations de-sync.
csqc has full control over the time into framegroups though, and because that's the answer to everything, you can use it to detect toggles of some bitflag and convert them into restarting whatever framegroup.
and if you're using csqc, you could also use it to position the various bones of eg an iqm via the skeletal objects extension, which allows things to spin independently of whatever animation they're otherwise meant to be playing, for smooth chainguns or whatever. 
Where i can find any examples of CSQC framegroups? Do they work normally with MDL and MD2? 
md2+md3 do not natively support framegroups, while mdl+iqm do.
csqc is quite explicit when it comes to animation, so there's about 5 fields that need to be updated each frame.
.frame+.frame2 define the two framegroups/animations to lerp between, eg when the animation changes.
.lerpfrac says how much of .frame2 to use (and thus how little of .frame to use). 0 uses excusively .frame, 1 uses exlusively .frame2, other values linearly interpolate.
.frame1time+.frame2time define the time into the two animations.

So, to switch from one animation to a new one, you copy .frame to .frame2 (and .frame1time to .frame2time), set .frame to the new animation (and .frame1time to 0), set .lerpfrac to 1, and then slowly decrement it over time (depending on how smooth you want the animation switch to be, probably lerpfrac=max(0,lerpfrac-frametime*10);
additionally, you need to increment both .frame1time and .frame2time by frametime. You can scale it or whatever if desired.

note that if you want to restart an animation, you will likely want to do it with lerpfrac (and .frame1==.frame2) instead of trivially resetting .frameNtime to 0, as this avoids sudden snaps.

when it comes to viewmodels, they're not really any different from any other entity. Just make sure MASK_VIEWMODELS isn't used, spawn a private entity with renderflags|=RF_VIEWMODEL|RF_DEPTHHACK, setmodelindex it to getstatf(STAT_WEAPONMODEL), and update its frame to getstat(STAT_WEAPONFRAME) as appropriate.
use some bit in the frame stat to signify animation restarts, and have the csqc restart the animation when its toggled by the ssqc or so.

So yeah, quite a bit of code that really needs some proper example code to fully understand. I don't really have easy-to-read code to link though, so I'm sorry about that. 
Thanks a lot for the information! I'll try to figure it out. Sounds very complex :D 
Does FTE support AD? The site says it doesn't, but I keep seeing people suggesting it... 
Should work for most AD maps. Might not work on sepulchre, swampy, or other megamaps. Spike can correct me, but I don't believe FTE has support for sv_protocol 999 even though it does support bsp2.

Spike could have done some updating though. I highly recommend he does since "can it play AD" seems to be the new standard for whether a Quake engine is "worthy" (initial AD release only specified Quakespasm as supported, leading to a lot of questions on other engines). Orl maps are a concern too since they are very very large as well. 
@idiot And @Qmaster 
use sv_bigcoords 1 for 999 maps (per Spike in a prior post in this thread) 
ad_sepulcher: worked okay last time I tried it.
ad_swampy: I really have no idea why anyone would think this map would have a problem.
999: sv_bigcoords 1; if its need isn't autodetected (if for some reason you want 999 specifically, also set cl_loopbackprotocol fitz;cl_nopext 1).

I'm not aware of any limits that are lower in FTE than QS, while I am aware of the reverse (even vs QSS).
That's not to say that there are no issues whatsoever, just that any issues are more likely to be due to qw-by-default player physics, or other such 'minor' incompatibilities that could affect ANY map...
And this is why you never fix what are obviously bugs. :(

But yeah, if I was aware of any issues with any of those maps that were mentioned, then I've either fixed them or just forgotten about them... Feel free to try them and shout at me should they somehow crash and burn. This is not a warranty - if it causes your computer to explode and destroy your entire city, then you probably shouldn't have been playing quake inside a nuclear reactor. or whatever. 
Any advancement on the control pad issue that myself and Kinn were experiencing? 
As I said in the other thread, I got PrimalLove to give me a list of changes on that front, which are now implemented in the latest build.
Most of it was just cvar changes, so you'll need to do 'cvarreset joy*' or to wipe that part of your config some other way. 
So... this is news for me... i've been playing quake with FTE for 6 months now and never experienced crackling sound :/ but when i play sm181_coce1 and sm181_coce2 i can hear some annoying cracklings... and if i go to "menu/audio options/restart sound" the cracklings stops, but if i load the map again, or just press F9, the crackling returns :(

Why is this happening? And why only in these two maps? :/ 
snd_restart doesn't restart static sounds.
there's a crackly static sound played near all wall torches.
I've no idea how you wouldn't have noticed that on other maps too though, maybe you've just been playing maps that use regular lights. 
I Suppose 
that in the first one the crackling comes from the torches, and in the second from light_fluoro or light_fluorospark (i don't remember which right now). But torches do a very different sound from the fluoro ... so maybe its another thing.

There is no logic gates or other sounds that repeat save the idle sounds from the enemies so it isn't from that, it can't be from performance as one is very open and the other took visibility seriously ... so I have no idea. 
Ok, i've made a video showing what i'm talking about =D

I choose "coce2" because it doesnt have torches, so there will be no mistake here ;)

After 00:27 you can hear the crackling sound. At 00:50 i restart the sound, and the crackling is gone, but the "wind" sound is gone too... So, at 01:30 i've loaded the map again to show that if you reload the map the crackling is back, and this time i fought some death-knights to prove that the crackling has nothing to do with the "wind" sound, since you can hear it when i'm fighting...

And at 02:15 i loaded the same map with quakespasm to show that there's no crackling sound in this engine.

But, as i said before, coce1 and coce2 are the only maps that i heard this annoying crackling ;) 
No Idea 
but it is not from my maps, as it isn't any of the sounds Quake does. I also used a completely clean install (just FTE.exe and the two .paks) of the game to check and heard none of that in any of the two maps so maybe it comes from your configuration.

What i noticed and will be interesting for the developer is something on coloured lighting: i have coloured lights everywhere on the map, but there is only one not coloured. It's values are 1 1 1 to make a very dark light, so i suppose that FTE misunderstood it as a light with values between 0-1 instead of 0-255 and made it pure white. Look back on the spawning point on skill 1 and you'll see it.

I also noticed that on default config hell_knight projectiles don't leave a trail. Rechecked it with E2M5 and the same happens so its not from my map. Gotta check which option puts that well. 
try using directsound instead of openal.
snd_device dsound
(or pick an explicit outpur driver+device via the menus)
or wasapi or sdl2 or alsa... etc...

this is the problem when there's a complete lack of standards.
you may wish to provide an .rtlights file with your map, so that the engine doesn't have to guess at all.

missing trail particles:
QS rounds up - particles get thicker at high framerates, making it harder to see enemies.
FTE rounds down - particles get thinner. This is consistent with other QW engines. Unfortunately they can get so thin that they become invisible...
I need to do something about this, I'm just not entirely sure what. The scripted particles do not have this issue (they have working distance tracking).
In the meantime, cl_maxfps 150 (or vsync), or 'r_particledesc high' will 'fix' it, assuming a lax definition of fix. 
Thank you!! Changing to directsound did the trick! =D 
what's the command to get q2-style noclip movement? (fly in direction you are looking). For some reason this keeps going away and I end up back with sucky vanilla noclip style 
#57, Kinn 
that's nq player physics for you. oh, so NOW you don't want it faithful! pah! :P
sv_nqplayerphysics 0 will give qw physics, which don't have that annoyance (yes, there are a few mods that depend on the vanilla behaviour, which just makes things messy). its default varies by preset, which is awkward. 
Hehe, well I don't consider noclip as "part of the game", so how that works can be as unfaithful as I like :}

Is there anywhere I can read about the differences in player physics between qw and nq, because it sounds pretty interesting, and is something that I've never really come across before, having been a single player all my life, and never actually played qw. 
Stunting the player experience is faithful!

Fucking hell. 
missing trail particles:
QS rounds up - particles get thicker at high framerates, making it harder to see enemies.
FTE rounds down - particles get thinner. This is consistent with other QW engines.

It's a little more complex than this.

If you run your favourite Quake engine at 20-30 fps - which is the best that most people would have been getting in 1996 - you'll see that the intended behaviour of particle trails is not a straight, continuous trail of particles, but actually a trail that drops "clumps" of particles at discrete intervals.

There was a .plan or something from Romero back in the day that exactly describes this effect, but I don't have a link to it handy.

So both NQ and QW are actually behaving incorrectly at higher framerates.

The correct way to "fix" particle trails is to track an "ent->oldtrailorigin"; if a certain timespan has passed (something between 1/20 and 1/36 seconds works good) drop a clump (using standard R_RocketTrail from ent->oldtrailorigin to ent->origin) and update oldtrailorigin from origin. Add in some reset behaviour for when a new ent is spawned or an existing one is culled, and you're done.

This way works consistently at any high framerate and doesn't excessively spam particles in timedemos either. 
Crunchy Piskels 
Ok, so I can set 3d filter mode to "nearest" and 2d filter mode to "nearest" to make the world and the HUD cruncky pixels, but is there a way to make the console / text pixelly? Currently it's blurry and the text has some line artifacts around it, which seem to be a result of the filtering.... 
Kinn: QW Physics Vs NQ Physics: Everything You Ever Wanted To Know 
Noice, cheers. 
Spike, Controller Question 
It's working much better now but I want to be able to rebind the controller, seems you can't do this in the quake menu?
Also look up/down on the right analog is inverted! How do I undo this? 
controller 'keys' are prefixed with GP_, you should be able to use argument autocompletion on the bind command for the full names.
their default actions are not listed in the menus on account of how I set up their defaults, but if you actually bind them (either via menu or console) then they'll appear in the menus. Note that fte only shows two keys per binding, rather than 3 or whatever.

to invert pitch, either set joypitchsensitivity -1 or so, or set 'joyadvaxisu lookdown' instead of lookup.
I don't recall if m_pitch affects it too. 
Cheers Spike. 
Will check this out at home 
doesnt show anything in the console for me.

setting joypitchsensitivity to a minus figure does correct the invert look though. 
Played a bit of deathmatch with my girlfriend. It works well, but rebinding is a huge faff. Would love to be able to do it easily in the menu (would also like to bind direct weapon impulses like in Quake 3) 
So... there's this game breaker bug with FTE when you can not get out of water sometimes... you can see in this video at 02:20

This happended to me a couple of times with other maps, but it never bothered me, because i can just start the map and play it again in quakespasm or markV... BUT, today i was thinking: what if this happen when i'm playing an episode with a lot of maps? I would have to go back all the way to the first map and play all the maps again :P

Surely i'm not the first one to notice this... is there something i can do to avoid this? some console command like "fix the get-out-of-water physics please"? XD 
Set Sv_nqplayerphysics To 1. 
Technical mumbojumbo gibberish:
NQ's waterjump distance is framerate dependant (due to a frame's delay - waterlevel is set from the frame before so is set despite the player being out of water that frame).
QuakeWorld's physics does not have this issue, thus there is no extra 'slop'.

sv_nqplayerphysics 1; can be used to switch to NQ physics for players.
(you can change it mid-game without any real issues, though it probably only matters for coop).
This also disables prediction (hence why its not enabled by default).
And remember that waterjump heights are still framerate dependant - you can increase waterjump heights by decreasing the framerate by increasing sv_mintic, but you should only need that in extreme cases.

Obviously this will affect other bits of player physics too, making all the various fancy jumps more like other nq engines too. 
Thank you very much, Spike =D

You're awesome =D 
What is the easiest way to implement blood splat in FTE? I mean, like these awesome dark red decals here:

These images are from a modification that Bloodshot12 made in particlefont.tga for Quake 1.5... Unfortunatly it is a darkplaces mod.

I know there's a way to do this changing the progs.dat, but i don't want to mess with progs.dat because i want the blood splat working with other mods, like DMSP2 and the official mission-packs =D

So, is there a easy way for me to do this or is too complicate? :P 
WebAssembly + WebRTC? 
Does the Emscripten build of FTEQW support WebAssembly and WebRTC for multiplayer? 
r_particledesc effectinfo is the lazy way.
you can also use r_converteffectinfo (iirc) to see what it would look like in fte's native particle syntax.
you can use r_part_redirect to rename a single existing effect to some other name, although this is usually only useful for weird people who want to mix multiple different effects without editing the particle configs.
FTE's embedded particle configs don't contain any decal effects on account of decals generally needing much high res artwork in order to look good. That said, if you use 'type cdecal' then you will get an effect that spawns as clipped decals, but you'll want to provide your own textures.

no, it doesn't use webassembly yet, though I imagine it wouldn't be too hard to update emscripten and tweak the compile flags in the makefile.

it does support webrtc, but only between itself, and it requires a broker to do so.
web server: sv_port_rtc rtc://BROKERADDRESS/GAMENAME
web client: connect rtc://BROKERADDRESS/GAMENAME
non-emscripten server: net_enable_webrtcbroker 1; sv_port_tcp BROKERPORT
(it is possible to omit the BROKERADDRESS args by including a usable value inside your site's fmf file, but you'll need a reliable broker for that.)

Otherwise you'd need to use websockets to connect to an existing server, eg 'connect ws://server:tcpport', but this only works for fte servers with both a tcp port open (controlled eg via sv_port_tcp) and net_enable_websockets set to 1. Alternatively fteqtv can be used as a proxy if you want a way to connect to any quakeworld server.

Installing game data from a public webserver is a copyright nightmare though. Users are meant to be able to provide their own additional game data by using drag+drop, which is of course annoying.
It is unfortunate that the paks need to be downloaded in their entirety, which makes downloads excessively large on account of all the maps which might not be played that session. 
Thank you very much for the info =D

Unfortunately i can't mess with the code right now, because it seems that is something wrong with my .NET frameworks :P Codeblocks+mingw refuses to compile any code (keeps asking for more and more *.h file) and Visual C++ 8 doesn't even install :P So, until i fix the .NET i'll stay away from the codes :(

But i downloaded the new version of FTE (5259)... this version doesn't support Hexen2 anymore? All i get when i click the file is a black screen with "Join Server/Options/Quit" :(

I think i'll stick with the old version for now =D 
Hi, it's me again

About Hexen2... How can i play music with FTE? I already put the ogg files in the "music" folder inside the DATA1 folder but it's not working, i copied the "music" folder to the main folder, and even created an ID1 folder but nothing seems to work :/ 
Forget about the post above.
The music works now =D 
It's me again!

I just noticed if i start the new version of FTE with "-hexen2" the game works :)

And now we don't have those annoying messages about "no-precache" on the top of the screen \o/

Thanks =D 
imho hexen2 is just generally too buggy without the mission pack, regardless of engine.
Note that if you rename the exe to fteh2mp.exe then it'll always try running the hexen2 missionpack, regardless of where its run from (unless given eg -quake on the commandline, or an fmf file, or just use -portals for it).
Assuming you actually have the mission pack, that'll fix a number of gamecode bugs that can get really annoying...
I also tend to test portals more often than the original game, tbh its been a long time since I tried.

Hexen2 has a serverside cvar to control the clientside music which I intentionally didn't mimic, and I don't have any midi playback code anyway so it never really mattered.
CD playback should work as in quake. Its just a shame that the midi music uses different tracks. 
I just tested renaming the exe to fteh2mp.exe... Now the "no-precaches" messages are back :P

I also notice that with the new version i can't gib the enemies' corpses anymore... with FTE 5121 i can gib them all :/ 
it's nice quake with moderate rag doll physics 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.