"i tried adding 11000 path nodes, but hammer had trouble compiling the map" brother Hammer has trouble compiling my maps with 0 train paths, you're lucky the 7k variant even compiled edited to fix grammer errer
I think simply doubling the object limit would already solve most things. At best, pushing it up to 4 times it's size (8192) is more than enough to keep 100 player servers entertained. It could also let VScript users experiment more with things, since the object limit would not be a big issue.
@@ragibmahfuz5241 And what are the chances that they would do that just to cater to some minor player base that just wants to play on a 100 players server?
Purely theoretically, how hard would it be for Valve to patch higher object limit to TF2? We know from the video that it's not that hard to just do, but what would be the consequences of doing so? I imagine there'd be some sort of domino effect of more things breaking after increasing the limit? Or would it really be just simple as that?
Not hard, but as shounic said, there may be unintended bugs down the line we don't know about. Also it's not like it needs to be raised for what Valve intends TF2 to be, so they have no reason to shake anything up. It'd be nice and maybe something we could've seen with a more active dev team, but probably wont happen now.
@@FumbleSquid I'd argue that raising the limit would benefit mappers. Latest Halloween maps are already close to the limit, with bloodwater being crashable, even outside of 100 player servers. There's even a person in this comment section, complaining about the object limit as a mapper.
Yes, it's just changing a number, it's that simple. The only consequence is a potential higher server/client load, that's it, there are no other consequences .
Considering jumping into a random community server can lead to you installing several mega-to gigabytes of space for assets, you would probably need to put a description if possible.
@@drgabi18 Who said anything about it being uncapped? You raise the entity limit in the client to a sufficiently high value (8000 to 16000), then let the server tell the client to match its entity limit. This lets server admins host more detailed maps and more players if they have the memory and bandwidth capacity.
I think it's funny to look back now on how eager a lot of people were to install random third party software to play tf2 while faceit was popular in the community. I guess the same people would think it's perfectly fine to install a program that can modify executables for the sake of silly hats
Given how many people lose their accounts because they download a random exe from an obvious scammer, I think there would be a lot of people willing to download that. Besides it's not like "downloading a program for hats" is anything wrong, you are forced to download potentially dangerous executables all the time and usually are fine, welcome to windows I guess
2048 objects/entities would've been a good limit back in 2007. Modern hardware can process all of that at a rate not even dreamt of back in 2007, so actually officially raising the limit to say 4096 wouldn't hurt anybody and would open up a whole new playground for mappers and modders.
@@NykoZeraora This would only be relevant on community maps that use more than 2048 objects. None of the maps that currently exist in the game would be affected. The game becoming unplayable for someone doesnt matter if its only unplayable on a map that already was impossible to make.
@@DJTimeLock Yeah! To be nice, they could also build a "handshake" for it on the client side, so it'll warn you that "playing on this server is going to use additional memory and bandwidth", and stop the connection process if your hardware is really ancient and can't take it.
shounic must’ve gotten the title of the video in the comments a lot, because despite the fact he’s addressed this issue in a previous video, he still had to make an entirely new one on why it doesn’t really work
Surprisingly, I find your server much more enjoyable to play on compared to the casual servers. Since I'm as f2p, being able to call for a medic is an actual lifesaver. And the dopamine hit of hitting a nasty crocket into the enemy team and getting 8 kills that I didn't deserve makes it infinitely better.
Could you maybe patch the server to be able to handle more than 2048 objects, and try a couple methods to make sure the client only ever needs to handle a max of 2048 per update tick? (Start alternating which set is sent to the client each tick? Pick entities within range of each client or something much more processing intensive?) Then your server won't hard crash any time the entity limit is breached which will increase stability, and you wouldn't need clients to patch.
The issue is basically the game reserves a buffer of memory to store all the objects, and the entity limit is just a hardcoded constant for the size of this buffer. Both the server and the client store a copy of this buffer and use it for reference, so they need to be the same size. To have the server have a different entity limit than the client would probably* require complete redoing of the routines for transfering the data. At this point, we're changing the binary executable of the game so it's no longer the same one serviced by steam, which could cause the problems listed in the video (needing a program to patch it, VAC, etc). *I haven't actually looked at the code myself. This is an educated guess based on what is shown in the video and my own knowledge.
That's what I was thinking. Like trying to cull out any objects from the servers' master object list to fit within the 2040 limit for each player. That can even be done in parallel which by dear god we have a lot of cores doing jack.
I have a feeling that the client won't like that, assuming this is possible in the first place. Creating and destroying 2000 objects every tick cannot possibly be good for a system not designed to do that.
@@nikkiofthevalleyif done properly then it won't be destroying 2000 objects every tick Similar methods have worked for quake 3 based games which is a very similar networking model
the insane player density + no hats on the server leads to some interesting phenomenon -since there are no hats players look interchangable, + with the great player density spy can actually disguise and have it work sometimes since everyone blends into eachother. Assuming the map is big enough to not get choked out by projectile spam. Which balances spy out -stock stickies + the base jumper is actually good, since players still dont look up and are dense enough to where most stickies fired will hit something. This also gives sniper a new niche since hes one of the only classes easily able to quickly shoot a demo bomber out of the air -despite mvm levels of player density the gas passer is still garbage. Since it doesnt do meaningful damage and any player hit by it is about to die or near a medic anyways
I was thinking if the limits of 32bit architecture would be potential problem too like if all 100 players had theirs unique cosmetics it might be possible to reach the 4 GB limit
I’m sure absolutely no one is surprised but ficool2’s profile pic (3:31) is from a very popular animation involving two male Beastars characters who explore new ways to show their appreciation for each other. Just if anyone was curious.
@@yousorooo Valve's issue is moreso a unique case of only focusing on making games as long as they make something that pushes technology that justifies it. Valve is more of a tech company nowadays and don't have much interest in the gaming market.
Further patching of the server to hide irrelevant objects from the client (e.g. entities that are guaranteed to be out of view anyway, probably using visleaves which tf2 already uses) would probably be possible. The client probably never needs to actually know of all entities everywhere on the map.
Out of curiosity would it be possible to modify object replication to: Replicate all essential objects Replicate non-essential objects based on distance until hitting the limit
I thought about that too, the problem is that the server needs to constantly keep track of everyone's object list for every single player, which is bad for performance.
I've had that idea too. I guess the performance argument is a good one, but perhaps if someday more server power is available for cheap it'd be an interesting thing to try
@@saiv46 the server already does that? Correct me if I'm wrong but the server doesn't tell you the state of some one's hat if they are out of line of sight, otherwise you could wallhack, or do they just tell you everything on the map at all times?
@@saiv46Honestly, server performance is less of a concern, as it can easily be made into a more powerful machine. I would say that the technical complexity of making it work is more of an issue.
If they raised the object limit they could probably also re-insert the effects that got removed over time, like the individual syringes in the syringe gun that disappeared to make room for hats.
if valve fixed it to like say a 10,000 object limit which apparently is where issues arise, then maybe it could work, or a setting in the launch options that allows clients to increase the limit, or clients copy the servers limit
You wouldn't be able to set it in the launch options because this would restrict what servers you're able to connect to (your limit must match the servers), and just taking the server's limit could be an issue because the server would basically be telling your computer to allocate a buffer of whatever size they want, and stupid/malicious server admins could set the entity limit stupidly high and make your computer run out of memory.
I host Titanfall 2 servers, which also runs on source (though modified). With the Northstar mod, it's possible to past the vanilla player limit of 12, however, going past 16 starts exhibiting some weirdness. Past 18, you have to increase the object limit, and it does work. That's nowhere near 100 players but remember that TF has titans and NPC's and other stuff. Lots of objects. But when playing, it's like the client doesn't get all the data from the server to display everything. Explosions might go off and have an effect, but you won't hear or see the explosion effect client side. Basically, stuff starts to go "missing" in the communication between server and client.
It probably would be more effort than what it's worth, and could have massive issues. But would it be possible to further modify the server to send a truncated object list, where objects ranked low to high importance is removed to meed the client limit?
Whats the point? Its much harder to get pñayer object limit, send objects with priority to each different player then just not doing all of that. On top of requiring a third party app to even join with chance of getting vac
Whats the point? Its much harder to get pñayer object limit, send objects with priority to each different player then just not doing all of that. On top of requiring a third party app to even join with chance of getting vac
@@OrderPrerogativethat’s not what he’s saying, he’s saying the server would keep a list of 2048 “relevant” objects to send to the clients, that way it doesn’t require a patch on the client end, but still has the ability to go over 2048.
It would be a ton of effort, and the process of ranking the objects and only sending the 2048 most important ones would probably use too much processing power and just make the server run slower (shoenic has said that the server does not have an abundance of cpu cycles)
@@nerdycatgamer That's because TF2 itself is a single thread process. Processing server data does not need to be done within TF2 though, only sending out the data 'needs' to be done in TF2. The limitation is in whether or not you can send specific clients specific data.
@@markiplieristhebestpizzato2743 omg. just found his prof. bio says he's the creator of hammer++ too lol. So that's kinda hot ngl... that he likes gay yiff. lmfao.
@@AfraidMonsters >be ficool2 >make a more stable and better version of hammer >make multiple helpful patches for a extremely old and popular multiplayer game >make your pfp cropped porn and not give a shit >refuse to elaborate
Several people talked about some kind of per-player way to stay under the limit using the visleaf system + some kind of priority system to cull entities. It's the most error prone and viscerally fun to program solution (until you get stuck on *that one bug* for like half a year wondering why you are still alive). Definitely will never be implemented, but it will sure as hell bounce around in my head.
4:34 would there be a way for the server to lie to the client about the amount of objects? only listing the closest 2048 (maybe + a priority system) or something to that effect
I no longer play TF2 but damn I still love watching your videos.. something so entertaining about watching you dissecting every small bit of Source's spaghetti code xD
So essentially, get Valve to increase the object limit. They've been doing simple changes from others before, like shown here in this video, so they could do this as well.
Unless all of the objects are on screen at once, then i dont see the issue, but idk how tf2 handles client side prediction and im too lazy to read the "paper" they did on it
i feel like valve could add a server setting that increased it and have that change be copied to the client. or just increase the limit in the base game and have that be the new limit.
so basically; you'd have to mod the game engine and not just the game itself. A line that is a very risky road to cross. Mods can be sandboxed (by the engine), mods of the engine itself really can't. Understandable why you wouldn't, had the same conundrum myself but with unity for RoR2. Was working on a specialised and *highly* experimental sudo mod-loader I called "Plug-and-Play" for streamlining the modding process & live modding severs - not intended for public use because I predicted it would be just way to unstable. The mod would allow you to load any mod into the game *at any time even while in-game* so that while developing your mods you can just re-load your mod whenever you make a change to practically instantly test the changes, especially useful if all you're doing is updating some text. -- if you're insteresting in how it works: It still used BepInEx to load mods in for the most part but acted as a 'intermediary'; calling functions that the mods are trying to call and generally hooking things from the mod into unity - not loading in the mod, BepInEx did that, and not hooking directly like BepInEx does but listening for calls and forwarding them instead, so not really a mod-loader per-say but functionally like one. -- *And it worked.* Though I only ever 'hooked' the basic functions unity uses (like Update()) as it was just a proof of concept. The problem? You couldn't *unload* the mod once it was loaded, defeating the entire point of 'load-unload-update-load' testing. The fix was to use something called "domains" for managing loaded DLLs and by all means it *would* work, but the version that RoR2 is on of Unity is literally *1 week too new.* That's right. Unity didn't just disable but outright removed domain loading, trying to use it now will just throw an error that it's "not supported". Trust me I tired to look for a solution but I couldn't find one that wasn't just "re-add it to the engine by having users modify the the engine - re-implementing it". Which would work and by all means it's possible to automate the modification but, just as it would here, that's very dangerous and asking A LOT of the user - even if they're a modder themselves. Just modding the engine is a line I don't think I'll ever cross.
In theory, could't you write some kind of translation layer, that only sends 2048 objects to each client, cutting whatever ones are far away from them or otherwise not necessary. While still handling all of the objects on the server side. So the clients don't even know that the object limit is raised. Similar to how something like Geiser allows minecraft bedrock players to connect to java servers by adding a translation layer. The Minecraft bedrock client doesn't even know that it's not a bedrock server. This would of course have a performance cost on the server, that would possibly be quite severe.
So the reason it's not possible for Valve to simply update the game with a higher object limit is because due to the nature of TF2's spaghetti code a lot of things could break now or down the line and since very few people are working on TF2 it's not feasible?
The title alone actually reminds me of a time the Beat the Geek _(It was an online Tower Defense game.)_ owner tried to extend its score limit from the 32-bit limit to ... i think the 64-bit limit. It, uh, _broke things._
This is one of these rare cases where dynamic memory allocation would completely nullify all of these problems while not affecting existing game whatsoever. It is simple: server tells you what cap is used for current map, one allocation per change of map won't harm performance at all. This requires full engine memory management rewrite to accomodate changing object limit per-map so you can enjoy 2048 object limit on existing maps but raise it client-side to a higher number when connecting to 100 player servers and will never happen.
is it possible to sort the objects by distance from the player and only send the first 2048? that way the server could be patched without the client's knowledge
What if the server set the limit, and the client set that same limit the way you did in the code? Would that work since then the numbers are the same. Also, random theoretical question, what if the client set their object limit to higher than the server, but lower than what would surpass the 32bit 4gb limit?
here's a very stupid idea: indirect object addressing so the server has 4k objects, which is more than enough to run all maps, but each client can only see up to 2048 of them. this is done by an indirection table that translates server object ids to client object ids and back. could also be per-player to allow finer-grained eviction. eviction will still occur, but only means that some objects cannot be seen by clients, and not that the object is permanently gone, so once the object load goes down or the object becomes important enough they can be added back.
A more complicated solution is to add a truncation layer where the server removes data objects from the list before sending it to the clients. If a client doesn't know about an object on the other side of the map it'd probably be fine. It'd just take an ABSURD amount of work I assume.
The problem with PROBABLY that is that every entity (every player character, their weapons, their projectiles, buildings, hats, facial animations, map stuff, etc) has a unique ID number associated with it, that the server and client are both expected to know is associated with a specific entity. These IDs would be expected to be only within the range of 0 to 2047, and the server would need to remember what every one of it's 100 clients *thinks* the 2048 entity list contains, which would be a table with over 200,000 IDs being mapped. Which the server would have to search constantly to essentially process "oh I'm about to tell client #25 about entity #5138, what ID does he think that entity is?; Oh, and I also need to tell client #27 about the same entity, what ID does he think it is? Oh shit, client #51 moved into the teamfight, so I have to update what entities he knows about, and there's 70 players (+210 weapons, 210 hats, and a bunch of projectile spam) he's about to see"; which is simply a massive amount of processing overhead, on top of the server having to redefine everything about the entity when it "spawns" it for the client. So instead of simply saying "Hey, player #87, entity #1435 is at this position", it needs to say "Hey player #87, create an entity #1435 which is a player demoman, equipped with entity #1436, a strange grenade launcher named "Kablooey" and 1528 kills, entity #1437, a strange professional killstreak quickiebomb launcher with team shine and firehorns, entity #1438, a conscientious objector named "mai waifu" with a picture of Tifa inviting the viewer to f her, entity #1439, a [...]" Which it will need to repeat every time another player moves into render distance of the player. And it still doesn't stop issues occurring if more than 2048 entities are in the vicinity of a player anyway, either crashing the client or causing rockets to be invisible to only the client or hats disappearing.
@@remove_the_at_sign that kind of translation isn't difficult to make, the issue is cramming it into a system that wasn't built for it. It is more work for a processor, but the processor is fast, the difficulty is in the programming. The CPU cost could even be mostly negated by using a proxy to translate on a separate thread, though that'd possibly be even harder. As for the "spawning" issue I hadn't thought of that. I don't think it'd be that much of an issue in the grand scheme of things. I don't know how it's coded so I can't really say for sure, but I still like my idea. I sure hope someone comes up with a solution though.
Honestly this is all I have been playing for the past month. I even got to play with Shounic once and he started messing with the server adding to the chaos 😂
Then the server would be slower having to process the decision making of what to send to specific 100 players according to their viewpoint. It's not viable
I feel like there *could* be a plugin made that spoofs object info sent per client, such that it never tells any client about more than 2048 objects at once. But, that would, a. be significantly harder to do, and b. might result in weird bugs like objects disappearing (?)
Who knows, maybe with a Source 2 version of TF2 they could increase the limit and also make other things better (like the Sniper dot to other players). Maybe they'd even enable us to wear any amount of cosmetics as long as they're compatible (and not more than 1 cosmetic per body area).
concept: the server selectively describes only a fraction of all the objects that exist to each individual player, based on who/what they’re most likely to interact with, effectively “lying” to each client that there are fewer objects than there actually are. is something like this (at least theoretically) possible?
I feel like Valve could just double the entity limit to 4096 from 2048 and it probably wouldn't break anything minus what the video said. I wish Valve considered this and actually told the community why or why not.
As someone who used to work on custom tf2 maps , the object/ item limit is just scary as hell
BOOOO i Am A oBjEcT lImItEr OoOoOo
@@spa7 AAAAAAA
0/2048
As someone who used to work with SDK,
HOW TF DO YOU TURN SNAP-TO-GRID BACK OOOON?!!!
@@skipmanghondarg I DON'T KNOW MAN
I cry every night it's probably somewhere on top idk bro
Shonic is the kind of guy to make a map with 11000 path nods just to play with the source spaghetti monster
source spaghetti monster is an accurate name
Biblically accurate source spaghetti monster
"oh god where do i go"
"pls stop"
"hl2.exe has stopped responding."
The maximum enforced by valve, so send a request to have it set between 1000 min to 5000 max for user control
Truly
"i tried adding 11000 path nodes, but hammer had trouble compiling the map"
brother Hammer has trouble compiling my maps with 0 train paths, you're lucky the 7k variant even compiled
edited to fix grammer errer
Hammer build different
compiling*
@@cheesepop7175
That's literally how he spelled it.
@@BurningBridgeStudiosliterally*
@@vinaythakur4742that's literally how he speled it
Since the office plant and the janitor increased the max player count to begin with, it would be interesting to see if they'd adjust the object limit.
"the office plant" LMAOOO
The moment I read "office plant", I imagined the plant in a pot staying on a chair infront of computer, and all this on cs_office
@@fourlion_everywhereis that Computer science_ office 😂
@@SuperDestroyerFoxWhat?
@ Honestly can't tell you.
i’d gladly sacrifice hats for 50 player games
t. Has no unusuals
@@Luna-Luxmuh shiny pixels on a sooner or later dead game
ok and?
@@Romotisthat's true for every online videogame ever, it's more for personal enjoyment which was the whole point of videogames.....
@@Luna-Lux t. Has unusuals
why doesnt valve just fix all the bugs? are they stupid??
is valve artistic?
@@sleepersharks I dunno but I’m autistic and if I worked at valve and was assigned to deal with the source spaghetti monster within tf2 I would kms
Why dont they just type "if bugs=true then fix"
@@fiendfoliorealnotfake Man is genius! Bwahahahahaha!
There has to be a lore reason behind this…
I think simply doubling the object limit would already solve most things. At best, pushing it up to 4 times it's size (8192) is more than enough to keep 100 player servers entertained. It could also let VScript users experiment more with things, since the object limit would not be a big issue.
Yeah it would be more than enough and there would be no need to patch the renderer.
@@Kacpa2Have u watched the video? Making object limit bigger also requires patching client's tf2, which would be it's own can of worms
@@Spelo1 if devs updated tf2, its fixed
@@ragibmahfuz5241 And what are the chances that they would do that just to cater to some minor player base that just wants to play on a 100 players server?
@@Spelo1 his point is that it's possible, not that it's plausible. Stop being argumentative for the sake of it, you KNOW what he meant.
Rubat is a really cool guy, always loved the stuff they did for Gmod
ficool is a g too i could not live without hammer++
they actually work for facepunch, the creators of gmod now!
Rubat has been deleting a lot of features lately in Gmod, irreversibly breaking addon support in many places, absolutely love him
@@tempname8263 Elaborate please.
Rubat is not multiple people
Purely theoretically, how hard would it be for Valve to patch higher object limit to TF2? We know from the video that it's not that hard to just do, but what would be the consequences of doing so? I imagine there'd be some sort of domino effect of more things breaking after increasing the limit? Or would it really be just simple as that?
the server room gets a bit warmer
Good news it's 20F in Seattle this week @@nero7699
Not hard, but as shounic said, there may be unintended bugs down the line we don't know about.
Also it's not like it needs to be raised for what Valve intends TF2 to be, so they have no reason to shake anything up. It'd be nice and maybe something we could've seen with a more active dev team, but probably wont happen now.
@@FumbleSquid I'd argue that raising the limit would benefit mappers. Latest Halloween maps are already close to the limit, with bloodwater being crashable, even outside of 100 player servers. There's even a person in this comment section, complaining about the object limit as a mapper.
Yes, it's just changing a number, it's that simple. The only consequence is a potential higher server/client load, that's it, there are no other consequences .
This feels like something valve could build into the client themselves where the server can dictate the entity limit.
Me, the server, sending the client an order to allocate 2TB of ram for objects
Considering jumping into a random community server can lead to you installing several mega-to gigabytes of space for assets, you would probably need to put a description if possible.
@@drgabi18 Who said anything about it being uncapped? You raise the entity limit in the client to a sufficiently high value (8000 to 16000), then let the server tell the client to match its entity limit. This lets server admins host more detailed maps and more players if they have the memory and bandwidth capacity.
Possibly, but there would need to be a cap. Past that, the thing that makes this fix infeasible is the expectation valve ever would.
@@8Kazuja8 You underestimate how many mfs run TF2 on low end computers (I was one of them a year ago)
I think it's funny to look back now on how eager a lot of people were to install random third party software to play tf2 while faceit was popular in the community. I guess the same people would think it's perfectly fine to install a program that can modify executables for the sake of silly hats
Given how many people lose their accounts because they download a random exe from an obvious scammer, I think there would be a lot of people willing to download that.
Besides it's not like "downloading a program for hats" is anything wrong, you are forced to download potentially dangerous executables all the time and usually are fine, welcome to windows I guess
Shounic is more trustworthy than Faceit tbf
hi kodi!!!!
2048 objects/entities would've been a good limit back in 2007. Modern hardware can process all of that at a rate not even dreamt of back in 2007, so actually officially raising the limit to say 4096 wouldn't hurt anybody and would open up a whole new playground for mappers and modders.
A major portion of the playerbase being on the edge of the game becoming unplayable
yeah, just look at bloodwater, great map frfr
would be even better if they let the server decide the size. Would allow more customization. But the default being 4096.
@@NykoZeraora This would only be relevant on community maps that use more than 2048 objects. None of the maps that currently exist in the game would be affected. The game becoming unplayable for someone doesnt matter if its only unplayable on a map that already was impossible to make.
@@DJTimeLock Yeah! To be nice, they could also build a "handshake" for it on the client side, so it'll warn you that "playing on this server is going to use additional memory and bandwidth", and stop the connection process if your hardware is really ancient and can't take it.
shounic must’ve gotten the title of the video in the comments a lot, because despite the fact he’s addressed this issue in a previous video, he still had to make an entirely new one on why it doesn’t really work
"Exponential Painful" is a VERY good wait to describe programming in general.
i forgot to add the library im using in ONE function's parameters, so now its bugged and i have to do some boring stuff
jonkler references are always appreciated
@@ebux9885 D:
why are you crediting jonkler instead of man? are you stupid?
The jonkler meme is so confusing for me lol
Why did @@ebux9885 say that? Are they stupid?
@@Jornkeris there a lore reason why you're confused? Are you stupid?
Surprisingly, I find your server much more enjoyable to play on compared to the casual servers. Since I'm as f2p, being able to call for a medic is an actual lifesaver. And the dopamine hit of hitting a nasty crocket into the enemy team and getting 8 kills that I didn't deserve makes it infinitely better.
just spend $5 retard
Arkham insanity really gets to him.
Havent't played TF2 in a while, but I absolutely love the epic saga of the 100 Player Server
I wouldn't mind if Valve raised the limits for every game to what CSGO's limits are.
It would be nice if valve doubled the object limit in a future update
It would be nice if valve made a future update
It would be nice if valve wasn't an abusive father figure
It would be nice if valve
It would be nice
it would be
2:58 bro thought he was Todd Howard 💀
IT JUST WORKS IT JUST WORKS LITTLE LIES STUNNING SHOWS PEOPLE BUY IT JUST WOOOORRRKKS
@@hectorgilgil6990IT JUST WORKS, IT JUST WORKS
OVERPRICED OPEN WORLDS
EARNINGS RISE, TAKE MY WORD
IT JUST WORKS
Is there a lore reason?
are they stupid?
The law was set in place by president Abraham Lincoln because no one would agree to a nuclear treaty without any proof.
Bulbasaur
@@Aspect333-w9o Isaac Newton wished to simulate wars before they happened on his ti-84 calculus
Could you maybe patch the server to be able to handle more than 2048 objects, and try a couple methods to make sure the client only ever needs to handle a max of 2048 per update tick? (Start alternating which set is sent to the client each tick? Pick entities within range of each client or something much more processing intensive?) Then your server won't hard crash any time the entity limit is breached which will increase stability, and you wouldn't need clients to patch.
The issue is basically the game reserves a buffer of memory to store all the objects, and the entity limit is just a hardcoded constant for the size of this buffer. Both the server and the client store a copy of this buffer and use it for reference, so they need to be the same size. To have the server have a different entity limit than the client would probably* require complete redoing of the routines for transfering the data. At this point, we're changing the binary executable of the game so it's no longer the same one serviced by steam, which could cause the problems listed in the video (needing a program to patch it, VAC, etc).
*I haven't actually looked at the code myself. This is an educated guess based on what is shown in the video and my own knowledge.
That's what I was thinking. Like trying to cull out any objects from the servers' master object list to fit within the 2040 limit for each player.
That can even be done in parallel which by dear god we have a lot of cores doing jack.
I have a feeling that the client won't like that, assuming this is possible in the first place. Creating and destroying 2000 objects every tick cannot possibly be good for a system not designed to do that.
@@nikkiofthevalley Yea that seems very possible, but it could be interesting to try. For science!
@@nikkiofthevalleyif done properly then it won't be destroying 2000 objects every tick
Similar methods have worked for quake 3 based games which is a very similar networking model
5:13 "all that including needing to keep up with tf2 updates"
I like your funny words magic man
the insane player density + no hats on the server leads to some interesting phenomenon
-since there are no hats players look interchangable, + with the great player density spy can actually disguise and have it work sometimes since everyone blends into eachother. Assuming the map is big enough to not get choked out by projectile spam. Which balances spy out
-stock stickies + the base jumper is actually good, since players still dont look up and are dense enough to where most stickies fired will hit something. This also gives sniper a new niche since hes one of the only classes easily able to quickly shoot a demo bomber out of the air
-despite mvm levels of player density the gas passer is still garbage. Since it doesnt do meaningful damage and any player hit by it is about to die or near a medic anyways
i do miss not having sprays. 100 sprays on a server would be amazing
wait sho enabled sprays some time before, they're gone again?
@@JM-dq7xnthey are still there. Just 60 outta 100 playere can use them. If your index is 61 and higher - you won’t be able to spray
@@JM-dq7xn when i played nobody had them
I miss my furry spray :(
@@jackraptor695 You were behind classic:
"Today we are doing an experiment to find out"
"how much cock can a single boipussy take", mr. Mathf?
I was thinking if the limits of 32bit architecture would be potential problem too like if all 100 players had theirs unique cosmetics it might be possible to reach the 4 GB limit
Even with a 32 bit architecture you can just. Use multiple variables too keep track of the list.
I’m sure absolutely no one is surprised but ficool2’s profile pic (3:31) is from a very popular animation involving two male Beastars characters who explore new ways to show their appreciation for each other. Just if anyone was curious.
Proof?
i know bruh i was freaking the hell out when i saw that
Glad I wasn’t the only one who noticed LOL
I mean, he is polish (at least according to his steam profile)
Yes, truly this animation shows entirely new and unexplored avenues of friendly and wholesome conduct
Was alt tabbed in tf2 while watching this video. I actually thought my game crashed at 0:42 and tried to quit out for a second. Help
Why don’t they just port everything over to Source 2? It would solve every one of their problems, including world hunger.
Valve said no
Valve devs are too busy making the 100th game that will never release
@@TeamSprocketValve used to make games, now they just make money.
@@yousorooo Valve's issue is moreso a unique case of only focusing on making games as long as they make something that pushes technology that justifies it. Valve is more of a tech company nowadays and don't have much interest in the gaming market.
lol. lmao.
5:21 keeping up with updates...what updates?
Oh no the title, you’ve been infected
Further patching of the server to hide irrelevant objects from the client (e.g. entities that are guaranteed to be out of view anyway, probably using visleaves which tf2 already uses) would probably be possible. The client probably never needs to actually know of all entities everywhere on the map.
Its official, shounic has escaped the aslume.
Out of curiosity would it be possible to modify object replication to:
Replicate all essential objects
Replicate non-essential objects based on distance until hitting the limit
I thought about that too, the problem is that the server needs to constantly keep track of everyone's object list for every single player, which is bad for performance.
I've had that idea too. I guess the performance argument is a good one, but perhaps if someday more server power is available for cheap it'd be an interesting thing to try
I mean I know games like Roblox use a similar replication technique so it might work
@@saiv46 the server already does that? Correct me if I'm wrong but the server doesn't tell you the state of some one's hat if they are out of line of sight, otherwise you could wallhack, or do they just tell you everything on the map at all times?
@@saiv46Honestly, server performance is less of a concern, as it can easily be made into a more powerful machine.
I would say that the technical complexity of making it work is more of an issue.
4:50
Why not tell valve to update it on our end? Are they stupid?
They took 2 days to fix item server.
I don't want to wait 20 years for them to fix any gamebreaking bug introduced by raised item cap.
If they raised the object limit they could probably also re-insert the effects that got removed over time, like the individual syringes in the syringe gun that disappeared to make room for hats.
shounic uploading is always a good day
WAIT THE ASLUME REFRENCE OMGOSH
if valve fixed it to like say a 10,000 object limit which apparently is where issues arise, then maybe it could work, or a setting in the launch options that allows clients to increase the limit, or clients copy the servers limit
It has to be a power of two, so 16684 or 8192 entities.
You wouldn't be able to set it in the launch options because this would restrict what servers you're able to connect to (your limit must match the servers), and just taking the server's limit could be an issue because the server would basically be telling your computer to allocate a buffer of whatever size they want, and stupid/malicious server admins could set the entity limit stupidly high and make your computer run out of memory.
@@henke37 It doesn't have to be a power of 2. It is simply a constant in the code.
I host Titanfall 2 servers, which also runs on source (though modified). With the Northstar mod, it's possible to past the vanilla player limit of 12, however, going past 16 starts exhibiting some weirdness.
Past 18, you have to increase the object limit, and it does work. That's nowhere near 100 players but remember that TF has titans and NPC's and other stuff. Lots of objects.
But when playing, it's like the client doesn't get all the data from the server to display everything. Explosions might go off and have an effect, but you won't hear or see the explosion effect client side. Basically, stuff starts to go "missing" in the communication between server and client.
3:30 that animation lives in my head rent free
What animation?
@@flusen9408 if you are the type who ought know, you already do. Don't worry about it.
It probably would be more effort than what it's worth, and could have massive issues.
But would it be possible to further modify the server to send a truncated object list, where objects ranked low to high importance is removed to meed the client limit?
Whats the point? Its much harder to get pñayer object limit, send objects with priority to each different player then just not doing all of that. On top of requiring a third party app to even join with chance of getting vac
Whats the point? Its much harder to get pñayer object limit, send objects with priority to each different player then just not doing all of that. On top of requiring a third party app to even join with chance of getting vac
@@OrderPrerogativethat’s not what he’s saying, he’s saying the server would keep a list of 2048 “relevant” objects to send to the clients, that way it doesn’t require a patch on the client end, but still has the ability to go over 2048.
It would be a ton of effort, and the process of ranking the objects and only sending the 2048 most important ones would probably use too much processing power and just make the server run slower (shoenic has said that the server does not have an abundance of cpu cycles)
@@nerdycatgamer That's because TF2 itself is a single thread process. Processing server data does not need to be done within TF2 though, only sending out the data 'needs' to be done in TF2. The limitation is in whether or not you can send specific clients specific data.
The aslume is spreading
3:31 Uh... Is that profile picture from what I think it's from? (a gay legoshi phrn image/vid, pretty sure)
Pog
any time you see a cropped picture of legoshi there's a 50/50 chance it's from something naughty
It indeed is.
@@markiplieristhebestpizzato2743 omg. just found his prof. bio says he's the creator of hammer++ too lol. So that's kinda hot ngl... that he likes gay yiff. lmfao.
@@AfraidMonsters
>be ficool2
>make a more stable and better version of hammer
>make multiple helpful patches for a extremely old and popular multiplayer game
>make your pfp cropped porn and not give a shit
>refuse to elaborate
Several people talked about some kind of per-player way to stay under the limit using the visleaf system + some kind of priority system to cull entities. It's the most error prone and viscerally fun to program solution (until you get stuck on *that one bug* for like half a year wondering why you are still alive).
Definitely will never be implemented, but it will sure as hell bounce around in my head.
4:34 would there be a way for the server to lie to the client about the amount of objects? only listing the closest 2048 (maybe + a priority system) or something to that effect
I mean I bet there’s a way but it’d be fairly slow to do culling server-side and I’d imagine it would be weird with high latency
@@TheMiningCrafter ok yeah but the alternative is the game crashing
"and the problem lots of interesting things is that they tend to have exponential painful..."
So inspiring. So real. Gaben a real one for that o7
I no longer play TF2 but damn I still love watching your videos.. something so entertaining about watching you dissecting every small bit of Source's spaghetti code xD
So essentially, get Valve to increase the object limit.
They've been doing simple changes from others before, like shown here in this video, so they could do this as well.
Unless all of the objects are on screen at once, then i dont see the issue, but idk how tf2 handles client side prediction and im too lazy to read the "paper" they did on it
Is shounic from aslume? Am I stupid?
according to quantum mechanics, you are both stupid and not stupid at the same time
@@professionalshitposter6897schrodinger's aslume
i feel like valve could add a server setting that increased it and have that change be copied to the client.
or just increase the limit in the base game and have that be the new limit.
I love the quotes you always place at the end
they tend to have exponential painful.
1:10 I would shit bricks if I ever come across as erver wich announces its crash like that
so basically; you'd have to mod the game engine and not just the game itself. A line that is a very risky road to cross. Mods can be sandboxed (by the engine), mods of the engine itself really can't.
Understandable why you wouldn't, had the same conundrum myself but with unity for RoR2.
Was working on a specialised and *highly* experimental sudo mod-loader I called "Plug-and-Play" for streamlining the modding process & live modding severs - not intended for public use because I predicted it would be just way to unstable.
The mod would allow you to load any mod into the game *at any time even while in-game* so that while developing your mods you can just re-load your mod whenever you make a change to practically instantly test the changes, especially useful if all you're doing is updating some text.
--
if you're insteresting in how it works:
It still used BepInEx to load mods in for the most part but acted as a 'intermediary'; calling functions that the mods are trying to call and generally hooking things from the mod into unity - not loading in the mod, BepInEx did that, and not hooking directly like BepInEx does but listening for calls and forwarding them instead, so not really a mod-loader per-say but functionally like one.
--
*And it worked.* Though I only ever 'hooked' the basic functions unity uses (like Update()) as it was just a proof of concept.
The problem? You couldn't *unload* the mod once it was loaded, defeating the entire point of 'load-unload-update-load' testing.
The fix was to use something called "domains" for managing loaded DLLs and by all means it *would* work, but the version that RoR2 is on of Unity is literally *1 week too new.*
That's right. Unity didn't just disable but outright removed domain loading, trying to use it now will just throw an error that it's "not supported".
Trust me I tired to look for a solution but I couldn't find one that wasn't just "re-add it to the engine by having users modify the the engine - re-implementing it".
Which would work and by all means it's possible to automate the modification but, just as it would here, that's very dangerous and asking A LOT of the user - even if they're a modder themselves.
Just modding the engine is a line I don't think I'll ever cross.
In theory, could't you write some kind of translation layer, that only sends 2048 objects to each client, cutting whatever ones are far away from them or otherwise not necessary. While still handling all of the objects on the server side. So the clients don't even know that the object limit is raised. Similar to how something like Geiser allows minecraft bedrock players to connect to java servers by adding a translation layer. The Minecraft bedrock client doesn't even know that it's not a bedrock server. This would of course have a performance cost on the server, that would possibly be quite severe.
At 3:30 , is it wrong of me that I know where ficool2's profile picture originated from?
Ik exactly what your talking about T~T
It turns out that we were the spaghetti code all along.
Seeing Ficool2’s profile picture was like a slap to the face
I just realized how little I truly know about programming
So the reason it's not possible for Valve to simply update the game with a higher object limit is because due to the nature of TF2's spaghetti code a lot of things could break now or down the line and since very few people are working on TF2 it's not feasible?
The title alone actually reminds me of a time the Beat the Geek _(It was an online Tower Defense game.)_ owner tried to extend its score limit from the 32-bit limit to ... i think the 64-bit limit. It, uh, _broke things._
This is one of these rare cases where dynamic memory allocation would completely nullify all of these problems while not affecting existing game whatsoever. It is simple: server tells you what cap is used for current map, one allocation per change of map won't harm performance at all.
This requires full engine memory management rewrite to accomodate changing object limit per-map so you can enjoy 2048 object limit on existing maps but raise it client-side to a higher number when connecting to 100 player servers and will never happen.
Is there a lore reason why the insanity is here too?
broo like yea i came here for both the aslume and tfe and why are people baely talking about it??
is it possible to sort the objects by distance from the player and only send the first 2048? that way the server could be patched without the client's knowledge
I love these deep dives into TF2, simply excellent videos sir!
Hey, at least you didn't outright get rid of items entirely, which is more than I can say for Valve.
Could the server be modified to only send the 2K objects nearest to each respective player?
That's actually a good idea
3:31 this guy's pfp is from furry corn btw
This used to say 3:51 apparently. Im stupid
why must people be horny on main
Based
Might actually be able to track it down
@@Horhay-xg1kp Backdoor labrador is not at all difficult to track down.
let's goooo
Man it would be nice if Volvo increased the limit to 4096 or 8192 :)
Maybe with the *64 bits updates, they will upgrade the object limit?
if an update added the change client and server side officially, but good luck getting valve to do this
alright, someone get the janitor and desk plant on the line.
What if the server set the limit, and the client set that same limit the way you did in the code? Would that work since then the numbers are the same.
Also, random theoretical question, what if the client set their object limit to higher than the server, but lower than what would surpass the 32bit 4gb limit?
03:30...wait a minute...I know that image...
Elaborate
@masteroshi58114 Backdoor Labrador :3
Furry Turing test
The Aslume is here
here's a very stupid idea: indirect object addressing
so the server has 4k objects, which is more than enough to run all maps, but each client can only see up to 2048 of them.
this is done by an indirection table that translates server object ids to client object ids and back. could also be per-player to allow finer-grained eviction.
eviction will still occur, but only means that some objects cannot be seen by clients, and not that the object is permanently gone, so once the object load goes down or the object becomes important enough they can be added back.
Hmm... Ficool's profile picture is uh, totally unfamiliar to me. Yes, I have never seen that collection of pixels before in my life.
the train wiggling about is killing me
Same thing goes to other source engine games like left 4 dead 2.
There were some custom maps almost exceeded 2048 limit.
A more complicated solution is to add a truncation layer where the server removes data objects from the list before sending it to the clients. If a client doesn't know about an object on the other side of the map it'd probably be fine. It'd just take an ABSURD amount of work I assume.
The problem with PROBABLY that is that every entity (every player character, their weapons, their projectiles, buildings, hats, facial animations, map stuff, etc) has a unique ID number associated with it, that the server and client are both expected to know is associated with a specific entity. These IDs would be expected to be only within the range of 0 to 2047, and the server would need to remember what every one of it's 100 clients *thinks* the 2048 entity list contains, which would be a table with over 200,000 IDs being mapped.
Which the server would have to search constantly to essentially process "oh I'm about to tell client #25 about entity #5138, what ID does he think that entity is?; Oh, and I also need to tell client #27 about the same entity, what ID does he think it is? Oh shit, client #51 moved into the teamfight, so I have to update what entities he knows about, and there's 70 players (+210 weapons, 210 hats, and a bunch of projectile spam) he's about to see"; which is simply a massive amount of processing overhead, on top of the server having to redefine everything about the entity when it "spawns" it for the client.
So instead of simply saying "Hey, player #87, entity #1435 is at this position", it needs to say "Hey player #87, create an entity #1435 which is a player demoman, equipped with entity #1436, a strange grenade launcher named "Kablooey" and 1528 kills, entity #1437, a strange professional killstreak quickiebomb launcher with team shine and firehorns, entity #1438, a conscientious objector named "mai waifu" with a picture of Tifa inviting the viewer to f her, entity #1439, a [...]"
Which it will need to repeat every time another player moves into render distance of the player.
And it still doesn't stop issues occurring if more than 2048 entities are in the vicinity of a player anyway, either crashing the client or causing rockets to be invisible to only the client or hats disappearing.
@@remove_the_at_sign that kind of translation isn't difficult to make, the issue is cramming it into a system that wasn't built for it. It is more work for a processor, but the processor is fast, the difficulty is in the programming. The CPU cost could even be mostly negated by using a proxy to translate on a separate thread, though that'd possibly be even harder.
As for the "spawning" issue I hadn't thought of that. I don't think it'd be that much of an issue in the grand scheme of things. I don't know how it's coded so I can't really say for sure, but I still like my idea. I sure hope someone comes up with a solution though.
Why do I keep thinking there wolud be tenbere rosso sangue playing in the background? Its obviusly not it, right?
It's like the thermometer in littlebigplanet DO NOT HIT THE LIMIT
I saw “are they stupid” on the title and got instantly brain blasted to “Why is Man no laugh at Jonkler joke? Is he stupid?”
As you have said, the only thing it would change is allowing hats to be used, but it still would've been nice to have an option regardless
Cool! Thanks Shoe!
Its good to know my question wasn't fully stupid, only partially
Nice video regardless!
The Alsume is here too. We will never leave.
"The 100 player server cannot have hats"
GOOD.
It's 2007 TF2 all over again. And I love that one more.
Will the 64 - bit update help increase the object limit?
64, not 46
Honestly this is all I have been playing for the past month. I even got to play with Shounic once and he started messing with the server adding to the chaos 😂
is the title a reference to that post about the people who died in Pompeii
Is it possible to just not send the client enough objects to crash? Maybe ignore too far away or generally unimportant objects?
Then the server would be slower having to process the decision making of what to send to specific 100 players according to their viewpoint. It's not viable
I feel like there *could* be a plugin made that spoofs object info sent per client, such that it never tells any client about more than 2048 objects at once. But, that would, a. be significantly harder to do, and b. might result in weird bugs like objects disappearing (?)
Who knows, maybe with a Source 2 version of TF2 they could increase the limit and also make other things better (like the Sniper dot to other players).
Maybe they'd even enable us to wear any amount of cosmetics as long as they're compatible (and not more than 1 cosmetic per body area).
concept: the server selectively describes only a fraction of all the objects that exist to each individual player, based on who/what they’re most likely to interact with, effectively “lying” to each client that there are fewer objects than there actually are. is something like this (at least theoretically) possible?
5:16 you're underestimating our autism
I feel like Valve could just double the entity limit to 4096 from 2048 and it probably wouldn't break anything minus what the video said. I wish Valve considered this and actually told the community why or why not.