Script Infrastructure
by Kyle Carter · in General Discussion · 11/12/2003 (10:13 am) · 2 replies
What sort of infrastructure do we want to provide for TorqueScript? What things (like GUI controls) can we add to the engine to make things go more smoothly? Given we want to provide decent in-game GUIs, are there areas we need to upgrade?
Harold mentioned adding a better array control, and adding an ability for binary file transfer (of images, for instance). I think that these are Good Things to have.
How do we want to deal with incoming/outgoing events? Do we want to hang it all off of the CommunityConnection class? ie, postMessage(targets, band, chat), ::onMessage(originator, band, chat)? Is there a better way to break things out? We want to provide at least the possibility for connections to multiple communities at once, so we shouldn't go with the global callback method currently used by the master server stuff.
Harold, you mentioned doing prototyping over TCP and with TCPObject. I think that the cost of implementing and modifying NetEvents is low enough that we can pretty much start developing with them. I guess it depends on the type of prototyping, and whether it's more or less hassle to do backend stuff in TS over C++. What are your opinions?
edit: fixed small bit of idiocy (NetEvents, not SimEvents, thanks Mark)
Harold mentioned adding a better array control, and adding an ability for binary file transfer (of images, for instance). I think that these are Good Things to have.
How do we want to deal with incoming/outgoing events? Do we want to hang it all off of the CommunityConnection class? ie, postMessage(targets, band, chat), ::onMessage(originator, band, chat)? Is there a better way to break things out? We want to provide at least the possibility for connections to multiple communities at once, so we shouldn't go with the global callback method currently used by the master server stuff.
Harold, you mentioned doing prototyping over TCP and with TCPObject. I think that the cost of implementing and modifying NetEvents is low enough that we can pretty much start developing with them. I guess it depends on the type of prototyping, and whether it's more or less hassle to do backend stuff in TS over C++. What are your opinions?
edit: fixed small bit of idiocy (NetEvents, not SimEvents, thanks Mark)
#2
Right now the new array control would be the one thing I would want the most.
ProtoTyping -
Generaly I was refering to things I would prototype myself. My C++ / knowledge of the TGE Network code isn't good enough for me to code my own NetEvents :)
As for the C++ / Script gateway, I really only see the need for two things. A single function to send with and an onMessage event callback. The onMessage event would then dispatch events to the appropriate script modules.
11/13/2003 (10:50 am)
GUI Controls -Right now the new array control would be the one thing I would want the most.
ProtoTyping -
Generaly I was refering to things I would prototype myself. My C++ / knowledge of the TGE Network code isn't good enough for me to code my own NetEvents :)
As for the C++ / Script gateway, I really only see the need for two things. A single function to send with and an onMessage event callback. The onMessage event would then dispatch events to the appropriate script modules.
Associate Mark Frohnmayer
And yeah, I'd definitely start prototyping the client with the NetEvents and not TCPObject. This will give us a clearer idea of what events need to exist in the community server.
For the GUI frontend, the Legends guys now have a really cool multi-column resizable array control for server lists... it's possible we could convince them to contribute the control, though it wouldn't be too hard to make one ourselves.