Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
zorilya

Registered:
Posts: 35
Reply with quote  #1 
Sometimes you want to make a custom object with the script, give it a new description, perhaps a race... and that's all well and good. However, if you wish for that objects info to persist through reconnects of players that have dropped then there has to be a way of re-sending that info as it appears that currently the engine just uses the info from the client side VesselData.xml, which would be inaccurate.

One solution is to have a timed loop that does this kind of "maintenance" but that has the issue of requiring you to know the objects name and with random names giving an easy way for players to distinguish objects from other similar objects, it's not something that I want to give up.

I was wondering if any consideration has been given or will be given to changing the source of the updated information for newly connected players. Perhaps asking the server to post an update across the network of the state of ship info on it's side (It's not that much info surely) rather than expecting the vesselData to be accurate.

Thanks
     zorilya
ryleyra

Registered:
Posts: 3,007
Reply with quote  #2 
Thom has brought up the idea, in previous posts (long before the release of 2.3 and 2.4) of so-called "plug in" enemy and player races. The idea is that you can purchase a ship class, race or enemy as an expansion pack, and install it on your server. Inherent to that idea would be the ability for the server to "broadcast" the expansion pack file, or at least its contents, to all connected clients.

I have no idea what has come of this idea. It's obvious Thom was thinking of the Ximni, but they were released as part of 2.4. So I suspect he hasn't worked on it. Not only would there be a lot of code involved to transmit the data from the client to server (and the server would have to wait until it is done before it let anyone start it, delaying the game somewhat) but there must be some consideration of licensing. You don't want someone who hasn't bought the expansion to get the file from a download and then start it on their own server.

One additional advantage to this feature is that it could be used to download generic meshes, textures and sound files for a custom mission to the clients. There would be less concern about licensing in this case because the meshes and sound files would be useless without the script. (Which doesn't need to leave the server)

I'll note that currently generic meshes and textures HAVE to be on the client, or scripts will not work. Sound files do not have to be. (They are only played on the server, and only for the first player ship. It's a known issue that multiple ships cannot hear the sound files used in scripts) Generic meshes are the way you create custom objects. I tend to re-use meshes and textures I know are part of the game, for instance, I might use an asteroid with a different texture, like a mine, for a planet.

zorilya

Registered:
Posts: 35
Reply with quote  #3 
Great that it has been thought about on that sort of scale but for just keeping a persistence of information between sever and client (not necessarily mesh and texture data, just text things like Race,description and scan description...) there appears to be some information in the game (ship name) that is persistent in this way so the framework is clearly there, I guess just not refactored to work with all of the text content that can change from time to time.
ryleyra

Registered:
Posts: 3,007
Reply with quote  #4 
I'm honestly not really sure what you're talking about. Any custom vessel in vesselData will appear as a TSN Light Cruiser or other ship type if the client has the stock vesselData. Mods have to be installed on all computers, not just the server. That's why mods can't be used with Android or iOS.

Is there some console that is not preserving information after disconnect? I know that Comms loses all previous logged message, and the GM screen loses all its menus. I'm not aware of anything else.
MarkBell

Avatar / Picture

Administrator
Registered:
Posts: 1,955
Reply with quote  #5 
Actually I'm just running into this now - I set a skybox index in the setup for an extremely simple mission script.  Since the clients can't click "Ready to Play" until the server is going, they actually don't pull up the specified skybox since they didn't get the "set skybox index" command.  

I can send a "set skybox index" command 10 seconds into the script so all the clients get the updated skybox, but it would be nice if they pulled up the right one when they joined the mission.

I think what zorilya is requesting is a way for clients to query the server about certain things instead of having to specifically push that info out from the server.

__________________
Note - this is in no way intended to be an official position of Thom or Artemis, as I am not an official representative of the creator or game.
ryleyra

Registered:
Posts: 3,007
Reply with quote  #6 
I did not know that. Seems like something that needs to be sent in the server's acknowledgement that the client has connected. Or if that's supposed to be sent, maybe it's bugged.

I can only assume the old Comms messages are not sent because that could take a while. Plus, very likely old Comms message aren't even stored. The GM buttons probably need a refresh function when the client connects, though.

I think it would be a nice feature if the server polled the client to see if a mesh or texture is available, and if it isn't, sent it. The same could be done for the Mainscreen in a multiship scenario. This would be for both sound files Comms can play and those that are just played directly.

zorilya

Registered:
Posts: 35
Reply with quote  #7 
I am talking about using the set_ship_text command. Data like the name is persistent and is broadcast (or appears to be) from the server after a reconnect to make sure that all clients have the same objects named the same thing. The server also appears to be the location where any changes to the hail messages of a given ship are stored and so they are persistent.

Other data that this command can change such as description, scan description, race and class are not persistent in the same way and the data that is updated into those areas is straight from the client side vessel data rather than from the server side version of the instance.

Once again, I'm not talking about mesh files or anything that would take a considerably long time to download on the fly... just text information that is used to make a ship appear to be of a different race than you would normally expect or a different class.

So to summarize and direct my question more succinctly, Is there a chance of us seeing a time where the game will take all text information relevant to the appearance of a ship through the science screen, weapons screen, comms screens or GM screen updated by requesting it from the instance on the server and not assume that everything is as the vesselData says it is client side?


ryleyra

Registered:
Posts: 3,007
Reply with quote  #8 
Are you talking about an enemy ship vessel, or are you trying to set description on the player ships? If the description set on an enemy ship in a script is not surviving disconnect from the server, this is the first I have heard of it.

Okay, confirmed. This is definitely a bug. I think you've diagnosed the problem correctly, the ship description is not retained on the server since it's considered part of the vesselData file. The script command must send a packet to the clients, which tells them to update their description. Since a new client cannot determine what descriptions have changed, it reads the description from vesselData, assuming it is valid. What needs to happen is that the server should sent a set_ship_text packet to each client when it first connects, for each set_ship_text command that has been issued to that point.

As a temporary workaround, the script could repeat the set_ship_text command every few seconds, in much the same way Xavier came up with to keep the GM menu up to date.

Now I'm wondering what other commands might have this issue. Anything which overrides vesselData but is not normally changed by the server in an Invasion Mode game is a potential candidate.

zorilya

Registered:
Posts: 35
Reply with quote  #9 
I posed that as a solution in my initial comment and outlined the drawback of having to know what the name of the ship is.

Long story short it's not a great solution but I'm glad to have highlighted a bug of that nature.
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.