[IDEA] X-Online -Initial Project Failure -Project Re-Conceptualized
Moderators: Scripting / Modding Moderators, Moderators for English X Forum
-
- Posts: 2993
- Joined: Sun, 25. Dec 05, 10:42
the amount of load on the sever for just this trade server is minimal, server clustering is not going to be required.
Querying on different ips miens 2 internet connections (i believe you mean to say different ports) but yes that is possible but theirs a better way to do it
A central 'relay' server that would scan incoming data and hand it off to what ever server needs it
Querying on different ips miens 2 internet connections (i believe you mean to say different ports) but yes that is possible but theirs a better way to do it
A central 'relay' server that would scan incoming data and hand it off to what ever server needs it
-
- Posts: 208
- Joined: Wed, 24. Jan 07, 06:26
will you be able to outfit a ship and sell it on the hub? for example
instead of someone going all over the galaxy fitting a ship, i could offer them at a 120% increase in total price, a completely outfitted ship ready to go...
or for another example, selling hard to find ships, like pirate nova raiders or those hyperions i keep hearing about
instead of someone going all over the galaxy fitting a ship, i could offer them at a 120% increase in total price, a completely outfitted ship ready to go...
or for another example, selling hard to find ships, like pirate nova raiders or those hyperions i keep hearing about
-
- Posts: 2033
- Joined: Wed, 29. Jun 05, 01:45
Hmm.. like an auction system.
I don't plan on doing anything like that at the moment. I thought about it, but I had planed on making a resupply script instead, which would obsolete that idea
Thou I did have another idea for a personal transfer system, but I want to get this one working right first.
(Its getting rather tedious.. as I have to decode the log, encode for byte transfer, decode the bytes, process the numbers, then recode, decode, then tfile it
(7 step process.... currently I have about 4 steps worked out)
I don't plan on doing anything like that at the moment. I thought about it, but I had planed on making a resupply script instead, which would obsolete that idea
Thou I did have another idea for a personal transfer system, but I want to get this one working right first.
(Its getting rather tedious.. as I have to decode the log, encode for byte transfer, decode the bytes, process the numbers, then recode, decode, then tfile it

(7 step process.... currently I have about 4 steps worked out)
-
- Posts: 2993
- Joined: Sun, 25. Dec 05, 10:42
what means are you using to transfer data? are you using a header byte that identify the packet or some other way?
most of the servers ive programed / programed for use a system like this:
the first two-four bytes identify the packet... say 0x01... That would me say CMSG_CLIENT_LOGIN ect or something, after that is recognized by the sever, it goes into a adaptable subroutine, changing that data into its respective structure and passing it to the appropriate function, it eliminates the issue of having to write a decode function for every packet you want to transfer
most of the servers ive programed / programed for use a system like this:
the first two-four bytes identify the packet... say 0x01... That would me say CMSG_CLIENT_LOGIN ect or something, after that is recognized by the sever, it goes into a adaptable subroutine, changing that data into its respective structure and passing it to the appropriate function, it eliminates the issue of having to write a decode function for every packet you want to transfer
-
- Posts: 2033
- Joined: Wed, 29. Jun 05, 01:45
Yeh thats pretty much what I'm doing
Except that the header byte is just one byte (I really only need 2 bits... but hey, I suppose 256 is better then 4, plus there is room for tweaks)
-technically, now I only need 3 things (but that's still 2 bits)
I'm just a fair annoying/slow process to write it all
I call the header byte the task, and each task has a fixed number of arguments, so its possible to string multiple tasks + args in a single line. One of the more annoying things is that I decided to use absolute minimal bandwith usage possible (even thou this setup doesn't really use much to begin with), as of such some figures use UINT16, where as some use Int32, which makes de/re-coding really annoying
Note to self....
Don't create byte stream at process
Create a sub to auto compile/decompile the byte stream.
(i.e. get the first byte, see how many subsequent bytes there are, then send over those bytes. Dont do the actual "stuff" in the byte enc/decoder
Except that the header byte is just one byte (I really only need 2 bits... but hey, I suppose 256 is better then 4, plus there is room for tweaks)
-technically, now I only need 3 things (but that's still 2 bits)
I'm just a fair annoying/slow process to write it all

I call the header byte the task, and each task has a fixed number of arguments, so its possible to string multiple tasks + args in a single line. One of the more annoying things is that I decided to use absolute minimal bandwith usage possible (even thou this setup doesn't really use much to begin with), as of such some figures use UINT16, where as some use Int32, which makes de/re-coding really annoying
Note to self....
Don't create byte stream at process
Create a sub to auto compile/decompile the byte stream.
(i.e. get the first byte, see how many subsequent bytes there are, then send over those bytes. Dont do the actual "stuff" in the byte enc/decoder
-
- Posts: 2033
- Joined: Wed, 29. Jun 05, 01:45
So long and thanks for all the fish.
Well in case you hadn't realized now as this is like my fourth thread i've posted in. I'm going. Yup
sad
such works un finished 
But yeh.. hopefully someone else can finish off where I started.
So Here is the source code, for what I can only describe as a generalized chat program + server side, with x3 script tie ins -with out the x3 side scripts...
In short, I just learnt how to VB a tcp/ip connection. So, with this, and write to logfiles/read text files, you can communicate with any one.
Here is the source of what I've done so far
http://members.optuszoo.com.au/whyistha ... online.zip
It has a console (dos window) for the server side, and a program for the client side. It written to work on the 7744 log/text file numbers.
Basically.. Yeh.. I can't remember what most of it does. But its all in the comments.
In short it does this
(Remember, that I haven't written the x3 scripts for this yet, I just made the basic communication program, which is also undone)
X3 script -> logfile -> prog -=-=-> compress to binary level for sending -> server prog -=-=-> formats it back to true form, processes it and then reformats it back into binary to send back to the client -=-=-> client prog -> processes it, spits it into a text file -> game reads text file every.. 1second/what ever
Oh and one last note, this isn't actually related to the x-online the web game. I just couldn't think up a better working title when I started working on this.
Oh and the last last note. The warelist.csv which it may refer to is this
http://members.optuszoo.com.au/whyistha ... relist.csv
Well in case you hadn't realized now as this is like my fourth thread i've posted in. I'm going. Yup



But yeh.. hopefully someone else can finish off where I started.
So Here is the source code, for what I can only describe as a generalized chat program + server side, with x3 script tie ins -with out the x3 side scripts...
In short, I just learnt how to VB a tcp/ip connection. So, with this, and write to logfiles/read text files, you can communicate with any one.
Here is the source of what I've done so far
http://members.optuszoo.com.au/whyistha ... online.zip
It has a console (dos window) for the server side, and a program for the client side. It written to work on the 7744 log/text file numbers.
Basically.. Yeh.. I can't remember what most of it does. But its all in the comments.
In short it does this
(Remember, that I haven't written the x3 scripts for this yet, I just made the basic communication program, which is also undone)
X3 script -> logfile -> prog -=-=-> compress to binary level for sending -> server prog -=-=-> formats it back to true form, processes it and then reformats it back into binary to send back to the client -=-=-> client prog -> processes it, spits it into a text file -> game reads text file every.. 1second/what ever
Oh and one last note, this isn't actually related to the x-online the web game. I just couldn't think up a better working title when I started working on this.
Oh and the last last note. The warelist.csv which it may refer to is this
http://members.optuszoo.com.au/whyistha ... relist.csv
-
- Posts: 2033
- Joined: Wed, 29. Jun 05, 01:45
Well I'm back, new pc (<10 fps now
) and I've got time, so I'm starting this up again.
Just a short summary of what progress I had made thus far
#1 A full multiplayer game would use unacceptable amounts of bandwith. As a bare minimum, x y z a b g integers are needed per ship -or bytes/ushort etc. And tbh, it adds up to quite a bit (as the overhead for each packet is like 20 bytes as well). But for efficiency reasons, speed is also going to be transmitted (for extrapolation of x y z, in the event for smoother transitions)
Also there will need to be some sort of transmittion for special actions (buy, sell, shoot, missile etc.)
So yeh, it capped out very quickly (as I come from a land down under, where the women glow and the men plunder, and we all suffer from poor upload speeds of like <10-20 K bytes/s)
I'm considering alternatives (such as instead of using integers across the entire x-y-z space, choosing a fixed reference point, marking that as marker 0-7 (1 byte), then making the x-y-z displacements off that. (e.g. marker is at 100 100 100, your at 0 0 100, your at -100 -100 0 displacement) This will allow for shorter numbers to be sent (e.g. shorts instead of ints) At the cost of several header bytes for the entire sector.
However, it can also cause greater desyncronizations if you lag out for huge amounts of time (but if your lagging for that long... its your own dam problem!) (i.e. if you lag and miss the 0-7 marker updates)
Any way, this idea is mostly just an idea for the future.
#2 Basic communication client
A basic client that can communicate with the game (readtext, log file) with a basic tcp/udp ip connection feature. I'm hoping to make this inherently modular... Although... to be honest... I have little ideas of how I am going to do this. (As you need to be able to customizate how the program interprets the data it receives)
I will probably use a rule based system.
e.g.
You load a rule ... file...
And it goes like this, rule1, first 4 bytes are an integer
*Reads first 4 bytes of data stream, converts to integer*
If integer is xxxx do rule 2, else if ... rule 3 4 5 etc.
And so on and so forth
And then it will spew it to a text file, with page and id (specified in the rule)
etc etc.
Then its up to YOUR game scripts to read the info and do what ever with it.
#2.1 Trade plugin
Trade online with other people
#2.2 Chat plugin
Just a little textual goodness, and possible VOIP
-This is more just because I'm curious as to see whether or not I can do it. I suggest you use something like x-fire if you really want to chat
General note, tcp and UDP use connections over IP, so if you are behind a fire wall, you will need to know how to ... port forward - if your are the server.
Ideas comments suggestions? (Technical insight me~)

Just a short summary of what progress I had made thus far
#1 A full multiplayer game would use unacceptable amounts of bandwith. As a bare minimum, x y z a b g integers are needed per ship -or bytes/ushort etc. And tbh, it adds up to quite a bit (as the overhead for each packet is like 20 bytes as well). But for efficiency reasons, speed is also going to be transmitted (for extrapolation of x y z, in the event for smoother transitions)
Also there will need to be some sort of transmittion for special actions (buy, sell, shoot, missile etc.)
So yeh, it capped out very quickly (as I come from a land down under, where the women glow and the men plunder, and we all suffer from poor upload speeds of like <10-20 K bytes/s)
I'm considering alternatives (such as instead of using integers across the entire x-y-z space, choosing a fixed reference point, marking that as marker 0-7 (1 byte), then making the x-y-z displacements off that. (e.g. marker is at 100 100 100, your at 0 0 100, your at -100 -100 0 displacement) This will allow for shorter numbers to be sent (e.g. shorts instead of ints) At the cost of several header bytes for the entire sector.
However, it can also cause greater desyncronizations if you lag out for huge amounts of time (but if your lagging for that long... its your own dam problem!) (i.e. if you lag and miss the 0-7 marker updates)
Any way, this idea is mostly just an idea for the future.
#2 Basic communication client
A basic client that can communicate with the game (readtext, log file) with a basic tcp/udp ip connection feature. I'm hoping to make this inherently modular... Although... to be honest... I have little ideas of how I am going to do this. (As you need to be able to customizate how the program interprets the data it receives)
I will probably use a rule based system.
e.g.
You load a rule ... file...
And it goes like this, rule1, first 4 bytes are an integer
*Reads first 4 bytes of data stream, converts to integer*
If integer is xxxx do rule 2, else if ... rule 3 4 5 etc.
And so on and so forth
And then it will spew it to a text file, with page and id (specified in the rule)
etc etc.
Then its up to YOUR game scripts to read the info and do what ever with it.
#2.1 Trade plugin
Trade online with other people
#2.2 Chat plugin
Just a little textual goodness, and possible VOIP
-This is more just because I'm curious as to see whether or not I can do it. I suggest you use something like x-fire if you really want to chat
General note, tcp and UDP use connections over IP, so if you are behind a fire wall, you will need to know how to ... port forward - if your are the server.
Ideas comments suggestions? (Technical insight me~)
-
- Posts: 862
- Joined: Sat, 12. Nov 05, 21:53
Well, not to be a disloyal X3 guy, but, doesn't Eve Online already accomplish this, and apparently, successfully?
Personally, I like the idea that this universe is mine, not to be shared with anyone. It's my hood; I can do what I want with it, especially with the help of awesome scripters and programmers such as yourself.
Personally, I like the idea that this universe is mine, not to be shared with anyone. It's my hood; I can do what I want with it, especially with the help of awesome scripters and programmers such as yourself.
-
- Posts: 3120
- Joined: Fri, 5. Jun 09, 18:55
On the other hand if s9ilent could pull off anything at all in this area, that would be a truly amazing achievement. What sort of bandwidth does #1 actually require?
It would probably be easier to do this with X2 or even X:T, but they are older games and the eyecandy is probably quite dated now. Also as they are more hardcoded, it might actually be much harder!
I look forward to see what you can come up with.
It would probably be easier to do this with X2 or even X:T, but they are older games and the eyecandy is probably quite dated now. Also as they are more hardcoded, it might actually be much harder!
I look forward to see what you can come up with.
-
- Posts: 90
- Joined: Wed, 6. Nov 02, 20:31
-
- Posts: 2770
- Joined: Tue, 15. Jul 03, 00:35
-
- Posts: 2033
- Joined: Wed, 29. Jun 05, 01:45
Option #1, requires
20 bytes packet overhead
Ship id, x y z, a b g, speed
So thats 8 bytes per ship.
So lets say.. there are 20 ships? (A conservartive number)
Thats 180 bytes per packet (or "refresh"). So You could say you wanted to update 10 times a second, that's 1800 kilobytes for 20 ships.
So if we want to increase that to something like 50 ships, or 100, the bandwidth goes way over the 3-5kb target that I wanted.
AND THEN, I need more info to show things like HP/Shield change, weapons firing, laser energy, switched main target, etc etc etc. This info will probably take at least 1 byte each. So just x2 on the above numbers.
Idealy thou, it should be;
Ship id, x y z, a b g, speed
And every occasional packet also include: , shield, hull, laser e.g. every third packet.
So thats on average about 9 bytes per ship
And then the special signals (firing, trading, target switch, missiles equipment destruction etc.)
IHMO, X is about having lots of stuff, in a vast open universe. So updating even a single sector will be slow. And for the types of battles that you would want in multiplayer, I figure its going to be one of the following
#1, Restricted battle (i.e. small scale, points/credit system, few ships) Demands low ping, reliability (and I can guarantee neither given the adhoc textfile-logfile system, its ping is increased by the indirect method of parsing data)
#2 Large scale battles. Bandwidth usage will be extreme.
#3 exploring someone else's galaxy. As ping is not an issue, the bandwidth is manageable. However, stations scripted in can not be complex-ed, and "player2" owned ships, may not have the scripts and everything, so they won't really function properly.
20 bytes packet overhead
Ship id, x y z, a b g, speed
So thats 8 bytes per ship.
So lets say.. there are 20 ships? (A conservartive number)
Thats 180 bytes per packet (or "refresh"). So You could say you wanted to update 10 times a second, that's 1800 kilobytes for 20 ships.
So if we want to increase that to something like 50 ships, or 100, the bandwidth goes way over the 3-5kb target that I wanted.
AND THEN, I need more info to show things like HP/Shield change, weapons firing, laser energy, switched main target, etc etc etc. This info will probably take at least 1 byte each. So just x2 on the above numbers.
Idealy thou, it should be;
Ship id, x y z, a b g, speed
And every occasional packet also include: , shield, hull, laser e.g. every third packet.
So thats on average about 9 bytes per ship
And then the special signals (firing, trading, target switch, missiles equipment destruction etc.)
IHMO, X is about having lots of stuff, in a vast open universe. So updating even a single sector will be slow. And for the types of battles that you would want in multiplayer, I figure its going to be one of the following
#1, Restricted battle (i.e. small scale, points/credit system, few ships) Demands low ping, reliability (and I can guarantee neither given the adhoc textfile-logfile system, its ping is increased by the indirect method of parsing data)
#2 Large scale battles. Bandwidth usage will be extreme.
#3 exploring someone else's galaxy. As ping is not an issue, the bandwidth is manageable. However, stations scripted in can not be complex-ed, and "player2" owned ships, may not have the scripts and everything, so they won't really function properly.
-
- Posts: 90
- Joined: Wed, 6. Nov 02, 20:31
-
- Posts: 2033
- Joined: Wed, 29. Jun 05, 01:45
-
- Posts: 3206
- Joined: Thu, 16. Jul 09, 12:24
that's also one of the draw backs to EvE, the battles are slow paced in a sense, some players actually like fast paced battles... sufficient to say EvE is a game for people who are a bit lazy and don't want to die so quickly. I know because I used to play EvE for a bit before it finally got bored for meDominator wrote:Your best bet would be a lan party environment rather than online, only reason EvE was successful was because it's point 'n' click with few key presses rather than full on player flying.
-
- Posts: 2033
- Joined: Wed, 29. Jun 05, 01:45
Ok so I'm about 75% the way there to making a workable prototype online able program.
Basically it's capabilities at the moment will be:
1) Request a pricelist of wares (all, all from maintype, subtypes)
2) Request a purchase/sale of wares, at min/max price, max quantity (And then facilitate the transfer)
With plans for automatic server handoff, chat and other misc things. (this is more for passive connections, not for active connections, i.e. no star fighter duals)
Basically it's capabilities at the moment will be:
1) Request a pricelist of wares (all, all from maintype, subtypes)
2) Request a purchase/sale of wares, at min/max price, max quantity (And then facilitate the transfer)
With plans for automatic server handoff, chat and other misc things. (this is more for passive connections, not for active connections, i.e. no star fighter duals)