Heavy Cockpit

Thinking about improving the Artwork in Vega Strike, or making your own Mod? Submit your question and ideas in this forum.

Moderator: pyramid

Post Reply
omarza
Star Pilot
Star Pilot
Posts: 4
Joined: Sun Apr 01, 2007 2:27 pm

Heavy Cockpit

Post by omarza »

I want to start off by thanking all of those whom contributed to this project... I think they did a great job.

I played around a bit and ended up with this cockpit as I was looking for something with a nice view (unrestrictive). It was inspired by the ph01_cockpit which I saw in this section. I am using this cockpit in version 0.4.3 at the moment.

If anyone is interested let me know and I will upload it for them... just have to find out where to do that. Didn't just want to upload it as I don't know if people will like it etc.

On viewing the images click on the image link and then once again after it loaded to get the higher resolution as the default it come up with is really bad.

Images
Image
http://server3.pictiger.com/img/971484/ ... mage-2.jpg

Image
http://server3.pictiger.com/img/971483/ ... mage-1.jpg
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Welcome omarza nice clean design and i think that you aced your unrestrictive goal :!:

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
rigelan
Confed Special Operative
Confed Special Operative
Posts: 291
Joined: Sat Jan 28, 2006 2:58 am
Location: Des Moines, Iowa

Post by rigelan »

Yeah, its a slight rearrangement of the other cockpit, I like it, especially the change in the energy bars from horizontal to vertical.
omarza
Star Pilot
Star Pilot
Posts: 4
Joined: Sun Apr 01, 2007 2:27 pm

Post by omarza »

Thanks for the welcome.

Yes that glassy cockpit view idea came from the other cockpit (Phelan's) I think. I really liked it but it felt a bit out of place in the bigger ships and therefore I created this one for larger ships.

I would like to contribute to the project as I am a systems designer/developer with extensive exp in Assembler (mostly inline for code optimizing), C, C++, Delphi etc. I have still a lot to learn regarding VS as I am newish to the game but started digging a bit. I haven't used OGRE before but have used other graphics engines and I expect a new learning curve there. I also have a couple of years experience in data communications (UDP & TCP sockets).

With that said... are anyone currently working on a new improved user interface (buying/selling/mission etc) as thats one area I think the game can be improved tremendously and I am willing to help out there. However I do not know the priorities and what everyone is currently working on... although I read that they are busy with a networked version and therefore do not know if an improved interface is already being worked on.

With an improved interface I also mean an improved market and even personal hangars for players where they can store goods as well as ships etc with a nice proper transfer system to handle all that. I also include a nice 3D map on board the ship as well as within stations as part of that.

I am more than willing to help out with this but don't want to do that if its not needed by the development team. Work takes priority tho and at times my time will be very limited. If someone from the development team can contact me with more information, that would be great.

Once again thanks for a great game.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

Yes the GUI needs a rewrite i believe that was put on the ever growing to do list and forgotten :wink: at least till klauss gives us the OGRE framework we have also lacked active coders that know the source tree you should get a PM from one of the devs i'am just the spam deleter and newbie Shepard :wink:

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

We definitely can use more developers.

Lately, not much has been actively worked on...

The OGRE port is a big project which klauss is working on (though it still seems far from completion).

Right now, there is no new GUI to go with the network system... at some point we need an ingame login box that could replace having to edit the vegastrike.config file.

The current GUI system written by Mike Byron is pretty advanced as far as I can tell... While you could make a new one, I don't know how useful that would be.

You say that you have a lot of experience in UDP and TCP transmissions. I would be interested in what you think of our current networking protocol, and how well you think it would be able to handle large numbers of people.
http://vegastrike.sourceforge.net/wiki/ ... nt:Network
http://vegastrike.sourceforge.net/wiki/ ... ket_format

One networking project we need is a download system. We had a developer who started all of the networking code and then left. He wrote a class called "download manager" whose job I'm not exactly clear about.

Anyway, I would like to get a system in place where certain data files would be opened by downloading from the server rather than from the client. A really important example is system files which contain serial numbers. The problem is that they are opened from the player's home directory just like in a single player game. The reason it works at all on a single machine is that the server writes it out to the same folder that the client reads it from.

We have a VsFilesystem class wrapping around calls to fopen (which was planned to be used for PK3 packaging), and we might be able to use that to download from the server.

If you want, you could try figuring out the best way for a client to get the server's system file.

Thanks
omarza
Star Pilot
Star Pilot
Posts: 4
Joined: Sun Apr 01, 2007 2:27 pm

Post by omarza »

Thanks for the feedback loki1950 and ace123.

Regarding the interface. One area I think needs serious reworking is the 3D system map... to something like EVE's 3D system map as its then usable and easy to navigate in a large universe where at the moment I find myself constantly switching to VSNav to plot routes etc as I like doing things visually. However networking and other issues are probably more important atm with a higher priority.

I quickly scanned over the network protocol listed and here is my first opinion (although I might be wrong as I haven't studied it yet). It differs considerably from the way I usually design my protocols and I will explain roughly why.

Usually in communications I try to make use of both TCP as well as UDP and therefore have to cater for packet loss. Why I make use of both those protocols is because of the following:

1. TCP and/or UDP affects protocol design
With games we need fast response times between client and server machines to try and prevent lag, latency etc as much as possible. Using TCP results in a problem here because when the TCP packet hits a fullish node thats congested TCP synchronization will occur. Therefore I usually prefer to use UDP although for chat etc I prefer TCP again as lag, latency etc are not an issue there and I don't have to waste processing power to synchronize the chat area freeing more processing power etc. Usually people will implement the game data being sent back and forth in UDP packets while text might be using the TCP protocol... however it depends on the design you implement etc.

Don't know if you ever experienced playing a MMO and found text still updates but game play itself freezes etc. Its all due to incorrect usage of TCP/UDP packages usually. How it works is as follow...

In a case of a node bottleneck (on Internet) sharing TCP as well as UDP traffic, the behavior of that node changes. What will happen is that the TCP flow control mechanism will have an affect on the UDP traffic. When congestion at a node appears TCP synchronization occurs which will allow the queue length of the bottleneck buffer to evolve in a periodic way ... and therefore can stay full for a while.

It is known that UDP packet loss then occurs in this TCP synchronization phase. However UDP in small packages are very effective in countering this packet loss when above occurs. The downside in small packages is large overhead in UDP package headers etc. In this case TCP will also be ineffective due to data being slow to pass thru the node as it forms part of the long TCP queue at that node. Fastest and most effective here would be small UDP packages and larger TCP packages for chatting etc.

Now when designing the network protocol you have to keep all that in mind and therefore have to build support for dropped packages and even to manually having to synchronize these packages into you protocol. IF you are only using the TCP protocol all that is not needed but you WILL experience heavy lag or latency a lot of time... which in turn destroys game play.

2. Plan for the future and changes in protocol
The game has been released and after a while there seems to be some new features or changes thats added to the protocol to make it more affective on new releases etc. In one scenario the actual game has not changed (only the protocol) and we still need to initially communicate with the update server (with the old protocol) before automatically downloading a patch to update the patch downloader. In scenario two we might have a protocol change to cater for an add-on which the game can play without but we don't want to update everyone to the new protocol UNLESS they are going to install that add-on etc... who knows what the future brings.

For that reason the protocol needs to identify itself properly to the servers so that the servers can switch/use the appropriate protocol version for that session or sessions. Therefore we usually ensure that we are backward compatible whenever a protocol changes and design these protocol identification into our packet headers.

3. Make use of a Session ID
I also usually prefer to make use of a session identification within the packet header, which the server sends to the client and the appropriate session identification is then sent in the packet header within each packet. This makes it harder to spoof an IP and at the same time you use it to allow you to bind control and data channels together in a dual port architecture. It also allows us to implement load balancing at a later stage if/when it is required.

Initial Opinion and Examples
I did not see any of that within the protocol for VS and that concerns me BUT once again I only had a quick glance at the protocol and don't know how complete they have documented it. I will quickly list an example from one of the protocols (stripped down) I designed for one of my programs I developed as an illustration of how I like my protocols to look like.

Keep in mind it was ages since I used HTML and I am not going to spend a lot of time formatting it nicely as its just an example.

The protocol makes use of 0F as a command indicator. The following 2 bytes specifies the applicable command

Packet Header

Length - Description
2 bytes - Protocol Version
10 bytes - User ID
6 bytes - Session ID
4 bytes - IP Address
4 bytes - Packet Length
3 bytes - Command ID
3 bytes - Reserved

Common to both Server & Client
Command ID - Description
0F 00 00 - Command Received Notification
0F 01 02 - Request Protocol List
0F 01 03 - Send Available Protocol List
0F 01 04 - Request Date and Time
0F 01 05 - Send Date and Time
0F F0 00 - Ping Remote Computer
etc

Client to Server
Command ID - Description
0F 01 00 - Send Login Information
0F 02 00 - Register New User
0F 02 02 - Change User Information
0F 02 04 - Change Password
0F 02 06 - Deactivate User Account
0F 02 08 - Activate User Account
etc

Server to Client
Command ID - Description
0F 01 01 - Send Login Status
0F 02 01 - Acknowledge User Registration
0F 02 03 - Acknowledge Change User Information
0F 02 05 - Acknowledge Change User Password
0F 02 07 - Acknowledge Deactivation of User Account
0F 02 09 - Acknowledge Activation of User Account
0F 03 00 - Server Send Message
0F 03 11 - Send Message Information
0F 04 01 - Send Users Found
0F 04 03 - Send User Information
0F 04 05 - Send Online Status
0F 06 01 - Request User List Add Permission
0F 06 03 - Send User List Add Permission
etc

Client to Client
Command ID - Description
0F 07 00 - Request Direct Communications
0F 07 01 - Send Direct Communications Request Reply
0F 07 02 - Send Message
0F 07 08 - Send Text
0F 07 09 - Request File Transfer
0F 07 0A - Request File Transfer Reply
etc

Below are some commands explained. Keep in mind the Command ID of the command are in the package header and NOT part of the package data.

Command Received Notification (0F 00 00)
This command is sent to acknowledge that a command has been received.
Package Data
Length - Content - Description

3 bytes - xx xx xx - Received command ID

Send Login Information (0F 01 00)
This command is used to log a user onto the server and are done via TCP.
Package
Length - Content - Description

1 byte - xx - User ID Length
x bytes - var xx - User ID - Length determined by User ID Length
1 byte - xx - Password Length
x bytes - var xx - Password - Length determined by Password Length
4 bytes - xx xx xx xx - Local IP Address
1 bytes - xx - TCP Listening Port

Send Login Status (0F 01 01)
This command is used to send the user login status. If the login is successful a unique session ID will be returned to the client which the client will use for the duration of the session or until the server notifies the client of a new unique session ID.
Package
Length - Content - Description

1 bytes - xx - 00 - Successful 01 - Unsuccessful
4 bytes - xx xx xx xx - Session ID

Request Protocol List (0F 01 02)
This command requests a list of supported protocols used by the remote system.
Package
Length - Content - Description

None

Send Protocol List (0F 01 03)
This command sends a list of supported protocols used by the local system. Once its received the Server will switch to the appropriate protocol for the rest of the session communication to ensure backward compatibility.
Package
Length - Content - Description

1 byte - xx - Number of Protocols in this packet
2 bytes - xx xx (1st) - 1st Protocol Version
.... - Multiple entries - One for ech protocol ..
2 bytes - xx xx (last) - Last Protocol Version

Deactivate User Account (0F 02 06)
This command is used to temporarily deactivate a users account. This request might be used if a user goes away on holiday for a couple of weeks or for whatever reason. The account can only be re-activated remotely via a special activation code received from the server. That way accounts are more secure against hacking for prolonged periods when the user are away.
Package
Length - Content - Description

2 bytes - xx xx - Password Length
x bytes - var xx - Password - Length determined by Password Length
2 bytes - xx xx - Message Length
x bytes - var xx - Message - Length determined by Message Length
1 bytes - xx - Message Status

Acknowledge Deactivation of User Account (0F 02 07)
This command is used acknowledge that a users account has been deactivated. If it was rejected then an error message will return informing the remote system why the deactivation was rejected.
Package
Length - Content - Description

1 byte - xx - 00 - Deactivation Accepted 01 - Deactivation Rejected
8 bytes - xx xx xx xx xx xx xx xx - Reactivation code used to reactivate the acount at a later stage
2 bytes - xx xx - Error Length - if 00 then no error
x bytes - var xx - Error message length determined by Error Length

Important to note that every package sent will have the package header in front. This way the system can check whether complete packages has been sent, from where it came, whether the session ID are valid and allows us to manually synchronize packages at the same time if needed. Upon the receive of a package the system will ALWAYS return a received package command to notify the client/server that the package has been received. This helps in synchronizing and at the same time the system can detect whether bottlenecks exist, whether packages was dropped, and detect if reducing UDP packages in size might optimize communications to the remote computer. It might even switch to TCP if required or vice versa.

What concerns me is that I saw nothing for flow control within the listed protocol and also did not see and control within packages to ensure that those are formatted properly to ensure all data have been received. However it seems as if the protocol listed are under documentation of how people think its function... once again I might be wrong there.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

I agree with most of your points.

The page I took you to was far from complete... all it contained was the different command ID's... nothing more.

The packet header apparently has this:

Code: Select all

    const Header* h = (const Header*)buf;
    command         = h->command;
    serial          = ntohs( h->serial );
    timestamp       = ntohl( h->timestamp );
    data_length     = ntohl( h->data_length );
    flags           = ntohs( h->flags );
The page I gave you was only commands... apparently command is only one byte long. There's more in the header that's send... I'll put that up on the wiki when I get a chance

For your first point:
We use both UDP and TCP... it attempts a UDP connection, and tests by asking for the time by UDP. If it times out (I believe it has a 1-second timeout) , then it defaults to TCP everywhere.
The packet format is the same for UDP and TCP.

For the second point, we do not in any way plan for the future or changes in the protocol. That's something that is really high on my priority list, along with having a clear packet specification.

Session ID's are used (the network code calls them a "serial")... unfortunately, I think that this serial is linked with the unit serial, which could be bad if the unit dies...

The account stuff in my opinion will not be as big a part of the protocol. There is a login message with the server...


By the way, you mention "4 bytes - xx xx xx xx - Local IP Address " Is that used for getting UDP messages through a router? I would be interested in knowing how to do this.
Why do you use a "TCP Listening Port"? It seems that UDP would be more useful.

Also, why the "Send Protocol List (0F 01 03)"? Can't the client just send a message "I'm using protocol version 2" and the server can figure out how best to deal with that protocol version.
omarza
Star Pilot
Star Pilot
Posts: 4
Joined: Sun Apr 01, 2007 2:27 pm

Post by omarza »

We use both UDP and TCP... it attempts a UDP connection, and tests by asking for the time by UDP. If it times out (I believe it has a 1-second timeout) , then it defaults to TCP everywhere.
The packet format is the same for UDP and TCP.


We also use the same packet format for both UDP and TCP. Do you recheck UDP every now and then after you switched to TCP in case there was a dip in the wide area network... which happens a lot between different countries worldwide.
For the second point, we do not in any way plan for the future or changes in the protocol. That's something that is really high on my priority list, along with having a clear packet specification.
I therefore take it that VS will not change/improve in the future and what we have now is it.
By the way, you mention "4 bytes - xx xx xx xx - Local IP Address " Is that used for getting UDP messages through a router? I would be interested in knowing how to do this.
Why do you use a "TCP Listening Port"? It seems that UDP would be more useful.
With local I mean the local IP address the client has on the network. The purpose behind this is more towards TCP for the chatting as we use chat relay where possible to lighten server loads and sometimes can speed up connection speed via another users computer on our network if a particular user has a very bad connection directly to our servers. In such case we might relay messages via another computer.

We usually prefer using TCP for the chat part of our programs as speed are not important there. Also with a lot of dropped packages and problems with UDP we switch to the UDP part to TCP. The listening port is used for direct chat communications as well as for chat relay etc. If you run only a few users its not so important but unfortunately we have to cater for thousands of simultaneous online users.
Also, why the "Send Protocol List (0F 01 03)"? Can't the client just send a message "I'm using protocol version 2" and the server can figure out how best to deal with that protocol version.
If you look again at that routine... it sends a list of available protocols. The reason behind that is that we do cater for the future and for add-ons etc. It might be that a specific add-on uses a complete different protocol TOGETHER with the main protocol. By implementing it that way we cater for 3rd party add-on developers WITHOUT having to change our main protocol every time someone develops something new/different.

I didn't reply in my previous post to suggest you must change the protocol... just viewed my opinion on what I saw in that URL you gave and tried to give a few ideas. If it seemed as criticism then I do apologize as it was not intended that way.

Usually when I am involved on a project its as lead developer or people call me in when they hit a brick wall to solve their problems... therefore I usually look at everything from that angle and might have done the same and maybe subconsciously were looking for potential problems. I have never worked on open source projects and maybe its best for me to stay focused in the commercial area. I started working as developer in 1984 and are so used to lead projects... and therefore it might have a negative effect on an open source project in the long run. It might also maybe bring a conflict of interest with the current MMORPG I am working on.

Good luck with the development on VS... and I sincerely mean it as you guys are doing a good job.
Post Reply