Announcement

Collapse
No announcement yet.

FTE QW engine.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • vibok
    replied
    Forethought Entertainment QuakeWorld, okay

    FTEQW - FTE QW (Fore Thought Entertainment) - That magical Quakeworld client. -- homepage

    By the way 2, this page FTE QW - QuakeWorld Wiki mentions wiki on fteqw.org, but this site is something unrelated now. What happened to that wiki, is content lost?

    EDIT: it's on the homepage too now, click "Wiki" at the left.

    Leave a comment:


  • Mugwump
    replied
    Originally posted by vibok View Post
    What FTE stands for, by the way?

    I guess you haven't bothered to visit the engine's homepage, have you? It's written in plain text in the header...

    Originally posted by Spike View Post
    or possibly just write some ssqc that allows rocket launchers to dig holes.
    Uhhh, while that would be totally awesomesauce, à la Red Faction, I wonder about the practicality of implementing something like that in Quake. From my limited tech knowledge POV, I don't see any other way than rebuilding each Quake map with AD breakables... which is probably a no-go for any sane person! If you ever manage to find a better way to do such a feature, I will to you forever and even possibly , even though I'm totally straight...

    Leave a comment:


  • vibok
    replied
    What FTE stands for, by the way?

    Leave a comment:


  • Spike
    replied
    @nahuel
    try this
    Code:
    r_part tr_grenade
    {
    	texture "textures/particles/myrtsmoke.tga"
    	tcoords 0 0 1 1 1 0 0
    	step 10
    	scale 32
    	scaledelta 64
    	alpha 0.2
    	die 2.5
    	randomvel 30
    	veladd 15
    	rgb 255 255 255
    	gravity -12
    	scalefactor 1
    	blend rtsmoke
    }
    @vibok
    'playdemo demo1' plays music for me.

    cl_run 1 with +speed will negate the effect of both. hurrah for q2isms.
    alternatively just set cl_movespeedkey to 0.5.
    FTE defaults to settings that are mostly achievable via the menus, so that mods that hack about with various cvar settings will still work properly, but yes cl_movespeedkey set to 0.5 would be a good idea for you.

    for me, all multimedia keys report an (extended) scan code of 0. this is consistent with eg sdl2. If you wish to try working around it, you can try checking the wParam instead.
    Really, if you want to handle multimedia keys then you should do it via WM_APPCOMMAND, because then you won't have some other background program changing volume too.

    also, its fte, not qte. I've no idea where you got that from, but you seem to be repeating it.

    Leave a comment:


  • vibok
    replied
    music doesn't seem to work in demos. I type "playdemo demo1", and it plays without music. It works on stages though. Just curious why is that.

    Would've been cool to make a run button an "unrun" button when always run is on. Quakespasm seems to do that, darkplaces and qte don't.

    qte thinks I'm pressing c when I'm decreasing volume. Just like in darkplaces. More details here http://quakeone.com/forums/quake-tal...tml#post176024

    Leave a comment:


  • nahuel
    replied
    Originally posted by Spike View Post
    @nahuel
    like this? http://triptohell.info/moodles/junk/...03052828-0.png
    technically those are merely lit sprites, but you can get the same result from particles with the same shader. That doesn't make it particuarly fast though.
    really awesome!!!

    any clue about the shader??
    how is possible to add a shader to a particle? via some script?

    Leave a comment:


  • Spike
    replied
    @nahuel
    like this? http://triptohell.info/moodles/junk/...03052828-0.png
    technically those are merely lit sprites, but you can get the same result from particles with the same shader. That doesn't make it particuarly fast though.

    Leave a comment:


  • nahuel
    replied
    @Spike

    Spike, I repeat my question because I had a dream where the particles in fte were affected by the lights Is this possible?

    Leave a comment:


  • trigram777
    replied
    Awesome, thanks again for the info. Maxdecals does work as expected, just needed a few extra zeroes in there

    And damn, I didn't even know FTEQW supported splitscreen. Gonna have to test that out extensively soon. And yep, using a button press to assign controllers makes sense, and it does work fine. Me only seeing it with the right trigger was a complicated issue involving how I had the controller mapped through Steam's xinput hook. Can confirm that all axes and buttons map correctly, and analog movement is perfect.

    Thanks again, man. FTEQW with the FBCA bot mod is just beyond solid. You've made an old pro-arena player very happy

    Leave a comment:


  • Spike
    replied
    maxdecals controls decal fragments rather than the actual decals, so if you have large decals then they'll clock up much more quickly than you might otherwise expect.
    Your remark about leaving permanent marks on quake maps makes me want to revisit my in-engine map editor stuff, or possibly just write some ssqc that allows rocket launchers to dig holes.


    regarding xinput, this is a splitscreen thing. Controllers are only enabled once you hit a button, which avoids USB's random ordering issue. Player 1 then player 2, etc. This also protects against poorly calibrated controllers that might otherwise cause your view to rotate constantly even when the user isn't trying to use them.
    Note that ANY button should activate it, supposedly, no idea how you're finding its only the right trigger - these are technically not even buttons, but fte simulates two extra buttons so you can bind the triggers to stuff if you want).

    joystick and in_xinput cvars are separate and distinct, in that they use two different APIs blindly without regard for whether the device is also present in the other api... The earlier API supports stuff that isn't trying to mimic xbox controllers, while xinput is much more precise about what the buttons on the thing actually represents, but as far as I'm aware there's no real way to figure out whether any single device is being reported by both APIs, nor which would be the best to use even if it was. So yes, you probably don't want both enabled at the same time.

    unfortunately this isn't something that I can really look into myself, as I don't have any kind of controller or joystick. All I can say is that the code should recognise ANY of the 16+2 buttons+triggers.

    Leave a comment:


  • trigram777
    replied
    Ah, thanks for the clarification, Spike. Figured I was using those terms incorrectly. I can confirm decals work perfectly with realtime lighting in 5084. FWIW, there still doesn't seem to be a way to get decals to stick permanently; even if I set both maxdecals and the 'die' setting in the particles cfg to huge values, decals still get cleaned up very quickly. Definitely not a big deal though, and I'd feel too silly pressing it as an issue. Just got some kinda neurotic need to leave my permanent mark on Quake maps

    I do have a legit bug submission, one that's been around for at least a year, albeit a very minor one. I use a Steam controller, and I can confirm that Xinput *can* work in FTEQW, but there's this weird little problem that took me ages to figure out. Basically, Xinput doesn't seem to initialize until you press the right analog trigger. Prior to pressing the right trigger, Xinput doesn't work at all -- no output from any axes. After pressing the right trigger, just once, Xinput will work perfectly from then on, unless you do a vid_restart. A very minor bug, considering that otherwise Xinput is fine (and is a surprising and well-appreciated feature), but a pretty tough one to get sorted out. In case it's helpful, assuming there's anyone else in the universe who plays Quake with a Steam controller, the way to get it to work in FTEQW is to disable "joystick" and enable "in_xinput" in the console, to keep in mind that the left thumbstick is mapped to joyadvaxis R and U, and always remember to press the right analog trigger at least once before you play

    You've probably heard this enough around here, but seriously thank you for FTEQW. It's just a freakin' behemoth of brilliant work.

    Leave a comment:


  • nahuel
    replied
    Originally posted by Spike View Post
    stains and decals are two different things. stains are a lightmap hack, while decals are glorified particles.
    is there a chance that particles knows information based on origin and lightmap or rtliight , with this particles will be affected by lights (as decals do)

    I know in dp some sprites can be affectecçd by lights usin a ! in the name of the file.

    This is possible in not-decals particles? is tooo heavy??

    Leave a comment:


  • Spike
    replied
    stains and decals are two different things. stains are a lightmap hack, while decals are glorified particles.

    because stains are a lightmap hack, they are naturally not visible any time that the lightmaps are not visible, hence why stains are invisible with rtlights.
    decals SHOULD be visible with rtlights, but I believe that I broke that recently. This should be fixed by SVN revision 5083.

    by default, stains fade over time in fte, but if you set r_stainfadeammount to 0 then they'll no longer fade if you're after that every-wall-is-bloodstained look.

    Leave a comment:


  • trigram777
    replied
    Long time lurker, first time poster. FTEQW has become my go-to Quake client, but there's a minor issue I'm having with decals/stains. All of this is using the "Haze" particle set, the QRP texture set w/ normals, and using the latest client (SVN 5077). It seems that stains (blood on the walls, bullet holes, rocket craters) don't work at all on my setup if realtime world lighting is enabled. They work fine with every other setting, but turning on realtime lighting causes all stains and decals to vanish. It also appears to cause some particle emissions to have wrong RGB values (blood particles look almost pink). Is there a setting to tweak this, or are stains not compatible with RT lighting?

    When stains do work, there seems to be a very low limit to how many can exist at the same time. I tried increasing both maxdecals and maxparticles in the console, but neither seem to affect the amount of blood/weapon stains supported. It's low enough that one gibbed monster produces too many blood stains and the engine starts removing them. In Darkplaces when you bump up the decal limit in the console, it does work as expected -- you can paint the whole level red and it'll keep up.

    I know this is totally silly and trivial, but if there's a way to make stains work with realtime lighting and support more of them at once, it'd be much appreciated.

    Leave a comment:


  • Mugwump
    replied
    @Crafter looks neat!

    Leave a comment:

Working...
X