Raz0r

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.

Long story short; Q3 had support for 64 players, you just need to do a bit of tinkering in the engine to get things to (mostly) work with > 32 clients. I'm not sure how Jenova manages to do it without a client-side, I have never looked into it.

I might be late, but I ran into that issue in JA++ when people turned on forced anti-aliasing in their graphics drivers, mainly on ATI cards. Post-processing + forced MSAA + ATI = upside down screens. Go figure.

I tend to agree, I've refused 'donations'/incentive/payment for my coding work several times and find it ethically wrong to ask for, accept, or offer cash for an open and creative hobby like modding 10 year old games. I've gone the other way, releasing the source for the majority of my work and offering help to anyone who wants to learn. See: JACoders + modbase I haven't even mentioned the EULA or related issues, I'm speaking about respect, creativity and learning. Money does not contribute to any of these things. I'm not saying you can't do it, I'm saying you're a dick and I think less of you as a person for doing it. So, carry on if you will.

> implying i don't. > @@Astral Serpent code slave > @@redsaurus mac port slave Thanks for the feedback, and I'm always open to suggestions for future versions =] The server-side hasn't had nearly as much development, but expect the next versions to be impressive :3