@necros
#1322 posted by ranger on 2014/10/21 04:19:37
fair enough lol
#1323 posted by ericw on 2014/10/21 04:44:27
ranger, the gl_info output looks ok, only thing i can suggest is try with a clean config if you haven't already. i've tested QS on the hd 4000 i think (recent-ish intel graphics, anyway) and IIRC it can handle even the largest releases like the rubicon pack decently.
I Got This Error
#1324 posted by dooomer on 2014/10/21 05:11:34
"gamedir should be a single directory name, not a path"
How to make the engine accept path (like addon/czg07) as valid argument for gamedir again?
@eric
#1325 posted by ranger on 2014/10/21 06:30:32
deleting the config did nothing
but removing the heapsize surfcachesize zone
args from the CL has removed the lag
#1326 posted by Joel B on 2014/10/23 18:59:53
Hey Baker, are you interested in refreshing the QS build in http://quakeone.com/proquake/Quakespasm_Steam_Easy_Install.exe ?
#1327 posted by Baker on 2014/10/23 20:24:23
Updated
#1328 posted by Joel B on 2014/10/23 23:47:10
Well that's service!
Bugs
#1329 posted by ranger on 2014/10/30 05:08:55
>Bugs
*sometimes the player gets stuck/stopped going down ramps/slopes
*sometimes the mouse randomly goes crazy and makes the camera spin wildly
*When loading maps digs05, digs06
the following appear in the console:
The anomaly
Using protocol 666
Couldn't find a cdrip for track 0
player entered the game
]map digs06
Client player removed
Warning: 40068 faces exceeds standard limit of 32767.
Warning: 48772 marksurfaces exceeds standard limit of 32767.
Warning: 36832 clipnodes exceeds standard limit of 32767.
Warning: 9667 visleafs exceeds standard limit of 8192.
Warning: 9394 byte signon buffer exceeds standard limit of 7998.
FITZQUAKE 0.85 SERVER (51103 CRC)
The Anomaly 2: Water
Using protocol 666
Warning: 370 models exceeds standard limit of 256.
Warning: 69 lightmaps exceeds standard limit of 64.
Couldn't find a cdrip for track 0
player entered the game
Warning: 913 edicts exceeds standard limit of 600.
*There is a lot of Z-fighting visible on maps
#1330 posted by Baker on 2014/10/30 10:02:15
*sometimes the player gets stuck/stopped going down ramps/slopes
Do you have host_maxfps above 72?
Frames per second above 72 will cause physics problems in most Quake engines in single player.
[Main exceptions: DarkPlaces and the last couple of version of DirectQ because they have framerate independent server and therefore physics. No Quakeworld engine (like FTEQW) would have this issue either.]
@ranger
#1331 posted by mh on 2014/10/30 12:44:20
I'm not presuming to speak on behalf of the QS devs but I do feel that this needs to be said.
You really shouldn't be reporting many of these things as bugs. If you actually read the text, you'll see that most of them are just simple notifications that standard Quake map limits are exceeded (which is OK because QS can support the higher limits) or that MP3 music is unavailable for the map you're loading.
These are not bugs.
Now, it could be argued (and I have done so in the past) that they shouldn't be displayed to players, but that aside, reporting them as bugs is just wasting people's time.
Regarding z-fighting, it was already dealt with before, and z-fighting is a content bug, not an engine bug. Again, bringing up an issue that's already been dealt with, and doing so without adding anything new to the discussion, is also wasting people's time.
I could add something here about one of the reasons why I bailed out of engine development being terminal annoyance at constant badgering of this nature, but - oh wait, I already have.
Continued
#1332 posted by ranger on 2014/10/31 07:26:36
>Bugs
*Not sure if it's a bug or a limitation, but models with an internal skin taller than 480 cause qs to crash... because qme allows models to have skins with a max height of 512
@mh
Actually it is a bug: the maps, esp the second map, lag in qs as well as interfere with the player's weapon anim lerp (due to the lag/overflow etc)
I don't know enough about zfighting but i believed that it could be solved via modifications to the renderer?
@baker
my host_maxfps is 72
#1333 posted by necros on 2014/10/31 17:32:45
Skins with max height of 480 is an original limitation of the engine. Width (as far as I know) has no limit though.
However...
#1334 posted by metlslime on 2014/10/31 19:40:16
why would a too-tall skin cause a crash? YOu'd think it would at least give an error message and quit to console, or even better, load it correctly but with a warning.
Mh:
#1335 posted by metlslime on 2014/10/31 19:44:18
Now, it could be argued (and I have done so in the past) that they shouldn't be displayed to players, but that aside, reporting them as bugs is just wasting people's time.
I see your perspective, but I felt that the warnings would be useless if they required Developer 1, since i don't think many mappers use that setting.
Visual Glitch In Jam3_mfx?
#1336 posted by Pekka on 2014/11/02 17:52:21
Quakespasm 0.90 has worked great and I've lately enjoyed playing jam3_mfx among other cool maps. However, I came across a minor issue, which I think is a visual glitch.
There is a room in the said map with four bloodfalls and a gib fountain dropping gibs into the center of the room. Two of the bloodfalls show the other bloodfalls when viewed through them, but since they are not otherwise transparent this seems a little off. The other two are not seethru at all.
http://imgur.com/Cy8wvUT
Here is a reduced-size screenshot which shows four images in one. The top and bottom ones show this effect, and the middle two ones do not. These four pics are all from different sides of the room.
As usual, I'm asking whether this happens to other QS users. I am using QS 0.90 compiled on Linux64 using SDL2 from the source release. The cmd-line options were -game jam3 and -heapsize 70000 (because I don't like typing numbers with five significant figures...)
Known Bug
#1337 posted by ericw on 2014/11/02 19:10:00
I think that's the lack of depth-sorting transparent surfaces (FitzQuake does the same.) It's on my list of stuff to fix in qs at some point :-)
the same glitch is visible in the Rubicon pack in a few places (the entrance slipgate of telefragged, the exit of the credits map).
#1338 posted by negke on 2014/11/03 18:51:57
Good example why fog should reset after each map: Jam 3 pack, playing Tronyn's level last.
#1339 posted by mh on 2014/11/03 20:33:21
The issue of fog is that getting the right balance between what players expect and what mappers want isn't easy.
If a player sets fog from the console and if it's cleared on a map transition they will probably report it as a bug.
If a map doesn't include a fog key in it's worldspawn as a way of indicating "no fog here, please", but if fog persists between maps, then it's also a reportable bug.
Mix in mods that send svc_fog messages (or stuffcmd it - bleagh) during gameplay and you've a mess.
This is a classic case of a feature that fights itself. As an engine coder you just can't win, and no matter what you do (or if you just say "what a clusterfuck" and don't implement fog at all) you'll have someone pissed at you.
#1340 posted by necros on 2014/11/03 20:42:45
fog should never have been a console option. wateralpha either, now I think about it.
But the feature was added before any mappers used it, so it didn't make sense at the time to make a feature that no one would see. I get it... but now players have a bizarre expectancy to be able to modify the way the map looks.
You wouldn't play Mass Effect and pull down the console so you could tweak the fog colour.
#1341 posted by JneeraZ on 2014/11/03 20:58:52
Agreed. The map should dictate the fog settings. No other option really makes sense. If the player wants to change the fog AFTER the map sets it the way it wants it, then that's fine. But the map should dictate what it starts at.
Fixed In Svn
#1342 posted by ericw on 2014/11/03 22:46:34
The bug was that on map changes, only the fog density was reset to 0. Now the rgb values are also reset to their defaults (0.3).
It's probably best to always specify all four density/r/g/b components in the worldspawn key; I just checked Darkplaces and jam3_tronyn.bsp gets black fog vs. gray in FitzQuake/QS.
Fog Fog Fog
#1343 posted by mh on 2014/11/03 23:06:38
In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.
I need to clarify that I'm not necessarily arguing in favour of the other perspective here: like I said, in principle I agree.
In practice what would be nicer to see is an agreed way out of this that involves both parties being able to have what they want; a way that lets mappers set their preferred fog settings (which could be no fog), that also lets players (and I'm primarily thinking of those who like to sex-up their Quake here, not that I necessarily agree with that mindset) set a fog that will persist over map changes, but that has a mapper-specified fog override a player-specified fog.
The major stumbling block here seems to be the convention of "no fog key in worldspawn = no fog".
Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.
I'd be interested in hearing that equally forceful argument, because so far I'm pretty sure it doesn't exist.
#1345 posted by necros on 2014/11/03 23:42:16
In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.
To this, I only ask what other game lets you go in and change things like skyboxes and fog that are integral to the look of the game.
If I ever release another map, I'll stuffcmd the fog and skybox every frame just to be a dick. :P
A Way Out
#1346 posted by Preach on 2014/11/04 00:55:17
A compromise proposal:
Fog has a "background state" which is only ever set by direct use of the fog cvar. The fog key in worldspawn is treated as a temporary override of the background state - once the map ends the background state is restored before the next map loads. Background state can be "no fog". If a fog command is issued during the map, this will not only produce an instantaneous change, but also update the background state to the given settings.
Result: on load, maps with fog keys look like the author intended. Maps without a fog key appear as the player sets fog by default (sober people: none, eyecandy freaks: lots).
Of course, info_command entities changing fog throw a spanner in the works. I can think of two unpleasant ways to work round that, but I will practice restraint and post neither...
|