FTEQW v5 wishlist

Discuss anything not covered by any of the other categories.
Post Reply
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

FTEQW v5 wishlist

Post by toneddu2000 »

Probably won't be even read by Spike or anyone else, probably it's stupid even think about it but I'll write anyway! :)
In the last 2 years I switched from dp to fte and I found an engine which it's not only a Quake engine, not anymore, it's a game engine on it's own. It's a real fun to create games with fteqw, as Shpuld demonstrate but, to me, there are several things I'd change now that FTEQW is at v4999.
  1. Delete all Quake related code(mdl,q1bsp,menu,game aspects, etc.). Yep, you Quake Folks, come on, hate me! :lol: No, seriously, it could be considered a plugin system to expand engine capabilities and think about a "Quake" plugin that includes all Quake stuff.
  2. Modular plugin system to show a very simple "core" and permits devs to create their particular plugin (see #1)
  3. Improving ssqc 2 csqc relationship (it's absurd that ssqc and csqc don't share world collision, models, nothing!). SSQC does only server stuff like score and enemies and CSQC handles EVERY client aspect. Engine should do the communication TRANSPARENTLY. No more sendevent, CSQC_Parse_Event, CSQC_Ent_Update and stuff. Just declare an entity is replicable. Like this

    Code: Select all

    void PlayerSpawn()
    {
    player = spawn();
    setmodel(player,"player.iqm");
    player.replicable = REPLICATE_CONTINUOUSLY;//this will trigger engine to make communicate ssqc and csqc continuosly to send every client every x seconds a replica of player .fields
    ..............
    }
    
    void BulletSpawn()
    {
    bullet = spawn;
    setmodel(bullet,"bullet.iqm");
    bullet.replicable = REPLICATE_ONCE_PVS;//this happen only once and replicated only to PVS players
    }
    
    In csqc you should be able to handle speed, movement, custom physics, weapon mechanism, etc. and this code SHOULD be automatically sent to server
  4. Improving CSQC. That means not asking yourself any 2 sec: "why the heck that other client is having my same weapon when I switch to next weapon? Why that player is aiming up when I move mouse up" and so on. CSQC should be the exact replica of client. Thats it. Whith a magic entity like "thisplayer" which is REALLY this player
  5. Improving csqc skeletal animations to make SIMPLY animation blending, animation looping, skeletal bone rotating, etc. Now it's a hard work, believe me

    Code: Select all

    if(player.velocity_x > 200){
    player.upper.animation = AN_FIRE;
    player.lower.animation = AN_RUN;
    }
    else{
    player.upper.animation = AN_FIRE;
    player.lower.animation = AN_IDLE;
    }
    
    also functions like Animation_PlayLoop(fistbone,lastbone,animname), Animation_PlayOnce(fistbone,lastbone,animname), Animation_Stop(fistbone,lastbone,animname) would be very cool
    
  6. Native Physics code (no more ODE, please). Probably GPL Doom3 Physics code could help, I dunno

    Code: Select all

    player.ragdoll = RAGDOLL_ACTIVE;
    self.ragdolltime = time + 2;
    player.ragdoll = RAGDOLL_INACTIVE;
    ..useless to say that ODE ragdolls are.. well let's just say are not usable! :)
    
  7. Librocket or similar implementation in engine (and builtins for quakec) for super simple UI creation (csqc UI are PAIN IN THE ***)
  8. Blender .blend file parser to avoid to use bsp for high detailed and organic levels (yeah, I know, no way it will happen! :) )
  9. Some sort of realtime GI rendering algorithm, like for example Voxel cone tracing algorithm
  10. GLSL is cool in fteqw but a better documentation will help. And quakec builtins would help too, for example, change on the fly a shader. Probably .forceshader does something similar?
  11. There are too many console commands. It'd be very cool if they were displayed in a menu, instead of alphabetically, in categories (INPUT, RENDERING, GAMEPLAY and so on)

    Probably there are a little more but right now I can find any other! Well, sorry to have wasted forums space but it was something I wanted to write for a looong time! :lol:
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: FTEQW v5 wishlist

Post by Spike »

q1 compat: what point is there in a quake engine without quake compat. the other problem is that while you can make a mod that doesn't care, getting a mod to the point where that stuff is irrelevant can take quite a while, and even if your finished mod isn't likely to ever use it, it can be very handy for bootstrapping your mod first. there are 'nocompat' builds which disable the stuff that I personally don't think are useful to others. there's a few other options that you can manually disable if you're compiling the engine yourself. too many combinations can be a real issue though, especially when it comes to describing what a specific build supports, which is why I generally try to avoid lots of different feature combos (other than renderers).

plugin system: actually, fte does have a plugin system already. its just not used for all that much right now. you CAN make plugins for new model or package formats, video decoders or encoders, etc, as well as various plugin-based UIs, but plugins tend to have additional maintainence costs (for both developing and for users - a proper installer helps for users, but also kinda defeats the point).

replication: it'd be nice to improbe this. sendentity is really quite awkward to use, it'd definitely be nice to be able to specify some list of fields that should be replicated and for it to just happen, but also quite fiddly. in the mean time, the deltalisten builtin can be used to replicate ssqc ents the easy way, but you're limited by the fields and precision of said fields.
you could also make a qc-based library to handle replication a little more automatically, but the whole SendFlags thing is still going to be inefficient.

csqc: if you're using stats and assuming that those stats apply to ALL players, then that's kinda your problem, not an engine limitation. stats are specific to the local player entity. if you want stuff about other players then use fields or even userinfo.
thisplayer = find(world, entnum, player_localentnum);
try that if you just want the local player. which can be world if nothing is known about it. obviously, 'self' is too messy when its changed randomly depending on which entity you're referring to at the time and has nothing to do with the local player.

animations: fte's csqc already has .baseframe .basebone etc if you want separate control over the upper+lower(base) part of a player. its more limited than the skeletal objects system of course, but it should still work to allow you to animate things separately with a single entity.
it'd be nice to add basebone+baseframe to ssqc too, but modifying protocols for something that I'm not sure would be used is not something I enjoy the sound of. either way, csqc animating things is the only way to solve the more annoying issues.
also, qc-based libraries would be handy here.

native physics engine: I did start to make a plugin to use bullet instead of ode, which was meant to make things more robust. I kinda got bored when it showed some of the same issues that ODE had, namely that its still possible for things to pass through walls.
writing my own physics engine isn't something I wish to subject myself to. I'm scared enough by FPU precision issues as it is.

ui libs: I've never heard of librocket, and I personally hate anything to do with the web. that said, I have been working on a libcef plugin which kinda does the same sort of thing. however its basically a complete web browser, and has annoying extra latencies. should still be usable for menus though.
alternatively, you can find my menusys library thing on fte's svn, in the quakec subdir. if I were to release a more friendly ui, this is what it would use for menus. it should be fairly straight forward once you get used to it, just try to avoid looking too deeply at first because the code is quite... err... distinct. yeah, lets go with distinct. certainly doesn't look much like anyone else's qc. :)

blender: gah. I've not looked in to it, but I would imagine that it would be a horrible overcomplicated format. importing .obj into a realtime-lit otherwise-empty world defined with just an .ent file is a much more realistic proposition. maybe it'll be usable one day, maybe it won't. in the mean time, try csaddon's terrain+brush editor.

gi: I doubt I'd be able to get it efficient enough to be usable, plus rewriting the renderer to cope with it is not something I currently feel comfortable with, as I'd probably get up before its even half complete.

shaders: you can remap shaders with some r_remapshader console command (the underlaying feature was required for q3 compat). this replaces the shader but not the material, so replacement shaders that still use $diffuse will still inherit the appropriate textures if you want to (ab)use it for an entire section of the map or whatever.

commands: in config files (including those saved with cfg_save_all set) will have nice groupings for the various cvars. otherwise you'll probably want to use either apropos if you want to search for some keyword in the name/descriptions, or just enter some grouping prefix (like in_ or r_ or sv_ and so on) and then use the auto-completion lists that the engine tries to suggest.

maybe stuff will improve with time, maybe improving it will break other things, or maybe I'll try to improve stuff, fail, give up, and take on easier stuff leaving those features never working.
time and motivation... gah.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: FTEQW v5 wishlist

Post by toneddu2000 »

q1 compat:
what point is there in a quake engine without quake compat.
It depends. The real question imo would be: "what is nowadays FTEQW? It's more a Quake engine or a game engine on its own?". If the winner is the first one, ok, q1 compat it's a must, otherwise considering developing a plugin only for q1 probably wouldn't be a bad idea
there are 'nocompat' builds which disable the stuff that I personally don't think are useful to others.
Yeah, and it's great, the problem is that there are issue with (mostly csqc phsyics) code ran with normal release instead of nocompat release. Because it's what I was trying to say. Now maybe FTEQW code it's too cluttered and too prone to errors because it takes in account maaaany quake mods, protocols, formats, and so on. Maybe it's not like this. I mean, I'm just a noob at programming and probably that's not the focal point! :)

plugin system: yeah, I saw it but I never understood how it works. Probably a small documentation could help developer who wants to know more about it

csqc:
if you're using stats and assuming that those stats apply to ALL players, then that's kinda your problem, not an engine limitation. stats are specific to the local player entity. if you want stuff about other players then use fields or even userinfo.
No, I use only .fields + sendevent and temp event + MSG_MULTICAST and, a lot of times, especially with players, things go as they shouldn't.
This is a comment I wrote in my ssqc weapon code that explains the problem(when I say " third person view" I mean the other player you see, NOT yourself):

Code: Select all

/* 
WARNING: don't know why, but, if you send the shot state for the player using a .field through SendEntity
the third person view player shot animation will work, but the first person view weapon animation will not.
If you send the shot state through CSQC_ParseEvent the first person view weapon animation will work
but third person view player shot animation will not. So, you're forced to send 2 different data, one
for FPV weapon and one for TPV player animation. Ugh..
*/
animations:
fte's csqc already has .baseframe .basebone etc if you want separate control over the upper+lower(base) part of a player. its more limited than the skeletal objects system of course, but it should still work to allow you to animate things separately with a single entity.
Yeah, it SHOULD. The problem with skeleton it's there isn't a working code anywhere. If you'd help me, I could create some sort of documentation, but we'd need (at least) 3 hours of chat continuosly while I'm doing all the tests. All by myself I'm always surronunding the problem without solving it. :cry:

native physics engine: Well, ODE it's a real problem, it's not only that objects go trough walls (never happened to me, must say, and I did a looooot of tests with ODE), the problem is that ragdoll are just "separated" objects from game world. So, it's a real mess to, for example, shoot dead bodies or to carry them(in a fast paced FPS could be a non-problem but in a stealth game it could be an obstacle)

ui libs:
alternatively, you can find my menusys library thing on fte's svn, in the quakec subdir. if I were to release a more friendly ui, this is what it would use for menus. it should be fairly straight forward once you get used to it, just try to avoid looking too deeply at first because the code is quite... err... distinct. yeah, lets go with distinct. certainly doesn't look much like anyone else's qc.
Yeah, let's say it's .. different!:) I mean, don't get me wrong, it's faboulous (OOP, classes in qc! :shock: ), but, frankly, without a robust documentation, I think it won't be usable. At least for me that I'm a noob in programming.

[OFFTOPIC]Important: remember me that we should have at some point a little chat about FTE multiprogs system. I'd like really to learn how to use it[/OFFTOPIC]

blender:Well, it could be the diamond peak of fteqw. Imagine: artists save the file and automatically engine parses all entities, portals, geometries. People Can FLy did the same for PainKiller (omg what a game..) and modding with that system was not only easy but a continuos fun! Imagine that with an open source engine...wooooooo!:)
in the mean time, try csaddon's terrain+brush editor.
But, is it working now? Last time I tried it didn't work and textures were not appliable.

gi: comeoooooon, don't make me pray you.. comeeeoonnn. Just make a little test, you're really a lot capable of handle it, comeeeeonn :biggrin:

shaders:
you can remap shaders with some r_remapshader console command (the underlaying feature was required for q3 compat). this replaces the shader but not the material, so replacement shaders that still use $diffuse will still inherit the appropriate textures if you want to (ab)use it for an entire section of the map or whatever.
Uhm.. no, not what I was thinking about.
I was thinking more about something that replaces shaders, INCLUDING materials.

commands: sorry Spike, I didn't understand! I mean, how commands are related to cfgs?
otherwise you'll probably want to use either apropos if you want to search for some keyword in the name/descriptions
didn't know about apropos, thanks! But, most of them are "no description".
or just enter some grouping prefix (like in_ or r_ or sv_ and so on) and then use the auto-completion lists that the engine tries to suggest.
Yeah I know that, the problem is, sometime, I remember the name of command but I don't remember which prefix is tied to! :)
Meadow Fun!! - my first commercial game, made with FTEQW game engine
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: FTEQW v5 wishlist

Post by toneddu2000 »

I forgot a feature request(using it, it popped in mind): OBJ collision importer in engine. For example I export 1 .OBJ file with 2 meshes: floor and floor_COLL. floor_COLL should be invisible in game and it should be used for collision(usually are very low poly objects). Sure, it could be used this system which I posted a long time ago, but it's overcomplicated and it doesn't work with multiplayer games(maps compiled with meshcollide flag will crash when launched by dedicated server).
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Post Reply