A while ago spot lights had been discussed and it supposedly quite easy for Alex to add these in. I've found a good old Q2 tutorial on how to do it when it was still generating (lightmaps)[http://www.quake2.com/qworkshop/tutorials/lights.htm] tutorials

I'd suggest we add pointAt(target): targetname_of_other_ent. This way, regular light target can still perform triggering as it should. (It does in N&C).

Either way, this one is on our wish list which of course needs lightstyle support without a doubt.

As it stands, the networking can only handle so much. MTU limits are reached too often due to the transfers of high precision data(we could use quantization there, but it is not enough and can not be applied to every situation.).

Bitpacking is another idea to make use of. However ideally replacing the netchannels with a library that does the dirty job for us with regards to sending these packets around sounds like the most solid idea.

pt_showtris? Either way, same functionality. Supposedly already exists for sky surfaces, and can easily be extended. Happens to be I forgot where it resides exactly anyhow so... But it's a nice one to have around for mappers and for our own debugging reasons.

We'll create a light entity as per usual how things were done. We'll give it a lookAt entity target, custom color(since there is no surface it emits from, but perhaps it is do-able in both ways, also as a brush entity. So you can have spotlights like prisons have etc.)

Obviously the wish for it being able to have lightstyles would be really cool too.

Exactly as it says, got told to look at:

That's easy, you just need to fill the light_style bits of material_id of model's triangles in the instance_geometry shader
see get_material_info in vertex_buffer.h```

Would be great to have for the Polyhedron sphere and of course any other model object that you'd like to have emit similar light.

It'd be nice to be able to pick up guns and drop them again, or let's say, healthpacks, yeah, good!

Currently is controlled most often by the '/' key, however this should be done throughout the server instead. Perhaps there is room in configstrings, or we'd have to add some extra events. One way or the other, the server game has to rule over its domain where the sun may shine :)

These should only appear if, the game had a fresh boot. Or if a client disconnects and drops back into the mainmenu.

Having spoken to some in the Trenchbroom Discord, it's not that hard to be reknown as an official project in/for their releases.

In our case it'd mean having to implement a variety of this (which they said would be hard, but we aren't having all that Q3 shaders have nor do we need that in the editor to be displayed per se. Take a bit of a deeper look and you will see why they stated it was "hard".

With Q2 .wal being officially supported now, and that at least being our base to begin with regarding our own materials, it makes sense that this "PolyHedronMaterialParser.cpp" would parse those content and surface flags from the .mat Other than that, it only has to tell TB to load in a .tga

Now when it comes to .iqm support, I have no clue why nobody ever ever added that because it was quite easy for me to find some simple loading and rendering code for that... Here
] is a random one found on the web that I bet can quite easily be converted into a TB compatible loader implementation. Perhaps look at Md3Parser.cpp as a base.

I'm curious to hear your thoughts. Of course this isn't for milestone 0.4.0 per se, we haven't even finished the material system properly yet. But if they do not mind officially supporting us, and the editor being so well known etc, I think it's a great option to go for it.

First things first: Bigger picture goals.

What started out as a Q2RTX Fork, sadly never got to be what it had to be, an engine powering a Quake 1 sequel. So now what?

Work continues as per usual, setting out to solidify what we've got right now and patch it up to reach a usable and functional state. This'll require several things to be taken care of such as:

• Finish work on all the remaining entities to-do in the server game lib.
• Finish save/load and respawn related issues.
• Finish game modes by adding TypeInfo to them and getting rid of coop and deathmatch cvars respectively by replacing them with the already existing gamemode cvar.
• Clean up/Refactor several client game code.
• Refactor/Research net code to allow for more data to be transfered, perhaps by packet fragmenting.
• Interface all import/export functionalities of (game-)client/server import/export -structures.
• Update the code with all the latest updates that Q2RTX has had in the past time.
• Replace all basic content that is required to have a simple FPS with free content, rendering us independent from Quake 2 data, making this project a stand-alone afterwards. (Other than sharing the obvious which is parts of the code base.)
• Add a proper weapon system framework that's easy to work with. (Support for reloading, dual wielding etc.)
• Expand the material system as so to support it passing info to the server game and client game libs. Useful for footsteps, perhaps even custom friction and other game specific details on a per material basis.
• Add proper 2D rendering support for RmlUI.

This is the general gist of things that need to be done in order to actually be a usable piece of work again.

Future ideas/wishlist to research:

When all of the above is said and done, the goal is to get back on track with whichever ideas we got in the following list below:

• Proper start up that displays the logo of the current game project being ran in fade-in and -out fashion.
• Investigate and implement more functionality for IQM support.
• OPTIONAL: Perhaps see if adding in a certain physics engine is worth all the effort. It'd add quite a bunch of powerful features that are useful for designing proper gameplay elements.

... Feel free to suggest any features you'd like to see here yourself! ...

Current tasks being worked on:

Please note that these vary and are sub tasks of the latter above, all serving a "greater purpose".

• Fixing Client/Server respawn for single player(defaultgamemode) in the case of calling gamemap SAMEMAP again.
• Fixing Client/Server save/load for single player(defaultgamemode).
• BaseMover entities such as func_door, func_door_rotate, func_plat and func_rotate. (Half way there already.)

As the subject says.

Physics problem with misc_exploboxes and other stepmove entities for that matter. If/when stacked and one disappears, it tends to go boom and crash on us. Seems to be related to an out of order deletion of entities. As if the server entity goes out first, and leaves the classentity pointing to invalid memory.

It might be quite nice if we could add the option to be able to shove them off edges too. Right now it is only possible to do so on slopes/stairs.

We'll need to come up with a method that is as easy and little annoying as possible in order to have the game run as if it were back in the day, while still being 60hz.

For example, animations are currently stored as integers (ouch) and this becomes problematic, especially if game code depends on it. Like shooting 6 blaster bolts or so a second is really not good. (Looks funny though)

• Get viewbob and footsteps to work again.
• Get the network to play kindly with it again. Slightly related to #5

Currently weapons are still done the old-school method, and that does not sit too well. We'll need to see fit on how to modernize this.

Why, what for? Wasn't it already working in perfect shape?

The IQM format comes with a framerate value per animation, and in fact also a name. This framerate aspect is currently unintegrated and is almost a requirement to use in the case of N&C if we want to make things work more nicely with the game code again. If an animation is determined by an integral value and the Hz rate is 50... you can imagine that if all other weapon code which is in return strictly based on which frame you're at goes haywire.

Wished for/proposed solution would be that no matter the hz, it'll play the animation at the same speed. (Of course this would skip frames or just not work nicely at all in case there is a ridiculous high amount and the FPS can't take it, or visa versa.)

There are more reasons to want to have full support, because "as above isn't like below today":

The IQM format can be expended, it leaves room for devs to add in custom data by purpose. FTEQW engine has made great use of this, and in fact loading in what they then called a ".vvm" would be a piece of cake. A single extra structure containing a variable or two.

This specific structure was about model events, for example, when animation "shoot" gets executed, it'd fire a local game implemented event number resulting in cool effects. An example of such a .qc script can be seen here. v_pistol.qc

The other reason is that, should we use a head-torso-legs system like Q3 based engines do, or can we one way or the other integrate blending there? These few topics go beyond my reach on a code technical scale. (well I could do the head-torso-legs obviously but ...)

output v_pistol.vvm
materialprefix /textures/models/weapons/pistol/


origin 64 -20 -24
rotate 270 -90 0
scale 1.5

scene "iqe/v_pistol_muzzleflash.iqe" noanim 1 

scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "idle1" fps 30 start 168 end 196

event reset
    event 2 1337 "weapon_pistol.fire"
    event 2 1338 "muzzleflash1.vvm"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "attack1" fps 30 start 2 end 10

scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "attack2" fps 30 start 196 end 214

event reset
    event 10 1337 "weapon_pistol.reload"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "reload1" fps 30 start 10 end 56

event reset
    event 135 1337 "weapon_pistol.deploy"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "draw1" fps 30 start 135 end 167

event reset
    event 126 1337 "weapon_pistol.holster"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "holster1" fps 20 start 126 end 135

Examples of the file structure I used and the models themselves can be found here in my old SchizoMania project repository:

Notice how the names, the frame rate per second, and the specific frames out of the list in general to pick from can all be adjusted in these "scripts"? The workflow might be a bit time consuming, but it'll be our best bet at having nice animated characters, as well as nice animated weapons.

Keep in mind that for a bullet shell to pop out, it'd just take a certain event number, modelname, and any artist can actually take control over what shell, what sound, and at what frame this has to happen.

Right now we got IQM playing nicely, without blending (If I recall this would require Inverse Kinematics.), however it seems to lack the framerate aspect which is the highest priority right now. And of course, all the other things mentioned.

One final example of how I did the Zombie Character back in SchizoMania, it also mentions how animations can auto loop (unless of course ever the game code tells it to go play some other animation.)

output zombie_derrick.vvm
materialprefix /models/characters/zombie_derrick/

scene "iqe/tpose.iqe"

origin 0 0 0
rotate 0 -90 0


scene "iqe/agonizing.iqe" fps 30
scene "iqe/attack1.iqe" fps 55
scene "iqe/attack2.iqe" fps 30
scene "iqe/dying1.iqe" fps 30
scene "iqe/dying1_fast.iqe" fps 30
scene "iqe/dying2.iqe" fps 30
scene "iqe/dying2_fast.iqe" fps 30
scene "iqe/hit_react_a.iqe" fps 30
scene "iqe/hit_react_b.iqe" fps 30
scene "iqe/idle1.iqe" fps 30 loop
scene "iqe/idle_hunt.iqe" fps 30 loop
scene "iqe/idle_scratch.iqe" fps 30 loop
scene "iqe/running1.iqe" fps 30 loop
scene "iqe/scream.iqe" fps 30 loop
scene "iqe/turn_backface.iqe" fps 30 loop
scene "iqe/walking1.iqe" fps 35 loop
scene "iqe/walking2.iqe" fps 50 loop
scene "iqe/walking3.iqe" fps 30 loop

All of this resulted in a slightly slow and somewhat limited by toolset workflow, however given the advantages and the fact that the Quake communities do keep these tools up to date (Eihrul has his own iqmtool, and Blender export/import.) Where FTEQW has its own iqmtool as well with several other improvements.

Sources:

Source code to the engine Tesseract src, which is messy/tricky to read, you'll see the files soon enough. He goes over the top with a BIH, Ragdolls, no physics engine for it either. That is not our goal but it might help be a reference for loading in IQM data.

See whether we can make it fit in with the current .mat system. Seems logical to me to do so. This way, for example, a specific surface of a brush can have its own footstep style, or perhaps have them disabled. It is about control over such matters, decals for bullets that look different per material (we do not have them yet but still)

Other example would be how much friction it gives to the player movement.

There is little to be said about this.

This will be sort of a requirement given the amount of flexibility this library has. Let's say when a player gets damaged, it is able to do certain transformations/effects to the font(numbers) in the specific element.