Mods are now organized as resources. Use the Mods link above to browse for or submit a mod, tool, or prefab.
The TFP Official Modding Forum Policy establishes the rules and guidelines for mod creators and mod users.
I would assume he means the server fps, which you can change with a console command.Huh? Is that even a thing? Since when do servers control the clients FPS?
Honestly, I feel the same way. Though, through my experiences with this game and some others. Servers sometimes use "FPS" as a metric instead of Tick. To this day, I still find this confusing.Wouldn't that be called tps (ticks per second)? I mean... frames per second requires displayed images per second.
It's how Alloc explained it; basically the servers heartbeat. I don't believe changing it accomplishes anything. Like, at all.Wouldn't that be called tps (ticks per second)? I mean... frames per second requires displayed images per second.
Maybe it just helps burn calories faster.It's how Alloc explained it; basically the servers heartbeat. I don't believe changing it accomplishes anything. Like, at all.
....On stutteringre A16, stutters were caused by a couple known things and possibly unknowns.
The first known was that the UFPS camera was updating in the wrong order sometimes causing what would look like FPS lag while your FPS would still say 60fps. That one I fixed early on in A17 development so that will no longer be an issue. This would happen when the CPU's physics update would get out of sync with the game update so it was hard to track at first. I tried some random things until I stumbled onto something that kept those calculations in order.
The other known is Garbage Collection. Prior to A17 we made a LOT of garbage and created a lot of new structs and method level vars during run time. We have now internally all started pushing vars to class members instead of making them in the methods. While it adds a tiny bit more to ram when creating the class initially, it doesn't need to destroy it every time the method is ran. The new effect system that runs buffs, progression, items, and events uses this setup so that processing a lot in one frame won't make a crapton of garbage from all those tiny bits adding up.
There are probably more situations and such that have stuttering but those are the main ones I know about and that we've found and started working on reducing.
For anyone curious, below are my system stats and I never have issues with any Unity based games, or any games for that matter.
OS: Windows 7 Ultimate 64-bit
Motherboard: Gigabyte GA-78LMT-USB3
Processor: AMD FX-6300 Six Core Processor (6 CPU) ~3.5GHz
Memory: 20480MB (yeah, I had an extra 4GB ram stick laying around lol)
Video Card: GeForce GTX 1060 3GB
Hard Drives: 512G SSD (2 of them), 2TB HDD
I have windows installed on one of my SSDs and I keep all my games installed on the other.![]()
I never read the dev diary, I avoid that section of the forums like a plague.Fox. You don't read the dev diary anymore, huh... Search for kinyajuus last post or three.
Currently I manually apply it via shell access to the server when I restart the server, but it can be applied in console if you are admin on the server (F1 > settargetfps 100)I would think that if you put the argument into the startup script, that it would be used when the server is restarted. How is your setup configured?
Also, how exactly do you apply the argument? I'd love to do some testing with this.
Server Tools has an option for that.Anyone have any suggestions for getting "settargetfps 100" to apply everytime I restart the server without having to manually do it? Once the server restarts, It reverts the the default 20.