Restore vehicle framerate fixes (rapid stop) as toggleable glitch #4243
Conversation
|
The "defaultness" of this fix is debatable. Currently it's still backwards incompatible by default. How much this fix affect the gameplay? |
I believe it was discussed that only some race maps can be affected by this fix. Majority of servers and clients will never notice any issues / only improvements since this vehicle rapid stop (and slow turning in the air) is annoying at high FPS. |
|
Most if not all potentially affected servers already cap FPS limit to make race maps work properly. So I guess almost no one will be affected negatively. And in the long run many servers along with players will benefit from higher FPS limit when we remove "fps_limit=0" (or change 100 to something higher like 240 or 300). This option is unlikely to be used widely. Most server owners will prefer to fix affected maps and make FPS limit higher for clients to make gameplay smoother. |
|
sorry but its confusing abit, is this fix enabled by default? if so what about people who testing maps locally on map editor? or race locally or playing on outdated race/map editor? |
It will be enabled by default with option to disable it. This is how glitches work right now for similar things that can change gameplay. In Map Editor it will be enabled by default (and can be changed for some maps or all maps if server owner wants it, it's not hard to call one function). In my opinion all framerate fixes should be enabled by default (like existing fixes are implemented) for the benefit of all community. |
|
its not easy to fix a map based on 51 fps, we got around 10k maps using velocity/angular functions for example this map only works on velocity functions |
In this case for you it will be easier to disable these fixes for all maps. This is what this glitch is for. But if you already cap FPS limit to 51 then it will not make much difference even with fixes enabled. |
|
it will make a difference, i've tested the PR before, its worse than you think |
So disable it and keep default game behavior. This is why the decision was made to make the option to disable it. Also no offence but I don't see why some race servers should hold back the community back. Majority of players these days don't play on race servers and will greatly benefit from higher FPS limit without annoying issues. |
|
The thing is, i know how to call a function, but others can't, i've seen so many players can't even add a simple file to meta |
The players dont need to do anything, the server owners just need to turn this off (heck, let's change the main race resource and set the glitch to false in there if we are going to dumb it down even further). Yes, framerate fixes should be ON by default... the same way any fix should be enabled by default. We don't have cbug enabled by default just because it is used in some PvP servers Eitherway... this is a great fix |
If they can download a map from the internet and start it then I'm sure they can download a simple resource with this function call and start it as well. We can create a resource for this and include it in pack with default resources (I think it's not necessary but we can do this if there are concerns for some servers owners that don't know how to manager the server). |
thats what i meant, u gonna make things harder for players to disable this fix locally, not just server owners |
|
A function call isn't indeed something straightforward for many users(even server owners). So maybe there should be a default resource that enables some glitches. |
I am not understanding the issue. Do you mean players that will play on local private servers? We can always update the race resource to have this on by default. |
Making something like this optional for players can potentially lead to issues with vehicle synchronization or weird visual bugs and possible abuse. Things like this should be controlled by the server. |
yeah, but what about people that still uses 1.5 editor? or outdated race gamemode or a custom one |
Let me flip it on you, what about the rest of the playerbase (RP servers, freeroam servers...) that also have server owners that might not know about this change but they would gladly have the framerate issues fixed just with an MTA update? I think its a dumb argument, but then again if we must have backwards compatibility with everything then sure. Maybe we can compromise and enable this by default with 1.6.1? |
|
i would like to ask you to reconsider these changes as it would effectively ruin the work of thousands of mappers over the last 20 years, and the main hobby of hunderds (if not thousands) of still active players in the race and deathmatch community. my estimation is that there could be around 50000 deathmatch maps that have been made in the history of MTA, which would now effectively all become unplayable. there are still hundreds of us in an active community, working on maps and servers for all of us to enjoy. some of us have spent tens of thousands of hours of game time over the last decade building and shaping this (admittedly) small part of MTA. i understand that it's a bottleneck in the grand scheme of things, but im happy to give you more insight into whats going on behind the scenes and how much work is still being actively put into the community to convince you that its worth keeping alive. thanks |
This argument can be made for many different things introduced in MTA over the years that no longer work like it used to on latest build (including all existing framerate fixes). Any legitimate reason why it should hold back the community? There will be an option to disable it. It's not hard to update the server or download and start a simple resource if server owner can't edit one file and add one line. Ignorance shouldn't be encouraged.
So why not disable it? This is what this option is for. |
well thats the issue, this should be configurable, a way to control this fix, for example setting the fps to 51 instead of 25 |
Worst case scenario your server owners will have to add 1 line of code, or not even that and just install a resource. |
There is my guy, read the pr |
|
i know u can disable it, but we need the benefit from this PR too |
apologies if my message sounded more dramatic than it needed to be, I'm just skeptical about changes affecting the gameplay in such a big way. i think updating the race default to have the option disabled would be the way to go, assuming that it will properly restore the default behavior with no issues. id just like to stress that any potential change would have a bigger impact than you might think, so all i'm asking is that the devs think twice before moving forward. thanks guys |
|
We already have default resources like Maybe race community can come up with a list of features (properties) that normally changed on all race servers. Then we can combined it into a single resource and include it in default pack. I think even race community will benefit from this. It's time to update the server. And speaking about 1.5 servers (remind me if I'm wrong but you can't connect from 1.6 client to 1.5 server so what exactly is the concern here again?) |
|
What I dont get is why force server owners to activate the default behaviour and not force server ownser to actiavte the fix? Also will cause a lot of issues while mapping for race communities |
|
the problem with this fix is, its enabled by default, surely it will help you guys and all people will know about this, but still its going to break 30k~ maps yes i know its a simple call im not playing dumb, but im thinking what will happen if this PR will be enabled by default, many people will ask us why this happens, why that, why my map broke bla bla bla. not many players know how to add simple line of code in server side, you already guys seen this before i have no knowledge in C++ or what is the disadvantage of making this as value not something u toggle on and off |
|
New mta era 300 fps while half of players can't handle 51 fps stable :D |
On a contrary, majority of players don't play on race servers and will greatly benefit from this after regular client update. Most of big servers already set FPS limit to 74-100 and higher (the default limit right now 74). And it should be fixed by default along with other framerate fixes. This will allow us to raise default FPS limit to 240 or higher. In the long run it will provide smooth gameplay experience for everyone. Except for some race servers that will see less players playing if they don't do the same because many players already use high refresh rate monitors and will see a big difference between servers with high FPS limit and 51 or whatever you use. |
Because its a general fix that will improve the gameplay of everything but race/dm maps, and I would prefer for the majority of users to be able to enjoy it and possibly finally lift the default fps_limit to a value above 100. If the racing community is so passionated (which they are as seen with the misleading/fear mongering comments in this pr) they will figure out that if they are testing locally they need to enable the glitch, and server owners can just run 1 resource and have the fix enabled forever until the server closes.
Additionally, the glitch only needs to be activated once, you dont need to activate it per map, hence its not that the maps will break, is that the servers will "break" but alas, since we are always held back by the backwards compatibility, i guess that only a few server owners will actually use this (the same happens if im not mistaken with the uplift of the fps limit). |
true, but lets imagine a player made a map on this fix by accident, what this player can do? or for example playing on outdated stable resources that the player wont update because something broke in the recent updates? for example, editor 1.5.8 that people still uses in 1.6 |
Yes, this would be the main problem right here and most players are not really capable of changing that behaviour so it should use the default non-fix version otherwise bricking the work of that person if it decides to map for the racing community |
First, if they "made" a map using this fix nothing changes. The glitch is activated per server. If i make a map not using the glitch, the map wont just be broken forever, you can put it in your server and as long as the server has the glitch enabled the map will work. Its a flag in the engine. Now, if the issue is editing maps, the racing community has shown its passion already creating addons for the editor, but even then you would just need to turn ON the resource that enables this glitch, which is already possible with the editor. |
... which is a fraction of the players that play on race servers... and that's easily fixeable just by starting a resource |
|
its pointless to continue in this convo when im trying to give many examples on how this gonna break things up, in my opinion its it should be off by default and this PR finally getting merged |
There's some misunderstanding here, they're asking for a way to configure this rather than just disabling the fix and being stuck at ~51 FPS, they want to play at any FPS using the old vehicle physics so they can benefit from this fix as well. Also, I think it would be better if scripters could toggle this fix on the client side too since some servers run multiple gamemodes on the same server. |
If it's really just one line to change, then why not keep it as an optional feature for servers that want it, instead of enabling it by default? The last time a change was forced (like I understand this update helps in many ways, but it will also create confusion and cause issues for newly created maps in smaller gamemodes like race, especially if the race resource doesn't get updated with the fix. (if it automatically gets updated in servers using race then I don't see any issue with that) Most mapping server owners don't know how to edit server files, and they surely won't be aware of that change. They just want something that works out of the box. Is it really worth prioritizing 300 FPS at the cost of compatibility with the race gamemodes, especially considering many players are still on low-end PCs and monitors? Aside from that, I really respect the work you've done on this PR it's great. My only concern is the backward compatibility with other gamemodes like race. Whatever decision is made, I'll respect it. |
Ok but they can do that right (default current behavior)? Is there something that will inevitably break no matter what?
200% yes |
Then we should go with setWorldSpecialPropertyEnabled for this. This is what I wanted to do in the first place but there was a discussion on Discord about adding a new glitch for this instead of special property (so it could be controlled by the server only). Also this would make it easier for race server owners to disable these fixes without updating the server. So they can keep all existing scripts and just add one more (or one line) to disable changes on updated clients. I'd actually prefer this since it's easier to use. |
no? you needed to go out of your way to activate it (update server, add event... maybe server owners were lazy with the checks). I do believe that the exception shouldnt be the norm (most ppl dont play DM servers) |
|
What is the reasoning behind willing to shit on deathmatch community randomly without having a feedback? Remember when you pushed an update and the MGM servers went haywire just for that? All the maps are made on 51 fps, because the game's physics works well on those fps. If you raise the fps up, you risk having really shitty bugs overall. Just reconsider it, a solution would be as mentioned before having it off by default and letting the server owners choose whenever they want it on or not. |
|
oh sh*t, here we go again. |
By old vehicle physics do you mean the ones that this PR fixes? |
I mean keep the physics of cars as at 51 fps, but with a new fps |
They want the vehicle simulation to run at 51fps. Same as this fix but instead of 25 it being 51. Tederis said it should be possible to just add a function that sets the vehicle simulation to whichever framerate you want (25fps should still be the default because thats the intended simulation framerate). But I think this should be another issue entirely. |
|
The separation of physics framerate and rendering framerate is fairly common. But doing it in MTA would be complicated. However we can dynamically change the physics time steps so that physics get fixed at ~25 fps. This is what this fix doing generally, but with some corrections. |
|
OP assuming that every other major FPS related bug has already been fixed so he proposes to change the default fps limit to 100 or even higher. I understand that nowadays playing under 100 fps is a pain, but please understand that gta:sa is more than a 20 year old game which runs on an even older engine. I know that a bunch of fps related problems got fixed, but the game definitely has way more glitches than you can imagine. Most of them are not reported. Since racing is popular on MTA and fighting is not, there are not so many knowledge on how FPS alters the weapon and bullet physics and charachter animations. Trust me, there are a lot of aspects of it. Just to mention some: Animation cancels. Like crouchbug, quickstandbug, slidebug. These all are fps related as well. You can obviously use them on higher fps as well but not as simple. There are minor movement & other animation glitches which don't work on higher fps. The fandom finds new movement related glitches every year. These glitches - even if they are disabled - can still be used by other keypresses etc. which could be a problem on some servers. Some get unfair advantage on another. Or we can talk about insanely huge ammount of bullet consumption on certain weapons like minigun, extinguisher, spray can etc on higher fps. These are just two things. Even if we talk about vehicle physics there must be way more glitches than you know about. So I highly oppose the change of default fps limit. It should've been locked on 30 and let server owners decide. If MTA proposes 100 by default, server owners might think (just like OP) that every fps problem is fixed. If I'm not mistaken the current default is around 70 which is a joke. About the real subject: This glitch should be disabled by default not enabled. Let owners decide if they want this new thing or not. You would do more harm by enabling it as default. I would advise to contact some very committed people who are digging in the game code like almost every day. They are the source of our informations. Some speedrunner and others probably know way more problems of vehicle physics. This PR aims to fix some of these bugs but I doubt that only these exist, the best if you make very detailed tests on singleplayer and on mta in pararrel. Run both instances on 30/60 fps and even with this fix, you'll very likely find more problems. |
|
Bring back the Framerate physics project so these can be properly planned and documented. |
It's not that deep, no one is specifically pushing this kind of fixes just to disrupt your scene, all you care about is your own laziness. But besides you, there are other servers which could greatly benefit from it. For years MTA has suffered because of backwards compatibility being forced down the throat (if not blocked by that, it would be in better place today, both for developers & scripters), just because: server owner/scripter is lazy/not competent enough to change one line (at this point why you even own a server?), you act as it is end of the world, and there is no MTA community discord to receive help from. If only the one, who asked you to fearmonger put so much effort in adapting to a simple change... The fact you even dislike nearly ready to use solution by adding such line to default race (or new) resource is hilarious; you are the person who shit on developers trying to improve game for many, and in the same time offering you a helping hand - despite having such entitled attitude.
That's not true, majority of those bugs have been fixed since. |
|
Honestly, I think having a toggleable glitch is the most reasonable solution. I think the rest of the community shouldn't be held back by the racing community either, and even then, it's proposed as an optional feature, that way it can be disabled on the racing maps/gamemodes. |
|
I don't get you guys. I opposed the OP's opinion on changing the default fpslimit from 74 to higher. I don't know when it was changed to 74 but it was a bad idea. Increasing this even more in mtaserver.conf would be even a bigger problem. As a default value, MTA should stick with 30 fps. This game is 20+ years old with an engine which even more old than the game itself. Don't think that all fps related problems got fixed. Just to mention one, Spraycan, Extinguisher particles are invisible now thanks to that 74 fps limit. There are way more fps related bugs. A lot of them got fixed yes, but a lot of them aren't. Nobody holds back anyone, we just oppose the forced changes. All these years when something new got added into MTA it was always disabled by default so you had to add that into your server. Now this thing will be enabled by default and there's a high risk that it will ruin some servers. So why do you guys think, it would be a good idea to change this policy? The proper solution is to make this new glitch disabled by default and if you want it, just enable it.
Just let's reverse this. Why are you so lazy? You can't add that one line to enable it on your server? |
|
Thanks for the detailed reply, although I think there might be a small misunderstanding in what I was referring to; I was referring to the vehicle fps fix, not changing the default FPS limit value, which can be changed on mtaserver.conf afterwards.
You're suggesting a change in this policy by stating that it should be 30 fps too. If we're talking about bug free gameplay, 30 FPS would be more correct, yes, since it was the speed the game was originally intended to run, but it's a bit too low to be the default value in 2025, as most screens are 60Hz and basic hardware is capable of running this game at playable frame rates (But this isn't the issue, really).
If I may say, I find that attitude a bit rude, there's no need to attack; but your proposal is the same but backwards, and only benefits racing servers (and even then, it could be fixed with a single line of code too, as you're suggesting others do instead), discarding everyone else. Literally this PR proposes that exact same thing, but for enabling the glitch:
Which is the same exact thing you're suggesting, but backwards. This only changes the responsibility from racing servers to having others do it instead. Racing servers have a niche use for this glitch, specifically its side effects. It makes more sense for the servers that want to enable it, do so separately.
People with bad PCs wouldn't be affected either, since their frame rate wouldn't go any higher, thus they wouldn't encounter any issue anyway. This argument is a dead end. With this perspective, only people with good PCs are being punished, as people with bad PCs wouldn't be affected in either of these scenarios.
About changing the standard for servers with little knowledge about scripting: 74 FPS has been standard for a very long time, and changing the default limit to 30 would pose the same problem: it could break things too. And thus, the same issue happens again.
The reason 74 FPS was set as the default value was because it was the highest FPS value where there weren't many game breaking glitches, which at the time included not being able to move while aiming (a really important one, but that one's been fixed already), or dying from fall damage when climbing, just like when climbing the fence at the LS hospital or the short wall at Sweet's roof. It was a thought compromise, not a random arbitrary number (like the 51 fps mentioned before). Specifically, it was this PR, proposed by @Dutchman101:
Also, it's not bad to give flexibility to developers who are able to make use of the new features too. There's people who know how to script too, we can't just pretend they don't exist and give preference only to non-technical people, who wouldn't be aware of this either way. If anything, I've seen more non-technical people wondering when this bug will be fixed, not backwards. And, technical people tend to build more servers than non-technical people, who use to be players, for the most part. I think we're prioritizing the wrong target audience. I think prioritizing people who aren't able to use the changes that are being made shouldn't take so much of a weight on decision making, since they probably wouldn't use any of this, and non-technical people would probably be happier if everything "worked right out of the box" without any bugs or glitches, nevertheless. And even then, the people who want to keep this seem to only be from the racing community, which may be even considered a minority. If we go by the argument of player majority, one which I don't fully agree with, since we should consider everyone and not take a preference on a specific demographic, but for the sake of this argument, role-playing servers are more popular than racing servers, and they would benefit way more from this fix than racing servers. The default settings should be set for QoL of the average end user, yes, but these settings can be changed and improved to provide more ease of use; it happens all the time, as things use to change with time. Nevertheless, it's bad practice to prevent improvements from taking place when a solution for the reason it wasn't implemented first was provided, which is the case now. I think this fix should at least be added as a toggleable glitch, and not discarded again; there's no need to fight over this, most arguments against this don't really make a compelling argument (not wanting to enable it manually) or are unfounded. For example, it seems most opinions against this change in this thread seem to think the feature will be removed permanently, but it's not. |
Because it doesn't embrace ignorance or laziness. This direction should've been taken a long time ago. A good example would be past golden age of MTA's AC, where people being spoonfeeded for many years have shifted blame towards MTA for their bad (or mostly lack of) script security. Their disrespectful behavior & attitude resembles answers in this PR, what's more insane, they refused to adapt their code, even when having laid out solutions in front of their eyes (sounds familiar, what a coincidence), and continued to live in bubble, demanding MTA to take action, just to not move a finger. This is similar situation here, no amount of excuses will change that.
I am not, i wouldn't mind doing that at all. Contrary to you, and everyone else here being butthurt about such important fix enabled by default. By the way, i can also throw such statement, but lets twist it a bit: why newcomer, who doesn't know stuff here and there, should be locked to broken vehicle behavior when trying to enjoy game on higher FPS? The difference is that you, so called OGs (really? i expected more from you..) been here for a while — you could adjust it in blink of eye, but instead you decide to spend this entire time into exaggerated reaction. Others have to deal with random crashes, bugged functions for weeks, months or even years (sometimes even no fix at all) after updates, and yet here you are, with day one not hardcoded switch = race/deathmatch community most affected, end of the f****** world.
Perhaps, but that doesn't mean MTA should be blocked/gate keeped in any way - especially for such crucial fixes (or features; who knows how much MTA inevitably had lost due to backwards compatibility, due to people being so focused on themselves, at the cost of greater good), because they say so (sorry not sorry, you are not center of universe). At the very least, there could be announcement on DC regarding "vehicle_rapid_stop" being enabled by default, starting from version r232XX. Use this information however you like. |
|
In general, going by common sense, this is a bug, an unintended behavior exposed by the game. Going by that logic, it would make more sense to have it fixed by default and enabling the glitch separately, just like the other glitches, which follow the same logic and is, at this point, a convention. This is a glitch, and the setGlitchEnabled() function was created for these exact kind of situations. I don't see any compelling argument to not implement this, since that solution was sorted out with this very specific objective.
The setGlitchEnabled() function, at this point, could be considered a policy too, one that would be broken if an exception is made for this. As for the backwards compatibility for racing maps, it's not really an established policy, and it can be implemented without hurting anything, as it was proposed with an update to the racing resource and having the updated resource installed every time the server is opened for the first time, removing this issue completely.
I believe there's no need to fight or be overly aggressive over this subject, for neither side, but I have to agree on that specific point of view: features shouldn't be gatekeeped for such crucial fixes. As a reference, crouch bug is a bug too, which is highly favored in PvP servers, however, it's still a bug, which now has to be enabled manually per server. It would be the same case for racing servers. Why would there be an exception for racing game modes and not for the others? The same argument for backwards compatibility could have been done there. All PvP oriented servers that wanted to keep the crouch bug had to adapt and enable it manually (In my case, I experienced that firsthand), and it wasn't the end of the world nor difficult for those servers. It won't be for racing servers either. About the custom vehicle physics speed, that should be an entirely different issue, since it's a completely different subject, and a vehicle physics speed convention doesn't exist (like the 51 fps speed mentioned before). As far as the game is aware, the vehicle logic was meant to run at 25-30 fps, not 51; the effect from that was a side effect of this bug. If anything, it may be possible to attempt to implement it as a separate feature, but it's not what this fix is about; this practically just enables and disables that side effect. For example, if the maps that depend on angular functions want to keep the broken vehicle physics, then the glitch can be enabled again. It can't be easier than that. The same is done with every other single glitch that can be enabled with setGlitchEnabled(). All things considered, I support the option of enabling the vehicle framerate fixes by default, as it's by its own definition, a bug, and if the desired behavior is to bring the bug back, then it should be enabled with setGlitchEnabled(). If anything, this behavior would be more correct and would follow the glitch fix convention followed up until now. And, if wanted, the glitch could be enabled by default in a new update of the racing game mode official resource, so the issue that the racing community is basing this argument on gets solved. |
This glitch toggles vehicle framerate fixes reverted in #2787 (author: @Merlin) (false by default).
Vehicle rapid stop fix will be applied by default unless server restores original game behavior by calling: