doc flabby

Ya that should sort itself out after 5 minutes, it happens if the directory server has to restart because it crashed, there still some bugs :/

UPDATE: After some experimenting at 17th Parallel it became clear there are firewall issues on some servers preventing connection to ssdir.playsubspace.com, and thus appearing on the list Therefore I have updated the directory server software with a "never before seen feature (because the it should never have been needed)" to allow a fixed list of zones to be preloaded. More info: http://forums.minegoboom.com/viewtopic.php?p=80661#80661 I've added the following zones to it: SSCU 17th Parallel|66.36.241.110|5900| SSCU Death Star Battle|69.56.227.178|3600| SSCU Extreme Games|66.235.184.102|7900| SSCU Trench Wars|66.36.241.110|5400| SSCX Chaos/League Zone SVS|66.235.184.102|13500| Have i missed anyone out, whos on one of Prittk's servers and there fore isn't getting updated on the directory listing?

Now i understand the changes i like them Thats still their....Look under game projects General Development is now General discussion

I can't find it...probably being dumb tho

I was going to have level/settings downloads done via HTTP. That way you could host level files on a different computer to the game server, thus avoiding level downloads causing lag on the game server because of people downloading a level using up all the bandwidth (which is why they are so slow in continuum, its by design). Its also pretty simple to implement a basic http server, to have for a server start pack, and port 80 generally is available to all users (www access is not normally blocked). Also it avoids the problem of trying to tie up the UDP connection with a TCP one for each client, which would get complex.

Updated with clock syncronisation

Your description of Trenchwars is how it has always been Whatever your critism of Pure_Luck hes done a great deal for TW behind the scenes, and hes kept it together. The sad truth is there is no one qualified or with the commitment to take his position at the moment. Being a sysop of a zone like TW isn't just about knowing the commands, you've got to manage a team of people.

For a Full description: http://stackoverflow.com/questions/1228545/what-configuration-file-format-allows-the-inclusions-of-otherfiles-and-the-inheri Synopsis Basically I've been looking for a flexiable level format for ages to keep ship settings and other such things that can be used in a heiracical way. Lua seems to be the answer It also allows the programming of custom functions and interaction with C code within the program, which opens up an exciting range of possibilities. It does leave a slight issue remaining, we might not want the player to see ALL the settings when he downloads the level, but we still want those settings to take effect.

re: http://www.ssforum.net/index.php?showtopic=23633 I highly recommend ALL zones ADD: ssdir.playsubspace.com Your Directory server list should read: sscentral.sscuservers.net,ssdir.playsubspace.com Note, do not put spaces in, or it won't work. The main server sscentral.sscuservers.net is currently down. If your zone is not on ssdir.playsubspace.com, no new players can find it. Its in your own zone interests to do this. ssdir.playsubspace.com has been the backup directory server for OVER 3 years, since 2006, its highly reliably, and runs a custom directory server that I have developed and won't be going away anytime soon, unlike the many other servers that have come and gone over the years. http://forums.minegoboom.com/viewtopic.php?t=6430 So if you know anyone running a zone, or have connections with anyone who can get this change made, who has not already added it to their list, pester them, escpially thoses big SSC zones who think they don't have to care about this crap, then start wondering where their population is going

Good point. Which directory server is working these days? The only two left working at the moment are: ssdir.playsubspace.com (mine) sscentral.sscuservers.net (currently down) Incidentally if there any changes you'd like made to the directory server to help discretion, let me know

I think as I understand it, he is allowed to accept the gifts, but he has to pay for them if he wants to keep them otherwise they become property of the United States Government. http://www.reagan.utexas.edu/archives/reference/gifts.html

I cant really see anyone going to the effort of cheating just to see people on screen as opposed to clocked on radar. Its so rare to even bother using clock without stealth

Its based on the MTU of a dial up modem which is 576. which is the smalled MTU allowed on the internet. Once you take into account IP/UDP headers this gives you a max of 508 bytes to play with. I think subgame limits itself to 476 or something similar (maybe trying to be on the safe side?) http://stackoverflow.com/questions/1098897/what-is-the-largest-safe-udp-packet-size-on-the-internet Packet fragmentation is really best avoided with UDP because it can cause alot of packet loss, and it can't be measured. Ill explain why. My House (ethernet) ADSL Router My ISP Random Router Random Router Friend's ISP My Friend (poor guy is on dialup) MTU: 1500 1454 1500 1300 1500 1500 576 Packet: 1500 1454 1454 1300 1300 1300 576 46 46 154 154 154 576 46 46 46 148 154 46 So you can see a single datagram can end up as 5 packets, If just one packet is lost, the entire packet is dropped. All these fragmentations will slow down the packet as well adding latency, some routers will refuse to fragment packets. TCP uses MTU path discovery to find the optimal MTU for your connection, to avoid fragmentation. Fragmentation is a bad thing. The problem with using just TCP (and no udp) is that if you write a chat message, that then loses a packet, all your position packets will be held until that chat message is received by the server, which means ALL the clients will receive the wrong position for you whilst the server is waiting for a position update, because the chat packet is taking up the stream. Of course you could use two tcp connections, but this all begins to add to overhead... I think i need to read more carefully, I thought he was suggesting using TCP for ALL packets....man im so dumb sometimes -_- And as i've discussed in my previous post I'm pretty much agreeing with brain that TCP is the answer for streams

The problem with TCP is latency rather than overhead. TCP can be influenced by certain QoS algos that ISPs use to manage connections which can add alot of latency. Also using TCP at the same time as UDP can lead to weird interactions between the two. Also you can handle a much larger number of connections on the server side using UDP. With alot of connections, each of which is related to one and other in a real time way, TCP becomes problematic. IE if one packet is dropped on one connection, it will hold up ALL the other clients whilst they wait for that packet to arrive. Also from a programming point of view. With udp you can simply have a loop waiting for packets to arrive. With TCP you need to check each individual socket. On a webserver TCP is a perfect choice because each webpage download has no effect on any of the other downloads. In the case of a game. You are directly influencing the information the other clients receive the packets you send. The majority of real-time multiplayer games use UDP as a communication protocol. There is a strong argument however for using TCP (most likely by running a HTTP server) to handle large file downloads (ie level/map/program updates), that occur when the user is not playing as its perfectly suited to this. Also QoS is useful in this situation. For many games TCP is fine, but for a Real-Time game like Subspace, its unfortunately not suitable. If you look at any other real-time game it uses UDP as its core-protocol) Unfortunately this means we have to fake some aspects of TCP we like (ie streams - for chat commands for example) (cluster packets which are incidentally a poor mans nagle's algorithm) Theres a pretty good essay about this here: (read the comments too) http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/ Problems with TCP and UDP interacting (in a bad way) Basically TCP connections causes UDP packetloss, the more connections, the more lag (this is more of a problem on the server side, as the client will only have one TCP connection to the server) Also its why people who download using P2P (which created ALOT of TCP connections) and play subspace end up lagging. http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM But this has made me have an interesting thought, the only packet (apart from the big ones like level downloads) I can see needing more than 512bytes (and thus require the stream protocol) is the chat packet (ok we could do what continuum does and not allow you to send packets that long, but if I want to support Unicode, in some languages that would only give you 128 character to express yourself, that said, we don't want people spamming the whole screen

You missed the deep philosophical point I was getting at

Firstly the current use of 00 as a prepend for protocol packets is very wasteful: If we adjust it so only the first byte is used to indicate the packet type for all packets, we can save space and simplify the protocol: Secondly the current protocol is inconsitant with regards to endianness. ALL Subspace 2 packets are BIG-ENDIAN (network byte order). Packet xx [data] 00-0F Protocol Packets (used for protocol) 10-FF User Packets (user can use) 0x00 Connection =============== UDP is a connectionless protocol. Therefore we must develop a protocol similar to TCP to handle "connections" only in a more optimised way than TCP. This is what the original subspace protocol was designed to do. Using a 4way handshake and cookies, we avoid the risk of connection spoofing. Client->Server SYN Packet 00 01 Server->Client ACK Packet 00 02 [cookie] Client->Server COOKIE Packet 00 11 [cookie] Server->Client Ready Packet 00 12 After the server sends ready packet the client can begin sending data. Any differenciation between client and server ends after this connection sequence. Closing connection (same as continuum): Host A->Host B FIN Packet (disconnect) 00 FF Host B->Host A FIN Packet (disconnect) 00 FF 0x01 Clock Syncronisation ========================= In order for accurate timing (Pretty much identical to the Subspace Sync Packet) A->B SYN 01 20 [A Current DateTime] B<-A ACK 01 21 [A Current DateTime][b Current DateTime] DateTime format --------------- Uses the format from here: http://doc.trolltech.com/4.5/datastreamformat.html struct DateTime { uint32 JulianDay // http://en.wikipedia.org/wiki/Julian_day uint32 Milliseconds since midnight uint8 [0|1] //0=localtime 1=UTC } These packets can then be used to syconise the clocks using this formula. From RFC 2030 Timestamp Name ID When Generated ------------------------------------------------------------ Originate Timestamp T1 time request sent by client Receive Timestamp T2 time request received by server Transmit Timestamp T3 time reply sent by server Destination Timestamp T4 time reply received by client The roundtrip delay d (ping) and local clock offset t are defined as d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2. It also allows us to caluclate the latency of the connection. This feature is also used as a keep-alive mechanism. Failure to receive syncornisation will result in the connection being dropped. Some mainipulation afterwards of the data collected can be used to compensate for lag more accurately, http://www.mine-control.com/zack/timesync/timesync.html Other Packet Types: =================== There are only 3 types of data needed Low Latency (packet positions etc): Datagram Reliable Datagram High Latency (download of level, chat messages): Ordered Reliable Stream Datagram ======== Sent plain using UDP. Starts with 10-FF Max Size 510 bytes; xx [data] Reliable Datagram ================= Sent plain using UDP. Max Size 510 bytes; Data: 03 xx [Datagram] ACK: 04 xx Resends Data if ACK not received xx incremented with each packet sent. Max 128 packets in transport. Stream ====== TBA Gonna finish this later Let me know what you think or any other network improvements you would make.

Heres an interesting thought: I am god. I have the ablity to create, change and destory anything within the reach of my godly powers. Am I religious, or am I infact an atheist as i know no other such god exists?

Wait a couple of months and buy a 1080p (Full HD) the 720s arn't much of a saving compared to the 1080p better value for money... I'm looking for the same thing after my Samsung 32" 720 broke after 16months (4 months out of warrentee :/) Nice 1080p screen: $560 which is similar to what im looking for http://www.google.com/products/catalog?q=panasonic+lcd+32&hl=en&cid=5337893666995629398&sa=title#p

First time it has been mentioned, defiantly worth a look, I'm looking at taking the project in a different direction, This sounds very similar to what I'm trying to to.

Guys read more carefully...continuum already works on this computer..he just wants to improve performance you don't need to do any of that console stuff (referenced earlier) as you already have continuum installed and running, thats just to install it. Try changing it to 16bit or 24bit in the options menu (so it matches the bit-rate of your desktop)

I think it will be successful in its niche (netbooks). The current version they are planning for release is not designed for general purpose computing. The operating system on your mobile phone (The main ones are Symbian, Linux and Windows Mobile) are pretty specialised and on millions of devices. If it wants to make it onto general purpose computers, they will have to make it alot more than just a webbrowser to get sucessful...People will expect the same level of utility they get from Windows, Max OS and Ubuntu Windows 7 is looking pretty sweet, as, i have read you get a copy of Windows XP free with it that runs in a virtual machine, so you can run all your older XP applications with no issues! If they include this, it will be a real winner, at least at my place of work where we have alot of legacy applications, this is the main deal breaker with Vista at the moment, it breaks half our programs....

The game is 7 years old They did the same for Quake, you can get quake 3 free Its also a great way to get people interested in the latest release, playing the old game will leave you wanting more! I love mechwarrior!

The biggest fear I have is NOT the state, but rather pissing someone off who works for the state and then using the tools against me to ruin my life. Think "Enemy of the State" rather than a systematic attack on your personal life. We are treading a slow road to totalitarianism, but thats why you guys have the 2nd amemdment in the US and the separate states. Your guns are to protect yourself from the goverment, not each other This is something i think we are much closer to and far more troubling are stories like these t http://www.gnu.org/philosophy/right-to-read.

You're welcome to rename the other topic to something more positive