r1ch.net forums
* Home Help Search Login Register
r1ch.net  |  r1ch.net stuff  |  R1Q2  |  OpenTDM  |  Topic: In-eyes spectator mode: how annoying would a required download be?
Poll
Question: How annoying would a required download be?
Too annoying, use the standard method
I don't mind but I'd rather it work without a download
It's fine but I would have to enable auto download
It's fine, I already have auto downloading enabled anyway

Pages: [1] 2  All
Print
Author Topic: In-eyes spectator mode: how annoying would a required download be?  (Read 21378 times)
R1CH
Administrator
Member

Posts: 2625



« on: September 01, 2007, 11:18:49 pm »

Most TDM mods 'in eyes' mode actually projects the view in front of the player to avoid the players' model from ruining the view. I have developed a technique to "hide" the player you are chasing, giving you a true exact view of what they are currently seeing, but it requires files on the client. If the files are not present, the grunt model will show instead, blocking most of the view. The new technique also prevents the occasional glitch where you see through the map or into a wall when chasing someone who is near a brush.

Depending on the outcome of this poll, I will either keep it like it is and require the download, or revert it to how other TDM mods work, with the benefit that if the download is present, you won't have occasional glitching where the model/weapon pops into the frame.

Screenshots showing the difference are available below
« Last Edit: September 02, 2007, 03:48:30 pm by R1CH » Logged
wision
Member

Posts: 237



« Reply #1 on: September 02, 2007, 05:50:39 am »

i think it's not a problem for most tdm players as we play only with male/female models and everybody got them.. would be nice to see a feature like that
Logged
Snake
Member

Posts: 184


« Reply #2 on: September 02, 2007, 06:18:56 am »

That depends on the size of the download.. But needing to download files is pretty common for mods, I wouldn't see it as a big problem.
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #3 on: September 02, 2007, 11:12:05 am »

i think it's not a problem for most tdm players as we play only with male/female models and everybody got them.. would be nice to see a feature like that
This is a separate download that no one will have. It's 15.7KB total, which shouldn't be too bad.
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #4 on: September 02, 2007, 03:36:30 pm »

Here are some screenshots showing the difference. First two are player/chaser in OSP, last two are player/chaser in OpenTDM with the download.


* quake008.png (1226.24 KB, 1440x900 - viewed 464 times.)

* quake009.png (1367.16 KB, 1440x900 - viewed 456 times.)

* quake000.png (1273.54 KB, 1440x900 - viewed 492 times.)

* quake001.png (1277.79 KB, 1440x900 - viewed 461 times.)
Logged
wision
Member

Posts: 237



« Reply #5 on: September 02, 2007, 06:15:00 pm »

would it be possible to get a weapon model visible?
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #6 on: September 02, 2007, 07:53:33 pm »

Vwep or hand weap (eg cl_gun)?

I found an unfortunate side effect of the technique used to hide players - the hidden player will always play grunt sounds Sad. I'm looking into workarounds for this at the moment.
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #7 on: September 03, 2007, 12:36:05 am »

Unfortunately most of the workaround are not viable. Using sounds directly would require copying male/female/cyborg/crakhor wavs, and if the user has customized sounds, would result in the wrong sounds playing. I attempted to use some configstring tomfoolery by referencing ../../ paths to the correct folder from the fake player, however this then causes the client to try checking and downloading a bunch of invalid paths. Currently, I have an extremely ugly system where configstrings are written directly to clients after connection to avoid the download / precache issues, however, this technique still fails as if the client is missing sounds, no sounds play at all instead of falling back to grunt.

I may end up abandoning this in-eyes project and just copying how it's done in OSP Sad.
Logged
wision
Member

Posts: 237



« Reply #8 on: September 03, 2007, 01:28:28 am »

ye.. cl_gun
:<
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #9 on: September 03, 2007, 01:32:28 am »

Well, I got it working flawlessly Smiley. I figured up a new way to handle sounds, the Game DLL does pseudo-processing of sounds (PVS/PHS calcs, etc) and then unicasts a single packet to the client consisting of a configstring, sound, configstring. One configstring reverts the player model momentarily to the original (never visible since an svc_frame is never received), the sound plays, then it goes back to the invisible model.

Only downside to this is the unfortunate requirement to have the PHS/PVS etc done in the Game DLL as opposed to using gi.sound. R1Q2's new server-side netcode does not respect packet ordering, making hacks like this impossible without manually writing a full packet. Whether this is a good or bad thing is your decision.... evil
Logged
[SkulleR]
Member

Posts: 7


« Reply #10 on: September 03, 2007, 04:21:07 pm »

I may suggest extending R1Q2 protocol to transmit current POV number along with player_state_t to compatible clients so they would know which entity is "first person" entity and hide it. I have already done this in context of Q2PRO protocol. As for incompatible clients, the server may just reset modelindex to zero on such entities on per-client basis, which appears to have no negative side effects in case of TDM.

Of course, this would require some sort of additional communication between the server and game DLL. Current POV number may be
embedded into gclient_t structure as an extra shared variable:
Code:
// game.h
struct gclient_s {
    player_state_t  ps;     // communicated by server to clients
    int             ping;
    int             clientNum; // current POV number

For the server to know clientNum is meaningful game DLL should export it's capabilities. Currenly I've implemented this by exporting the GetGameFeatures function from game DLL returning a bitmask of features supported by game DLL and taking a bitmask of features supported by the server:

Code:
// game.h
#define GAME_FEATURE_CLIENTNUM   1

// g_main.c
EXPORTED int GetGameFeatures( int features ) {
    serverFeatures = features;
    return GAME_FEATURE_CLIENTNUM;
}

Inside game DLL, you may just test if ( serverFeatures & GAME_FEATURE_CLIENTNUM ) != 0 and conditionally use proper in-eyes chasecam instead of that hacky projected view, provided you update client->clientNum correctly.

This way, no downloads are required by the client at all :)
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #11 on: September 03, 2007, 04:55:05 pm »

I had thought about extending the Game API, but decided I would try and work with the current state. Although, I guess at this point in Q2 history, anyone running an OpenTDM server would likely also be using a new engine that would support any new API anyway. Is there any real reason for the client to know the current POV number though? If the server can simply skip the entity, doesn't that have the same effect? Sending it to the client would involve a netcode change somewhere which is why I ask.
Logged
Zaltekk
Member

Posts: 17


« Reply #12 on: September 18, 2007, 12:01:48 pm »

Is it not possible to just add the RF_VIEWERMODEL flag to the entity being chased?  It should only be applied to the copy of the entity that is sent to the spectating viewing through that entity, but it doesn't sound any more complex than rendering it as a different model(which I assume is what you are doing, based on the need for a download).


Here is a reference from the Quake II source:
Code:
//cl_ents.c, line 1834 (lastest r1q2 build)
ent.flags |= RF_VIEWERMODEL; // only draw from mirrors
« Last Edit: September 18, 2007, 12:04:57 pm by Zaltekk » Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #13 on: September 18, 2007, 04:54:22 pm »

That would be nice, but Quake II doesn't support per-client entities like Quake III - anything applied to an entity is global and sent to every client.
Logged
Zaltekk
Member

Posts: 17


« Reply #14 on: September 18, 2007, 08:16:25 pm »

Then how are you pulling off this trick?  I must be missing something...
Logged
Pages: [1] 2  All
Print
r1ch.net  |  r1ch.net stuff  |  R1Q2  |  OpenTDM  |  Topic: In-eyes spectator mode: how annoying would a required download be?
Jump to:  

Powered by SMF 1.1.19 | SMF © 2013, Simple Machines