Server Discussion [Request for Chucklefish] Prevent crashes when client lacks an object (like a custom crafting table)

I'm requesting that in multiplayer, if a client doesn't have an object like a custom crafting table, they see the object as a generic, non-interactive object, instead of crashing to desktop.

EDIT: More information here: http://community.playstarbound.com/...-a-custom-crafting-table.129149/#post-3098153

 

For the same reason why bad items turn into PGIs, but can't be converted back, your idea would literally break the game even more. Using a generic object in place would permanently change that object for everyone, because the object is on the server, not locally to you. So unless the server first queries your system for what mods it has installed and the mod itself is written to account for people not having the mod, there is really not a good way to handle it.

The game crashes because that type of issue is one you need to resolve, not sweep under the rug.

 

It's quite possible if the devs aren't boneheaded and know how to handle such discrepancies, and it should have been thought of early in development.

It should be like this: If a client receives an item with a name/id that it doesn't recognize, it won't convert the actor or crash, instead it will keep the name/id it received from the server so it doesn't get overwritten, and on the client's side use generic item code that doesn't do anything, along with showing a generic sprite in it's place. No additional data would be necessary, just the name of the item being requested by the engine.

Also, a similar principle should be applied outside of multiplayer- if a map or the inventory has an item or tile the game doesn't recognize, it doesn't wipe the name/identifier or convert it. Instead, it would keep the ID, but visually default to showing either a generic item or dirt(for tiles), use generic code, and in the case of items show the unknown item's internal name* when highlighted instead of "perfectly generic item" for easy recognition.

*(The name of the item being requested, like if "mycraftingtable" was in your inventory, but the game doesn't recognize it, it'd keep that name but resort to generic handling code in it's place.)

Why would this be beneficial? Well, if someone deletes a workshop mod that adds new tiles, and loads an area that used those tiles afterwards, it'll show as dirt, but if they reload the mod, it'll still have the tile IDs memorized, and thus they'll show as they once were. Would also prevent people from losing items.

All in all, quite possible, but a change to how the game handles objects it doesn't recognize would be necessary.

 

So every developer of modable games are boneheaded?

Where would it "keep" this information for things in which it knows nothing about?

How would the game handle something like a full on biome or race?

The game does have "Generic handeling code". That is what PGIs are for. But it can't just keep some magical data that it knows nothing about in the background. The game doesnt know what to do with X, so it converts it to Y, which is something it does know about. Things that it couldnt practically handle with generics, it crashes. Plane and simple.

You lack basic understanding of how games and multiplayer work. Servers don't "give" data like that, it rather asks "Hey, do you have X?". If the answer is no, then it has to resort to generics or crash. Setting up generics for everything is impractical. Because of this, the data on either end of a connection MUST be the same when you are dealing with third party assets.

 

To add to that, the reason why you don't get a crash right off the bat with a modded item being placed is because the server understands what to do with it. The person who doesnt have the mod simply doesnt show it because they are not interacting with it in any way. As soon as they try to use it, pick it up, or otherwise have to interact with something their game knows nothing about, then it will crash.

Multiplayer is primaraly just syncronizations of data and movemnts. You actually are not "going" to a server, you are just syncing with it. You are just simulating everything on your end and sending updates to the server, and the server decideds if you are allowed to do it or not, and if so, sync with everyone else. When you do an action, your game says "Hey server, I did X". And the server will return with "Ok, Ill let everyone else know you did X, so the server sends out a sync update. This is why when you have many people in a small area it gets laggy in multiplayer games because everyone is trying to sync with the server and the server is trying to sync with everyone else. It has little to do with your computer hardware.


Ever play on a minecraft server with permissions? Ever notices how you can break a block but it will instantly be replaced? That is because the server knows you arent supposed to break it but your local game does not, so you break the block, then your game tells the server you did. The server says you are actually not allowed to do that, so the block is returned.

Multiplayer is rather lonely when you understand how it works.

 

I wasn't calling names, I was just saying that it's fully possible to do if one isn't completely inept. (Thus, boneheaded) Misconstruing my words.

With the implementation I'm thinking of, the client doesn't *need* to know what to do with it. All it needs to know is what the item name is, and it's position, and type, which from what I can tell the server already informs the client of. I also know there is no Generic item handling code, it would need to be implemented.

PGIs are a shitty way of handling unknown items. It's a band-aid, not a graceful solution. A graceful solution would be to have the item not be a "Perfectly generic item", but "Unknown item: ItemName" in the case of pickups, and in the case of unknown tiles, still keep the tile's name, but since the client doesn't have the sprite, it'd use a generic sprite, and in the case of objects, not have it crash, have it spawn a generic, non-interactive item with the original object's name in it's place when the server sends something unknown to them.

I fully understand how multiplayer games work, I've developed a few (Lambda Arena & TerminalFury to name two, first is a Source Engine arena shooter, second is an unreleased source port of Hellbender and Fury3). I don't fucking appreciate you making the assumption that I don't, and thus insulting my knowledge or ability. It's downright condescending.

This only holds true in a sync-based multiplayer design. A good example of this would be Doom/Doom 2's original netcode, which just synchronized everyone's input, and there's no actual server whatsoever. Every player ran their own simulation of the game. Such netcode will lag for everyone if any single player's connection is poor, or if you have a lot of players since it has to wait to keep everyone in sync. This type of netcode is common in fighting games, netplay-capable emulators, and old-school FPS.

A more common client/server design in modern titles (generally FPS games), clients do not simulate much at all aside from visuals and anything that it can predict (such as movement, weapon firing, and other things the client is safe to make assumptions about). The server is the authority, handling everything gameplay-related, from player positions, actor positions, hit detection, spawning of actors, actor status, etc, and informing the clients of the result (the current state of things). The client sends their input to the server, while doing some movement and collision prediction on their end (so their own movement doesn't feel laggy, and so they don't jitter when touching something), and the server processes the actual movement, collision, etc... basically everything truly important to the simulation.

There is little actual "synchronization" going on at all, just the server receiving input and sending results as soon as it can, and the clients reproduce it as soon as it receives the necessary data. The server doesn't wait, and if either the client or server miss packets, strange behavior can occur, but the game keeps on going. This is how Minecraft does things, and from what I can tell, Starbound is not much different.

The Minecraft brick breaking bit mentioned is because the client predicts brick breaking on it's own, but on the server it didn't really break, and when the client gets the next update about the brick's state, it re-appears because was never really broken. If the client was made aware by the server that a brick couldn't be broken beforehand(transmitted as part of the block's data), this effect wouldn't occur.

 

So ever developer of a modable game is a bonehead? Because I challange you to find a single modable game that handles modding in the way you would like. (Spoiler: None exist)

Except the client, and server, equally need to know what to do with data. If one doesnt know what to do, it will cause an exception and boot back an error/crash. The client doesn't really "recieve" data, the server tells the client to go get the data from the local files, and if the data isn't there, the client will again boot back an error/crash.

How would it get the item name if the client doesn't have the data? Like I said, the server says to go get specific data. If the client can't find it, it will boot back an error/crash. If they code the server to transfer that data, where would it store it? The player file? That sure would be a good way to cause bloat and a good avenue for abuse. This is why servers don't really send game data, they send synchronization data.

Then stop being so ignorant about it. If you know how it works, you have yet to show that here.

Yes, the server will do the bulk of the work as far as processing the game world, but it is still just synchronizations across clients and the server. Everyone sends their sync data to the server, and the server updates everything, then sends out the new data to the clients so that they can update their screens.

 

Still putting words in my mouth, stop that.

I can think of several games. Doom (modern ports like Zandronum, if it doesn't recognize something placed in a map or being spawned, it simply says "I don't know what X is", and either just doesn't spawn it if it's something being spawned by the server or a script, and if it's an unknown item on the map itself, it shows a big exclamation point sign in it's place.), Quake (since the first game), just about every Source Engine game in existence (in Source, if a server spawns an entity the client doesn't recognize, it doesn't crash, it says "unknown entity: entity name", and puts a big "error" text model in it's place, and if one uses the console command to get the name of the entity you're aiming at, it'll still say it's name.)

Funny thing about that last bit. Garry's mod is the perfect example of a moddable game that the server and client can have total mismatch of anything, and handles the errors exactly how I'm proposing. Not just with multiplayer, but even when handling items that aren't known in singleplayer saves. (For example, you spawn an object from a mod, save your game, delete the mod, and reload the save... it'll be an error model in it's location. Save the game again, load the mod, load the save once more, things return to normal and the object is what it's supposed to be.

They don't send synchronization data, that is one hell of a misnomer. They send actions/events. (This thing spawned, this thing was destroyed, this thing is moving at x/y/z velocity and is currently at x/y/z position, etc. Occasionally, they'll send a full update of the state of objects/players if there's too much of a discrepancy.)

Now, if the server did actually send the actor's full scripts, where would they be stored? Probably like most games that allow transfer of mod content, to a cache folder. (See: Unreal Tournament)

When the server tells the client to spawn an object with the item's name. Look at it this way: The server tells the client to spawn an object called "MyItem" at a specific coordinate. The client doesn't have an item called "MyItem", so it spawns a non-functional, generic actor named "MyItem" in it's place, at the same coordinates. It's not goddamn rocket science. The beauty of a client/server system, is that the client can have things differ from the server gracefully. The client is capable of spawning things and doing things in it's own instance that won't affect the server or other clients.

False, they do a lot of listening for input, but they don't wait. Unlike sync-based netcode, it will not throttle the game or hang until it gets a response, if it doesn't get a response, it continues processing the gamesim based on what it already knows.

Then you'd realize that in this situation, there's no "syncing" going on here.

 

Ignorance abound.

Clearly you don't know what synchronization means. Client sends information to server, server updates, server sends data to client, client updates. That is literally synchronization.

This isn't worth my time anymore. You don't know half of what you are talking about.

 

Now you're just being an asshole. I just showed you SEVERAL examples of games that work just as I had proposed, and now you just resort to calling me ignorant. Not only that, but I've also accurately explained quite clearly how certain forms of netcode work. Something tells me you've never had any real experience with game networking, or at the very least different forms of it... or, you've read some articles and are now thinking you're some expert, and now turning your nose down at me.

That's not synchronization. Synchronization implies that you're keeping two or more things in lockstep with one another. Yes, there's exchange of information, but they are not exactly synchronized. Both the client and server are capable of doing things of their own accord, and often do.

 

https://www.google.com/search?q=do+...rome..69i57.5990j0j7&sourceid=chrome&ie=UTF-8

Do some searching next time. If they didny sync data, then why is it a common topic of question?

Synchronizations doesn't mean all data, it is simply an act and could be small bits of data or large amounts as necessary. The server telling a client "Hey, X object has moved and is now over here." That is synchronization.

 

I don't need to search, I already know. Just because it's a common term doesn't mean it isn't a terrible misnomer that causes confusion as to what's really going on behind the scenes, especially when you compare it to games that do real synchronization*. It's why I refuse to use the term when speaking about client/server netcode.

*(By that I mean keeping things in lockstep, all clients see things at the exact same time as everyone else because the gamesim is delayed by the exact time period that it takes for all players' inputs to get sent/received and processed by one another, all players run their own full instance of the gamesim, and are expected to produce the same result, making mismatching content impossible in such games, and is also why said games are prone to crippling de-synchronization).

Also, nice of you to ignore half of my last two posts.