Tekbot_CTF+ >> new server <<

[Cobalt]

Apparently if u change video modes, thats what will happen.

Still having issues with your hud code?

[xaGe]

Ok, so you only support certain resolutions? Or your saying if I play at 1440p and then next time I play at a different res it does this? That's 1366x768 above in the screenshot with the messed up stamina bar. The quake player mdl above the bar is always off, never above the stamina bar. The blue bar itself is only outside the border some resolutions not all, just the ones I use apparently.

[Mirrorman95]

That model is : chain.mdl and its in the tekbotctf.pk3 file under the progs folder.

Odd that its the only one failing to load. You should see this pk3 in the path if you type: path , into the console.

Its also possible the pk3 got corrupted on DL, so you can try deleting it, and DL it again via the direct web link in the instructions file, then place in dlcache, and retry.

I figured out the problem. I had an old tekbotctf.pk3 file from when I first entered the server back in 2013. I've downloaded the new one over it, and that should fix it.

[Cobalt]

Yep that would do it.

I figured out the problem. I had an old tekbotctf.pk3 file from when I first entered the server back in 2013. I've downloaded the new one over it, and that should fix it.

[Cobalt]

From what PrimalLove told me, this is a DP issue that needs addressing.

The sprint bar is a csqc type hud, and the csprogs.dat downloads, then initializes and grabs the video mode the engine is in. Once you change res in the game, there is no re-init.

I believe he says Spikes FTEqw has this issue resolved already.

For now this will have to wait until LH corrects it in the next build, if hes aware of it - Im not sure. Hes been hard to get a hold of.

Also, Primallove has told me that the mini-me Quake guy would be better off rendered as an entire new "scene". Right now hes technicly a client side only object, but he is more or less an active one, where light and other map area related things liek shadows would effect how hes rendered. If you notice, when you are swimming, he drifts l-r , which is because of the waterwarping views any object rendered while in underwater view has associated with it. An entire new scene will correct this.

Also I need to code in the level bar for the biosuit so it switches to that kind of rendering when the biosuit is activated.

So if you put the resolution in your DP command line that you wanna use while on the Tekbot server , IE:

-width 1024 -height 768 -32bpp

Ok, so you only support certain resolutions? Or your saying if I play at 1440p and then next time I play at a different res it does this? That's 1366x768 above in the screenshot with the messed up stamina bar. The quake player mdl above the bar is always off, never above the stamina bar. The blue bar itself is only outside the border some resolutions not all, just the ones I use apparently.

[LordHavoc]

The sprint bar is a csqc type hud, and the csprogs.dat downloads, then initializes and grabs the video mode the engine is in. Once you change res in the game, there is no re-init.

What do you mean? The current res is passed in as the two float params to CSQC_UpdateView. Spoike doesn't like mods reading the vid_width and vid_height cvars.

It's also possible to read the view property VF_SIZE at the start of CSQC_UpdateView.

[Cobalt]

Oh, Hi LH, thanks didnt see you posted.

Its been months since I worked on this csqc, but from what I recall there is routine called csqc_Init?

I am guessing this runs once as an initialize before the game starts. If I remember this is where it grabs the _width and _height vars you mention.

So unless there is a way to restart / re-init the csqc after that, and we decide to change video modes after this, the old values it grabbed would still be the same.

But yea, I suppose we could re-enforce those every frame in updateview, that would be a fix I believe, thanks...

The other stuff PrimalLove said about this problem happens to be identical to your solution, I just didnt realize it till now. But he also said :

".. yes, drawing the player model as we are doing will not work with this method. To fix the player model position you'll need to create a new scene and then you can move the scene around using the same above method screen postion multiplier. However, in DP for some reason its kinda borked. It draws an additional element that doesn't happen in FTE. That is the bug I was speaking about."

This is mostly in regard to the new mini-me Q player showing on the sprint bar hud Primal helped me with a while back. Turns out the waterwarip makes him sway l-r when we are swimming underwater.


Im not sure what this bug is, as I havent experimented with new scenes yet, but he seems to say Spike called it a bug when he spoke with him.

What do you mean? The current res is passed in as the two float params to CSQC_UpdateView. Spoike doesn't like mods reading the vid_width and vid_height cvars.

It's also possible to read the view property VF_SIZE at the start of CSQC_UpdateView.

[Spike]

I got name-dropped, so I'm going to clarify my stance.

vid_width and vid_height cvars should be avoided because they are unreliable. if you're running windowed and change the size of the window or whatever, those cvars won't change but the physical size will. if they're set to some video mode that would be invalid, the engine might use 640*480 instead or something (again, they would be wrong). or maybe the user is just changing those cvars just before changing video mods... in which case its wrong yet again.
ANY mod that uses vid_width and vid_height for the phyiscal size of the screen is buggy in some situation (the only exception is of course for a video menu).
unfortunately, DP somewhat mandates this when dealing with VF_MIN+VF_SIZE (as it uses physical size instead of virtual size). As LordHavoc said, you could theoretically work around it by querying the initial size, but this implies that viewsize is 120 (and/or other cvars to ensure the hud has no background covering the entire bottom part of the screen), and this would theoretically allow you to calculate the sizes the same for both fte+dp (cvar-willing, of course).
DP draws the hud *after* the rest of the screen and does not automatically restore VF_SIZE properly, so you *MUST* restore that corrently anyway (broken console etc otherwise).
This makes picture-in-picture type things like hud elements a game of whack-a-mole for the QC programmer. I don't follow DP that closely so I'm unsure if these are still issues or not.

vid_conwidth and vid_conheight are problematic. while it is possible for a mod to work perfectly in most situations, there comes a time when it really doesn't work very well. namely with widescreen resolutions. By expecting that those two cvars are always valid you require either that the engine does not support widescreen aspects by default(this doesn't exclude using the menu, but see issues with vid_width above), or that the engine completely overrides the user's preferences.
Calling cvar("vid_conwidth") and for height every frame is also inefficient. Theoretically you could just use autocvar_vid_conwidth to reduce the overheads, but its less desirable than the alternatives.
FTE fakes the float values of these two cvars in order to attain some level of compatibility with DP, but also generates a warning the first time either is read by the csprogs so that you know that the mod is basically buggy (you can use cvar_string to read the actual values, if needed). This of course means that I recommend that FTE users leave their vid_conwidth cvar set to 0, thereby allowing the engine to determine the correct virtual width based upon the vid_conheight setting.
ideally a mod *should* use the two arguments to CSQC_UpdateView in order to determine the virtual size of the screen. If those arguments specify that virtual size weirdly in relation to the physical size of the screen then quite possibly its because they either prefer using the wrong 2d aspect, or because their monitor has non-square pixels.
The catch to those two arguments is that they're only valid inside CSQC_UpdateView. This means that they're often not available inside CSQC_Init. On the plus side, this does help enforce the idea that the virtual/2d size CAN change mid-game.
In FTE, you can do:
vector virtualsize = (vector)getviewprop(VF_SCREENVSIZE);
vector physicalsizeinpixels = (vector)getviewprop(VF_SCREENPSIZE);
You can then do the extra maths to draw things to the pixel if needed (beware of non-square pixels). These should work in CSQC_Init too, but you should still be prepared for them to change mid-game.

At the end of the day, cvars are a minefield of dependancies and different defaults (and stupid users to some extent too, as well as configs from the wrong damn mods).
If you can avoid depending on them then you really should do so, this is unfortunately true for pretty much any cvar...

[Cobalt]

@ Gypsy - can you please make a PM to Spike with your question and delete your above post? I dont want this thread to wind up diverted into an "ask SPike" session. Its hard enough as it is getting support on my own, and finding people to test my mod. Thanks.

Oh and this is post #666 for me so look out !

[Cobalt]

Thanks to Spike and everyone for weighing in on the Hud Issue. Im working on it and its hopefully gonna be resolved soon.

Meanwhile, last Thursdays session was disappointing. So I gonna try Marks suggestion to move it from Thursdays to Sundays from 16:00 to 18:00 Pacific time.

Also he suggested I have some kind of plan going on for the session, so the beginning will be setup / helping any new people that are connecting for the first time, then some play and testing time , followed by a chillout break. Then some more playing time to finish up with feedback / comments or bugs found. I might also try to post a lighting config for Darkplaces for people to run so that the lighting looks more "darker" as I have noticed my mod's CD music tends to lend a darker atmosphere to Quake and the lighting settings I use for development might have alot to do with first impressions for new players.

[Cobalt]

Well this session was also pretty much a failure like last week. So I guess I am at a loss how to continue, I wont be interested in doing this with q1n anymore for a while. Im glad I got some support from them for a while anyway - back to the drawing board I guess.

[xaGe]

Just put my son, then my wife to bed so I'm free in a bit. If the server is up I'll jump on to see whats up. Did you resolve the hud issue?

[Cobalt]

Thanks man but Im bummed out by what happened tonight. When I loose interest in Quake , it seems to happen in a big way these days

I did some work on the hud so that almost all the resolutons are ok now , but the mini me guy still floats around during resolution changes, and Primallove has told me how to fix that, but I have not put it in yet.

Just put my son, then my wife to bed so I'm free in a bit. If the server is up I'll jump on to see whats up. Did you resolve the hud issue?

[xaGe]

There is no change in the stamina bar or outline position. Do I need to delete my config or something?




So other than that cosmetic thing there is still the previous issue with too thick of a smoke screen from explosions that it chokes DP and kills frame rate until it slowly passes.



Someone(PSP-Quaker(?)) actually joined the server for DM6 then a few seconds of the Shub's pit until the defeat from my shaft was too much to bear.

The few issues I saw are the same ones I've told you about previously many months ago. Although I did notice some player animations looked odd especially when carrying a flag.

Besides those its still fun and looks great on my setup.

[Cobalt]

Xage, sorry, I forgot to say I made the fixes to the stamina bar on my local copy, have not uploaded the changes to the server yet.

Yea the smoke particle thing has me stumped. At one point I had better looking smoke with alot less fps hit. Seemed to be with older Darkplaces versions when I was testing for it, but cant be sure.