Sending colorset information to a client on the server?

[Conservative]

Does anybody know if there is a command that updates the PaintRow group in the tree view with information from the server?

And please don't just come in and say "you can't change the color information on a brick mid-game", because I've found that to be false, only problem is a player is required to leave and rejoin to update the color information again.

[Ad Bot]

[Port]

Updating them on the server itself is easy, and it's definitely possible to update them for clients. I'm not quite sure what the exact approach is though.

Try setting $Pref::Server::AllowColorLoading to true and load a save with a different colorset.
The only problem is that the rows/columns don't change, only the actual colors themselves.

[Conservative]

Updating them on the server itself is easy, and it's definitely possible to update them for clients. I'm not quite sure what the exact approach is though.

Try setting $Pref::Server::AllowColorLoading to true and load a save with a different colorset.
The only problem is that the rows/columns don't change, only the actual colors themselves.

I've found a console command that updates a clients rows/columns, I just need a command that updates the values they use beforehand.

[MARBLE MAN]

Does anybody know if there is a command that updates the PaintRow group in the tree view with information from the server?

And please don't just come in and say "you can't change the color information on a brick mid-game", because I've found that to be false, only problem is a player is required to leave and rejoin to update the color information again.

  virtual void setColorTable(int colorID, string color) {}
   virtual void setSprayCanDivision(int index, int slot, string name) {}
   virtual string getSprayCanDivisionName(int index) {}
   virtual int getSprayCanDivisionSlot(int index) {}
not sure if it helps :p

[Port]

  virtual void setColorTable(int colorID, string color) {}
   virtual void setSprayCanDivision(int index, int slot, string name) {}
   virtual string getSprayCanDivisionName(int index) {}
   virtual int getSprayCanDivisionSlot(int index) {}
not sure if it helps :p

These are all purely server-sided. What we're looking for is how to update a client's information.

[Conservative]

There was some.. freak accident in which the information DID transfer to a client in my server for any brick I planted with the new information.

I had made a solid cyan color, the guy saw the original red all as solid cyan, then I applied some transparency to it and he actually saw the cyan with transparency for any brick I planted after that.

We have been unable to replicate this, unfortunately.

[Chrono]

Then saving/loading comes into play, and everything gets forgeted.

[Port]

Then saving/loading comes into play, and everything gets forgeted.

As long as you use $Pref::Server::AllowColorLoading, there won't be any problem.

[Conservative]

As long as you use $Pref::Server::AllowColorLoading, there won't be any problem.

This only makes it so when loading bricks from a different color set, it checks for the colorset on the server and gives you two options if it is not the same colorset.

It does not transfer the new color information to the client, sadly, because it expects the colorset on the server to have already been loaded by the client.

[Chrono]

As long as you use $Pref::Server::AllowColorLoading, there won't be any problem.

There's only 3 forms of color loading.
One where it just uses the colorID, whether it's even the same color or not.
One where it checks for the closest match to the colors, and assigns colorIDs based on that.
And one very broken one that attempts to append the save's colorset to the current colorset, whether or not it exceeds 64 or any matching color exists, then tries to assign the bricks the new colorIDs.

[Port]

It does not transfer the new color information to the client, sadly, because it expects the colorset on the server to have already been loaded by the client.

Yes it does..?

There's only 3 forms of color loading.
One where it just uses the colorID, whether it's even the same color or not.
One where it checks for the closest match to the colors, and assigns colorIDs based on that.
And one very broken one that attempts to append the save's colorset to the current colorset, whether or not it exceeds 64 or any matching color exists, then tries to assign the bricks the new colorIDs.

It doesn't append, it replaces.