Wirehead Studios

All Quake World fans should read this.  Mecha was very sad after he helped me discover this.  Look closely at what is going on in these pics:

(http://www.wireheadstudios.org/phoenix/pics/quakeworld/glqw01.jpg)
(http://www.wireheadstudios.org/phoenix/pics/quakeworld/glqw02.jpg)
(http://www.wireheadstudios.org/phoenix/pics/quakeworld/glqw03.jpg)


And mecha took these from software Quake World client for verification:


(http://www.wireheadstudios.org/phoenix/pics/quakeworld/swqw01.jpg)
(http://www.wireheadstudios.org/phoenix/pics/quakeworld/swqw02.jpg)
(http://www.wireheadstudios.org/phoenix/pics/quakeworld/swqw03.jpg)
(http://www.wireheadstudios.org/phoenix/pics/quakeworld/swqw04.jpg)

This was taken with the qwsv.exe version 2.30 running.  What you're seeing here is the Double-Barreled Shotgun's visible battern does NOT match the damage traces.  The pattern is clearly off the player, as far away as the staircase in the GL shots, yet the blood splats show the damage traces are hitting the player.  This means the source code I have for Quake World is correct, the SSG spread pattern in Quake World for damage traces is identical to the spread pattern in regular Quake.  The "super-tight" pattern is a rendering bug with the Quake World client.  This means Quake World has been lying to you all these years.  This is a sad thing.  It does explain much though, and it also means the Quake source provided by id is viable for use for all weapon functions and player physics.  It also means there will be no super-tight shotgun pattern for old-school mode, seeing that there never really was one in Quake World to begin with.

Interesting

Thats a real shame. slippy needed a distance weapon.

Hmm. upon seeing these shots, I also fear I will need to revisit my shotgun model :]

And you can see from Pho's software mode shots why I thought there were slits/holes in the barrels, right?

But anyway. This made me cry.

Yeah Mak, the skin is really odd there.. :]

Did the original Quake do that as well?  I can't remember.

The spread in normal Q1 -- single or internet play -- is visibly quite wide.

I believe the spred on the single barrel is narrow, while the short bird gun is wide.

Heres a composite shot with telejano:

does anyone else find it unusual that the blood splatters have a squared pattern too?  :surprise:

I think it's an overall problem with Quake World.  Quake DM and single player do not have the patterning problem.  For reference, the shotgun spread patterns are like so in the code:


I've snipped out everything irrelevant to spread patterns.  What it does is calles the "FireBullets" function, and sends pellet count, direction, and a vector for azimuth, elevation, and projection changes.   (That's horizontal, vertical, and front-to-back for those confused by the terminology)  Projection is "0" since it's kind of useless, so the first number is the "width", and the second number is the "height".  You can see the height is 2x for the Super Shotgun, and 3.5x for the width as compared to the regular shotgun.

That's the problem I was running into - the code was telling me the "super tight" pattern was dead wrong, so either the source code was wrong, or something else was wrong.  I was toying with the SSG and I noticed if I shot the ceiling and stood facing N, S, E, or W that the pattern was square, but if I shot NE, SE, NW, or SW it looked like a diamond.  This was telling me there was bad data involved since the pattern was aligning to world, and not relative to the projection vector.  I thought maybe the Quake World netcode was to blame, like it was snapping vectors down to 1 place of decimal precision, or doing some other bad float-to-int conversion that was losing the spread, so I got the crazy notion to see if the damage was async to the render, and sure enough, I blasted the wall next to mecha, and he got hurt.  We increased the distance, and the above screenies were the result.  This also explains why in one attempt at a Quake World game I blasted people repeatedly with the SSG  from a decent distance, and even though the pattern was square on them it did absolutely NOTHING in terms of hurting my opponents.

I've not looked into the netcode or client render code to determine if it's the server telling the client the wrong values, or if the server is sending the right values and the client is just drawing the pattern wrong.  I'm not out to fix Quake World bugs.  If someone wants to tell whoever's writing the newer Quake World revisions to fix this, be my guest.  It was enough for me to discover that the actual damage traces are right where the source code says they should be as far as Gen's functionality is concerned.  ;)

hi, just cross posting some info from quakeworld.nu forums for you guys


So the gunshot rendering doesn't match up exatly with the damage traces in QW because only 1 co-ordinate is sent instead of 14

cheers
oldman

Aye, but Quake 3 Arena uses one event transmission for multiple pellet impacts, and does not have problems with the patterns matching up.  Quake World clumps all the rendered pellet impacts in the same area.  I know the Q3 shotgun code inside out, and I was able to modify the shotgun code to cut down our Strogg Chaingun's netcode to 1/3 of what it would require to send 3 bullet traces the way Quake 2 does when it's firing 3 shots per function call at full speed.  It's a very useful trick.  I would then say that the problem with Quake World is that there is no seed for a spread pattern being sent with server transmission.  I can understand if they didn't know how to do that back when Quake was brand new, but I see no real excuse for it now in current Quake World ports except for simple oversight and/or laziness on the coder's part since the Quake III Arena game source has been available for at least 4 years now.  How hard can it be to create a simple function in Quake World for a seeded random to run on both client and server, and send the seed over to the client to replicate the pattern the way Q3 does?  Seriously, I've done harder things than that and made them work.  You should check out our modification to the Q3 BFG.  The particle blast uses no more netcode than firing one round from the machinegun does.  All the trajectories are virtual calculations that are replicated on both the client and server, and they remain perfectly synchronized.

i think it is likely to be a problem of not wanting to make changes to the QW protocol and/or not wanting to suffer the increased network overhead rather than "oversight and/or laziness" :)

oldman

Increased network overhead? Did you actually read what Phoenix wrote? O_o

It's possible to write the code in a way that it uses very little bandwidth. Our Q3BFG modification sends a crapload of particles flying through the air on impact, and it uses no more netcode than a single bullet fired from the Q3 machinegun. If this can be done by an "ameteur," it could certainly have been done by the professionals at Id Software.

there is a lot of muddledness in your post?

referring to the first paragraph which referred to my post, what i said (perhaps explained better) was that it has probably been looked in to and the options discounted.

the network overhead increase i mentioned was referring to the potentially simple fix of just using the netquake style, sending 'gunshot here' for every one of the pellets

and the fix you mention would (i believe) require changes to the protocol to allow the suggested synchronisation, which most qw developers are unwilling to do as it would break compatibility with e.g. the qizmo proxy often used for routing and large game spectating

in your second post you mention "it could certainly have been done by the professionals @ id"; at the time qw was being developed they probably didn't have the experience/technology (as phoenix points out) but we were discussing why no current qw engine amateur developers hadn't 'solved' the 'problem' and i believe this is for the reasons posted above - however it is still being discussed on qw.nu forums and i'll keep u updated :P

oldman

That is pathetic, why cant they fix a simple netcode problem instead of leaving it?

its not like its a major problem

sometimes the pellets that represent your missed bullets are slightly off from where they infact hit when they missed

its not like we have warping AWP shots :P

oldman

Sometimes the littlest things are a big problem. It looks like you hit the dude, so you assume you are causing damage. I wouldn't like to find out later it was a bug.

If QW players have been able to live with it ever since it was released it can't be all that big a problem, I'd say.

It's a lot easier to live with something when you don't know it's there.

Like the time when you walked around with a cucumber in your ear for weeks, because you didn't know it was there? :]

Yeah, like that.

At least, I would say that if that were true. :P

How many security flaws are in Windows that we're all "living with" because we don't know they're there?

You see, it has been a problem, particularly for me because I've had several very vocal Quake World players nagging me to implement the "tighter Quake World SSG spread pattern".  Well after playing Quake World online, being the complete noob that I am in regards to Quake World, I took them at their word, and wondered why my SSG blasts did zero damage to people at longer ranges even though the pattern was dead on them.  That kind of deception in game behavior may be a non-issue for die-hard, old-school Quake World players, but some of the people who wanted me to implement this pattern are die-hard, old-school Quake World players, and even they did not know this was a bug.  I could have wasted a lot of coding time trying to replicate a behavior that's the result of someone's bandwidth-saving hack.

I just nosed around the Quake source.  The problem is that Quake's multicast function only allows two pieces of information to be included:  a vector (origin point) and a MULTICAST_PVS value, which determines what clients should receive the event.  This is similar to Quake 3 Arena's temporary entity function, however Quake 3's temporary entity sends an actual entity that can have any entityState variables set that a normal entity can.  In order to do this, the multicast function would need to be able to send an extra integer and a direction vector in order to properly pattern the gun.  I don't know off the top of my head if you could cram that much into a Quake multicast message or not, it would require more research (including test compiling) than I'm interested in doing.

Thats too funny!  :)~
Point proven!  :thumb:

Authorative word


Which is pretty much as I suspected, protocol limitations currently soz :)

oldman

Or, the alternative would be to go ahead and use the extra bandwidth to send the additional pellet impacts.  We're not on 14.4 dialup anymore, but then again, I have no idea how efficient or inefficient Quake's netcode is.

I play QW quite often, and have NEVER noticed this before. I'm gonna be looking for it now, just to see.

Reading this thread hurt me. I've played QWTF for about 3 years.. retiring in 2000. I was always a HWGuy.. the supposed 'noob' class.

Being a HWGuy, I couldn't walk around while shooting my main weapon (TFC).. or wind up the barrels and walk around for easy insta-shooting (q3f). Shoot the assault cannon in QWTF and you're planted to the ground.. can't move or do anything else but aim. I'd insert a rant about those who called HWGuys noobs right here, but that's off topic.

I used the SSG and grenades for all dog fights.. until I felt it was time to whip out the cannon and finish the job.. or if the terrain was highly in my favor, then ok.

To sum everything up.. the weapon I've probably used the most in my QWTF carrer has been lying to me the entire time.. and I NEVER once noticed it. In all seriousness.. I did notice the shots not hit at extreme ranges.. but I felt that was added to help out with the rule of shotguns... bad at long range, better at close. So I thought there was some sort of 'maximum range' thing going on. (Which led to me using the single barrel against extreme range targets.. because I noticed that the problem was somewhat diminished when using this).