I just see your opinion and you linking to the valve wiki. Thats not proof.
Good try tho.
On Sep 21, 2012 7:01 AM, "Calvin Judy" <[email protected]> wrote:

> **
> That's absolutely not true, you just have not bothered to read this
> discussion well enough. I posted valid information 2 days ago, and then
> someone
> maliciously modified the wiki just to make the information look invalid.
>
> The wiki has since been restored without those messages added, there is no
> statement on there that says "higher tickrate improves hit registration."
> Someone maliciously added that yesterday.
>
> *Here's what I stated two days ago:*
> **
>  The higher the tickrate, the higher the *physics* calculations, which is
> why the door is moving slower. As Ido stated, they will be investigating
> the doors issue. But the arguement will continue to be "100/128 tickrate is
> better for competitive gaming, because it does more calculation." The
> problem is, it's physics calucation, like entities (the doors), NOT
> hitboxes/hit registration.
>
>  If you guys want to tweak settings to improve hit registration, start
> doing more research into the lag compensation part of the engine.
>
> https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_compensation
>
> **
>  As stated before you can verify what I'm saying about hitboxes with
> "sv_showimpacts" set to 1, which will show both client-side, and
> server-side hitboxes. (Change the tickrate between 33, 66, 100, and 128,
> the hitboxes are not dependant on the tickrate.)
> **
> What people percieve as tickrate causing hit registration issues is
> actually interpolation.
> https://developer.valvesoftware.com/wiki/Interpolation
>
> **
> To delve even further into the door issue, you may want to review entity
> interpolation, which is a direct effect of tickrate.
>
> https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Entity_interpolation
>
> **
> But entity interpolation and client interpolation are two very different
> areas, and changing the tickrate to something higher will not produce
> better "hit registration" results.
>
> --------------
>
> Either way, this arguement is getting tiresome, there's absolutely too
> many people on the mailing list who do not bother to read, or investigate
> issues, so they reply with something completely off the wall. (like absurd
> minds post about game server providers not hosting 128 tickrate because
> they don't want competition, which makes no sense in business.)
>
> If people want to run 128 Tickrate, that's fine, if people want to run 66
> Tickrate, that's fine also. But you should know there is no improved hit
> registration on 128 Tickrate.
>
> This arguement should be about getting people who rent servers educated,
> they should know when they're being screwed, they've been screwed quite a
> lot in the CS community
>
> Nuclear fallout is charging 14.99$/month extra just for 128 tickrate, when
> it costs about 1.5x more cpu to run.  This is the nonsense I'm pissed
> about, we've already had a representative of NFO Servers, come on the
> mailing list and say
> they can't verify whether 1000fps does ANYTHING additional for cients
> (which it doesn't), but they still market it for an additional 25$/month.
>
> *______________________________________
> Level 3 Technician
> Griffin Networks LLC - Gaming Solutions*
>
>
>
> ----- Original Message -----
> *From:* Travis Brown <[email protected]>
> *To:* [email protected]
> *Sent:* Thursday, September 20, 2012 9:36 PM
> *Subject:* Re: [Csgo_servers] 128 tickrate server makes door at de_nukeor
> de_nuke_se move slower than when it is @ 64 tick server
>
> All of these ppl saying no to high tickrates have yet to provide any proof
> of their argument.
> On Sep 20, 2012 8:58 PM, "Absurd Minds" <[email protected]> wrote:
>
>> There's no problem though. You're mindlessly forcing your will on
>> people for absolutely no reason. If you don't like 128 tick servers,
>> don't play in them. If you think people are complete and total idiots
>> for wanting to play in 128 tick servers, don't associate with them.
>> There is no reason to do anything else.
>>
>> On Thu, Sep 20, 2012 at 8:54 PM, Steven Hartland
>> <[email protected]> wrote:
>> > ----- Original Message ----- From: "Absurd Minds" <
>> [email protected]>
>> >
>> >
>> >> There is no reason to default to "the easiest" when you're trying to
>> >> create a high quality game. Saying, "it's just easier that way" is a
>> >> huge cop out and really shows everybody how lazy you are. Many people
>> >> want a higher tickrate. It doesn't matter what your opinion of them
>> >> is. You WILL disappoint people if you lock it, and if people would
>> >> rather deal with the issues than have a locked tickrate then why don't
>> >> you just keep your servers at 64 and let the rest of us do what we
>> >> please?
>> >
>> >
>> >
>> > Just because people will put up with broken stuff, doesn't mean they
>> > should, and just because people want it because they "think" its better
>> > doesn't mean it is ;-)
>> >
>> > People will get over disappointment, when they realise the game is
>> better
>> > for it, same happened for source same could happen for go.
>> >
>> > It was only recently that we had players insisting they absolutely MUST
>> > have CRT's to play CS and that TFT's where just unusable and would kill
>> > the game. Now look, everyone uses them and wouldn't think twice about
>> it.
>> >
>> > Perception is a massive part of gaming, and unfortunately gamers are all
>> > to quick to latch on to the latest and greatest without any real logic
>> > or proof.
>> >
>> > You can take any game and if its more consistent at a lower rate than
>> > the higher one, the game will play better for it. Inconsistency is
>> > a much worse problem then updates rates, and higher rates often causes
>> > more inconsistencies hence the "higher number is better" can easily fall
>> > flat on its face.
>> >
>> > If you want an interesting read / listen that includes real facts about
>> > the delays involved in gaming have go watch Carmac's keynote from this
>> > years quakecon, its got loads of juicy titbits in some that are quite
>> > relevant to this very conversation.
>> >
>> >    Regards
>> >    Steve
>> >
>> >
>> > ================================================
>> > This e.mail is private and confidential between Multiplay (UK) Ltd. and
>> the
>> > person or entity to whom it is addressed. In the event of misdirection,
>> the
>> > recipient is prohibited from using, copying, printing or otherwise
>> > disseminating it or any information contained in it.
>> > In the event of misdirection, illegible or incomplete transmission
>> please
>> > telephone +44 845 868 1337 <%2B44%20845%20868%201337>
>> > or return the E.mail to [email protected].
>> >
>> >
>> > _______________________________________________
>> > Csgo_servers mailing list
>> > [email protected]
>> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>>
>> _______________________________________________
>> Csgo_servers mailing list
>> [email protected]
>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>>
>  ------------------------------
>
> _______________________________________________
> Csgo_servers mailing list
> [email protected]
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>
>
> _______________________________________________
> Csgo_servers mailing list
> [email protected]
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>
_______________________________________________
Csgo_servers mailing list
[email protected]
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers

Reply via email to