Setting a client's maxspeed permanently and efficiently - Page 6

joaquimandrade · *Last edited by joaquimandrade; 06-26-2011 at 23:53.*

Can you give me an example of a compatibility case? I'm not reaching how if your plugin wants to set speed to 1000 all the time you can have other that changes the speed. If you give me a practical example I may be able to help. In terms of efficiency, if the speed you want to have doesn't not depend on the speed set by reset solution, 2 is always better. In the solution 1 you can check if speed was set to 1.0 to detect if player was blocked by freezetime (what keeps the code clean if you want to handle that situation)

FoxueR · 06-27-2011 , 01:03 Re: Setting a client's maxspeed permanently and efficiently

Personally, I'd prefer blocking it. This would operate closer to expectations when another plugin tries to set the player's speed after your plugin already has.

joaquimandrade · 06-29-2011 , 15:04 Re: Setting a client's maxspeed permanently and efficiently

Quote:

Originally Posted by FoxueR

Personally, I'd prefer blocking it. This would operate closer to expectations when another plugin tries to set the player's speed after your plugin already has.

Sorry but I'm not understanding what does blocking the reseting of the maxspeed has to do with other plugin changing the player speed.

FoxueR · 06-29-2011 , 18:54 Re: Setting a client's maxspeed permanently and efficiently

Quote:

Originally Posted by joaquimandrade

Sorry but I'm not understanding what does blocking the reseting of the maxspeed has to do with other plugin changing the player speed.

Imagine this sequence of events.

Your plugin ("Plugin A") sets a player's speed and now attempts to lock it at that.
"Plugin B" sets the player's speed.
Some event happens such that the game tries to reset the player's speed.

The behavior at this point will vary depending on which decision you made. If you decided to block the speed reset, then Plugin B's speed setting will still be active. If instead you overwrote the player's speed, Plugin A's speed will be active. It makes more intuitive sense that Plugin B's speed setting should remain active, since it came afterwards. While it may be Plugin B's responsibility to maintain the player's speed on its own, it may be prevented from doing so by Plugin A either setting the player's speed (i.e. it overwrites Plugin B's updated speed immediately after it is written) or blocking the event (i.e. Plugin B is never notified that the player's speed changed).

joaquimandrade · 06-29-2011 , 20:33 Re: Setting a client's maxspeed permanently and efficiently

Quote:

Originally Posted by FoxueR

Imagine this sequence of events.

Your plugin ("Plugin A") sets a player's speed and now attempts to lock it at that.
"Plugin B" sets the player's speed.
Some event happens such that the game tries to reset the player's speed.

The behavior at this point will vary depending on which decision you made. If you decided to block the speed reset, then Plugin B's speed setting will still be active. If instead you overwrote the player's speed, Plugin A's speed will be active. It makes more intuitive sense that Plugin B's speed setting should remain active, since it came afterwards. While it may be Plugin B's responsibility to maintain the player's speed on its own, it may be prevented from doing so by Plugin A either setting the player's speed (i.e. it overwrites Plugin B's updated speed immediately after it is written) or blocking the event (i.e. Plugin B is never notified that the player's speed changed).

Your explanation make sense! But I honestly don't think that the situations make. Because:

If what is wanted is that B speed becomes active, the first case works but then A is just used to block the maxspeed reset what is stupid because B should make it itself. By letting A doing it, it might not block it like B wants it to be. (Like B might not want it to have it blocked for some situation depending on a own var over players or like don't wanting it at freezetime).

If not, it is also wanted that B do not override's A and B will override A because the speed will be changed by B.

In more simple words: I don't think that it makes sense that two plugins handle concurrently the maxspeed or speed changes in practice. Maybe with an API plugin it would make more sense. Or maybe it's me seeing it wrong I don't know!

By the way, who are you that joined yesterday and are already talking like that?

FoxueR · 06-29-2011 , 20:56 Re: Setting a client's maxspeed permanently and efficiently

Quote:

Originally Posted by joaquimandrade

Your explanation make sense! But I honestly don't think that the situations make. Because:

If what is wanted is that B speed becomes active, the first case works but then A is just used to block the maxspeed reset what is stupid because B should make it itself. By letting A doing it, it might not block it like B wants it to be. (Like B might not want it to have it blocked for some situation depending on a own var over players or like don't wanting it at freezetime).

If not, it is also wanted that B do not override's A and B will override A because the speed will be changed by B.

In more simple words: I don't think that it makes sense that two plugins handle concurrently the maxspeed or speed changes in practice. Maybe with an API plugin it would make more sense. Or maybe it's me seeing it wrong I don't know!

By the way, who are you that joined yesterday and are already talking like that?

I agree, but I generally assume other plugins are dumb and are not written properly. It's a pretty fair assumption that, once a plugin sets a speed, it's unlikely to change it (other than to maintain it) when a game event that tries to reset it is fired. What you're saying makes both plugins more robust, but assumes things that are unlikely to happen. Either way, the best way to implement this whole thing is to have an API to handle it, like you said. I'd envision that the best way to do this would be to make a "set and forget" system where a plugin has to manually tell the API that it wants to set or undo its speed changes. Until it was undone, the API would try to maintain the speed setting it was instructed to.

ConnorMcLeod · 06-30-2011 , 02:05 Re: Setting a client's maxspeed permanently and efficiently

With an api you couldn't catch set_user_maxspeed, and also in counter strike all you have to do to set maxspeed is to change pev_maxspeed so you would need to continually check it in the api...

joaquimandrade · 06-30-2011 , 02:17 Re: Setting a client's maxspeed permanently and efficiently

Quote:

Originally Posted by ConnorMcLeod

With an api you couldn't catch set_user_maxspeed, and also in counter strike all you have to do to set maxspeed is to change pev_maxspeed so you would need to continually check it in the api...

The API would have to provide a wrapper for set maxspeed

FoxueR · 06-30-2011 , 11:08 Re: Setting a client's maxspeed permanently and efficiently

Quote:

Originally Posted by joaquimandrade

The API would have to provide a wrapper for set maxspeed

Exactly. It would be nearly impossible to enforce though, since any plugin that doesn't use the API but still sets speed in prethink or something would screw it up.

MeRcyLeZZ · 07-02-2011 , 16:32 Re: Setting a client's maxspeed permanently and efficiently

Quote:

Originally Posted by MeRcyLeZZ

2. Block ResetMaxSpeed (Normal hook):

Here we prevent the engine from changing player's maxspeed at all when custom speed is enabled:

UPDATE:
Found a bug in the second method. Even when blocking Ham_ResetMaxSpeed for a specific player, his maxspeed is still changed after planting C4. It's changed to 1.0 and the player won't be able to move after that! So I guess either try to handle this situation manually or use method #1 instead.