Quit complaining and do it then. It's clearly an important topic to many
people. If it's not important to you then add a filter. Stop trying to
force other people to your will. (Kind of like the tickrate issue...)
On Sep 23, 2012 12:20 PM, "haeufi" <[email protected]> wrote:

>  omfg! Please stop discussing about tickrate.... The actual state is that
> it´s variable and valve will only change this if THEY want and not if
> YOU/WE want! There is no success in discussing this! It just spams
> everyone´s mailboxes and you oversee important issues! I´m soon about
> adding a filter for this topic, because it isn´t even worth reading this
> stuff...
>
> So please please please please just stop this "spam"!
>
> Am 23.09.2012 16:10, schrieb Absurd Minds:
>
> Then they need to fix those issues. Locking tickrate is the lazy, harmful
> way out.
> On Sep 23, 2012 5:24 AM, "AnAkIn" <[email protected]> wrote:
>
>> Tickrate is probably causing issues with other things than just doors
>> anyway. In OB engine games it caused issues with weapon dropping
>> speed/distance, grenade/sticky bomb speed on TF2, etc...
>>
>>  2012/9/23 ics <[email protected]>
>>
>>>  The door fix in for nuke in CSS was phys_timescale 1.50 for tick 66
>>> before tickrate lock. The door movement is physics related so tick 100 on
>>> it simulated the door movement on much higher rate than like 66 but of
>>> course the door slowness is more noticeable with 128 now in CSGO. So
>>> basically, if this cvar existed in CSGO, fix would be phys_timescale 2.00
>>> for tick 128 but it would make every other physics object move faster.
>>>
>>> Now can we please shelf this conversation for a while.
>>>
>>> -ics
>>>
>>> 23.9.2012 4:13, Steven Hartland kirjoitti:
>>>
>>> Lets get something clear "It works, its just supposedly slower" = its
>>> broken.
>>>
>>> And how do you know it can be fixed without disabling 128 tick?
>>>
>>> I've not coded for source engine so don't know for sure, but based on
>>> others comments door timings in the engine are based on values which
>>> increment at the tickrate, so without decoupling the two or changing the
>>> way door timings are calculated then no you wont be able to fix simply the
>>> doors.
>>>
>>> For clarity as you seem to love jumping to conclusions, this doesn't
>>> mean it can't be fixed and still keep 128 tick, but just that its likely it
>>> will be a much harder job if you start having to change key parts of the
>>> engine to decouple things.
>>>
>>>     Regards
>>>     Steve
>>>
>>>
>>> ----- Original Message -----
>>> *From:* Travis Brown <[email protected]>
>>> *To:* [email protected]
>>> *Sent:* Friday, September 21, 2012 5:12 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
>>>
>>>  It works, its just supposedly slower. The door can be fixed without
>>> disabling 128 tick.
>>> On Sep 21, 2012 7:02 AM, "Steven Hartland" <[email protected]>
>>> wrote:
>>> >
>>> > The fact the door isn't working on only 128 tick servers isn't enough?
>>> >>
>>> >> ----- Original Message -----
>>> >> From: Travis Brown
>>> >> To: [email protected]
>>> >> Sent: Friday, September 21, 2012 2:36 AM
>>> >> 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.
>>> >
>>> >
>>> > ================================================
>>> > 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
>>>
>>>
>>> ================================================
>>> 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 
>>> [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
>>>
>>
>>
>>
>>  --
>> Best regards,
>> AnAkIn
>>
>>
>> _______________________________________________
>> Csgo_servers mailing list
>> [email protected]
>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>>
>
>
> _______________________________________________
> Csgo_servers mailing 
> [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