Game Development Community

Manually set offset of scrolling texture

by ArchieMD User · in Torque 3D Professional · 06/04/2010 (2:59 pm) · 6 replies

I need to set a texture offset manually.

I added a console method to Material that sets the offset, and disabled the updateTimeBasedParams which seems to be the only place the offset is altered.

When I step through it, it's clearly only changing the value on the server, not the client. Usually this is easy, just send the new value to the client.... but Material is not a NetObject....

How can I make this work?
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Associate Manoel Neto
Default Studio Name
#1
06/04/2010 (3:03 pm)
Materials only exist client side. A local server (aka: you're playing on the same EXE that is hosting a server) will have access to the materials of the local client, but any changes made to it aren't going to be networked.

You need to send all clients a message (commandToClient) that contains the new scroll value and have each one update their materials. If you need this information to change way too often (like every frame), you'd should write a NetObject-derived class that sends the information via ghost updates.

Torque 3D Owner ArchieMD User
ArchieMD
#2
06/04/2010 (3:06 pm)
Thanks for the quick reply. It would be stupid easy if Material was derived from NetObject. I think someone a long time ago made a very poor choice to not disassociate the idea of a texture (which should not be passed across the network) and a material, which is lightweight enough that it should be sent around the network.

Torque 3D Owner ArchieMD User
ArchieMD
#3
06/04/2010 (3:07 pm)
I guess the solution is to jump through hoops with script calls, which somehow are more flexible than anything you can do in the engine (without a ton of hackery that will all be broken when the next beta comes out), because the engine was poorly designed. Whatever. Torque is awesome!

Associate Manoel Neto
Default Studio Name
#4
06/04/2010 (4:30 pm)
Believe me, networking Materials is a *terrible* idea. You can easily end up with thousands of them in an average project. You wouldn't want thousands of diffuse, normal, specular, detail, etc filenames being send through the network when you load the game (aka: see people having problems with thousand datablocks).

Materials are like GUIs: they have no business in a server. If your server wants to display a pop-up menu for a client, it needs to use commandToClient() to do so.

Torque 3D Owner ArchieMD User
ArchieMD
#5
06/07/2010 (6:41 am)
not "networked", but "networkable". every object should be able to send some data if it wants to. let me register the variables that i want to send, flag them as always-send or only-send-on-dirty, make all objects serializable, and build the packet that way. maybe a little less efficient, but i'm not trying to support 128 players over 14.4, and it'll be a hell of a lot easier to develop on.

Associate Manoel Neto
Default Studio Name
#6
06/07/2010 (8:02 am)
Script-exposed general-purpose serialization is something I do think should be supported and would make things far more flexible.

However, Materials are not the place for this. If they were to support networking, they'd need to be created on the server and ghosted to the clients.

If T3D had some sort of generic ghostable object with scriptable networking (hint hint), you could use that to control client-side stuff like materials and GUIs. Right now commandToClients() will have to make do.