Raz0r

I would suggest watching the Github issues, perhaps a Wiki could be made there. @@ensiform might even make a new repository, I'm not sure.

That wasn't an April Fools trick. Ziff Davis Media went bankrupt, FileFront was eventually acquired by Break Media

iD Tech 3 was ported. JA's fork of iD Tech 3 was not, nor is the source available for it. It could probably be done with iojamp, which is a jamp(ded).exe replacement based on ioquake3.

I bookmarked this page and visit it several times a day.

Yup

Don't just replace the files with modbase. You don't need the original SDK at all, that's what's causing issues.

http://store.steampowered.com/hwsurvey

Raven's SDK doesn't compile as it is. There will be a specific error message in the output box, probably the powf redefinition. I recommend using modbase anyway.

Ohai :>

hai :>

My thing is bigger than yours. And Inyri has two of them.

Desktop resolution: 1920x1200 Ingame resolutions: 1920x1080, 1632x1020, 1280x720

I'm pretty sure the OP means 'ghosting' as in 'I am certain my saber went through you but it did no damage, there is no such thing as a fixed time-step physics simulation, latency, or being plain wrong' Hence, idiocy and not understanding causes ghosting. The most effective method of reducing any visual inconsistencies (e.g. client simulating the saber's trajectory going through their opponent, but server not seeing the same data) is to increase your sv_fps to 40 or such. I recommend using non-fractional frame-time (ft = 1000/sv_fps). Default is 40, 25 or 20 should be fine. SP system has more advanced interpolation than the MP system, and doesn't suffer from low sv_fps as much. It has a totally different feel though. If you're running at a high sv_fps and people are still complaining about ghosting, they should probably find something better to do with their lives.

I would expect it was an experiment to re-implement the quad damage from q3, which still has relics in the MP code.

I think you're right. Slider has already been given the patch, but who knows how long it'll take to be added.

If you're looking at making , you'll want to get pugmod. Has a great camera system.

What causes ghosting? Idiocy for the most part.

._.

Hi, cheating is for baddies Is there any baddie eradication device? Greetings.

Ohai. Watch out for the alots.

What's the refresh rate and resolution? Pro gamers have been known to stick with CRT for a while but now with 120hz 16:9+ LCD monitors, and the benefits in every-day computer usage, LCD is probably the way to go. If you have the money. CRT works. LCD works. If your CRT works and you don't mind it, you probably don't have to fork out over a new monitor.

I think I discovered this around 2005 xD

Default com_maxFPS is 85. 1000 / 85 = 11.76 msec Cast to integer = 11 1000/11 = 90.90 FPS (cast to integer, so HUD shows 90) They really should have used 125 com_maxFPS, so the frametime is nice and non-fractional (8.00) - and roughly in sync with your refresh rate. Personally, I reworked com_maxFPS in my q3-based game to com_frametime, measured in whole milliseconds (non-fractional) Technically, the 'FPS' does not matter. The only thing that matters from the engine's perspective is the frametime - which is expressed as FPS (1000/frametime) on the HUD.

Yes, the physics is affected by the client frame-rate: particularly gravity and air control. Physics calculations use frametime (in msec) and there are funky calculation errors that help you gain speed and fall slower. AFAIK the issue lies in truncating floating point values to integers each physics frame - which will have different results depending on the frametime. 8 msec = 125 fps, most common for trick jumpers and strafers. Standard physics FPS for CPMA, DeFRaG, etc. It's just over double the default refresh rate, so it looks very smooth too. 11.111 msec = 90 fps, used for very short jumps 3.333 msec = 333 fps, used for very long jumps. Most players can't reach this FPS, and if they can, they'll likely run into "connection interrupted" unless they live close to the server. I never liked that config tweaking guide. The author doesn't understand half of what they're talking about, nor do they focus on the bottlenecks. (PS: FPS above 60 does matter, especially in scenes with high motion, or if you want responsive input (60 fps = ~16msec between input/mouse updates, 125 fps = 8 msec between input/mouse updates) V-sync simply is not an option due to the unresponsiveness between input and display.

Started toying with JA's assets around 2004. Then I found coffee. Now I'm a programmer.