L.C.

Alright Smong. If nobody cares to finish this project, then I'm abandoning it (and hey, people were wanting and expecting this for their zone).

The 3D radar is certainly doable is designed right. It's pretty much a camera inside a sphere 402638502618356 units away from the center of the map, just far out in some random void that players can't even reach. One of the things that Thirdspace might "generate" (or that compiling tools could also do) is to produce the 3D radar cache; basically it will replicate the entire map into a tiny mini-model and remove all textures from them. Then it will use as simple rendering techniques as possible (and to mention, efficient also) to color them accordingly (blue for doors, gray for walls, green for safeties*). The radar camera pretty much uses a FOV to create the "getting smaller" effects. This little inversed-sphere room that the tiny-mini-model of the map is in is pretty much a "transparency" (it will appear 100% transparent on the radar) and has a little fog of its own (fades to "transparency"). It's doable, and it could work extremely well if designed and executed correctly (or properly?) *This reminds me. There could also be a brush-based en!@#$%^&*y "safezone" - you cover whatever space or region in a map with this brush, and players that walk into it are protected by the "safety zone." It is up to the mappers discretion to decorate this space/field/region to indicate it is a safety zone. EDIT :: Since 7z is an open source archive format, is free and has very decent compression, perhaps you could store uncompiled/compiled maps, their custom textures, sounds, graphics, etc in .lvl (*.7z renamed to *.lvl, openable by 7z program). Thirdspace could download just this file, validate a checksum against the server's to make sure that it isn't altered or anything, and then load the contents inside. If no custom textures were used, but the ones included with the game, Thirdspace will load up the existing defined textures that were used in the map. If there is a missing texture, then Thirdspace will load up a special (hard-coded?) texture to use as a replacement for missing textures. ie. Half-Life and Half-Life2 has a pink and black checkerboard texture for this.

Allah Akbar.

No, just coding. the HTML/PHP side of things is pretty much done. Smong has been waiting for a long time for the or a coder to catch up so that he could sync his PHP with the coding.

http://forums.minegoboom.com/viewtopic.php...&highlight= allshallperish has left the building and is busy with school (he has no time to do it). I need a coder, and I want to get this project finished. Smong will be paid his promised $25 upon completion, and you will be too if you want the money.

Well jabjabjab agrees, so I think that settles it Mill. . Just kidding Mill. Hope you make a decision of some sort though, atleast. http://www.hlrse.net/Qwerty/tsturret.png

Don't. I'm not even close to talking about engines. *.map is a human readable format. All ya' gotta do is have your engine be able to read it properly. You can hardcode the the values/variables for the FGD that would be used with Hammer. Now look, if you do this...then I will be more overjoyed than I've ever been. I'd even be willing to teach people for a while for the sake of strong support. My analytical mind tells me that this *.map/lvl post I made outweighs Milkshape in far more important points. Modeling is harder than mapping in Hammer. Hammer is like modeling, but not exactly. Milkshape is modeling. In Hammer, you can select faces (to modify texture properties), create lines through vertex selection (or split faces into more faces, pretty much), select vertexes. In Milkshape you can't do that, which brings Milkshape down to total crap for mapping. Modeling and mapping should be separate in this case. Leave modeling to modelers, and maps to mappers. Hammer is extremely easy to use and learn, while Milkshape is a complete pain in the !@#$%^&*. It's very difficult (maybe not even possible) to select a specific pair of faces on a complicated and manipulated cube (which is now not a cube) on the other side of the whole object. Secondly - with MS3D you're making it more tougher than it should be...for yourself and everyone who approaches it. You listed to me what models Trench Wars was composed of. So now you're telling me that basically there is this kind of file where you define the origin of each of these models. That's totally unnecessary. Even C&C Renegade maps are constructed in one huge GMax file (a clone to 3DSM, which I'm sure you know lies along the basis of modeling; mind you that there are VERY FEW mappers for C&C Renegade because Westwood/EA based it on modeling; it isn't easy to learn it). Another terrible feature of MS3D is that you can't zoom out as far as you want to in the 2D grid views; there's a terrible limit. You can't even zoom out enough to get a whole view of the Trench Wars base from top view. The camera functionality was designed for modeling, NOT mapping. In Hammer, you use the classical WASD, Arrow Keys, and mouse to move around -- FPS styled camera, ftw when it comes to mapping. Sure, it may be easy to have MS3D implemented in the engine, but it certainly isn't worth it for the long run. The *.map/lvl idea would work very nicely in the long run. The limit? In technical terms you shouldn't even have one - leave it to the "as long as your computer can handle it" phrase. For graphics settings, there should always be a kind of fog of war built in, regarding maximum visibility (for example, Battlefield 1942, Battlefield 2, etc). The radar should attempt to draw the walls. If you use brushes, it would be easy for the engine to properly draw any wall in the radar. You should clone the original radar from Subspace/Continuum using the old graphics (temporarily, and for a "classic" skin -- which then you can remaster the graphics to a "modern" or "default" skin). The radar this time should be a miniture Camera, basically. Read on to the next paragraph. Imagine a medium sized cube in the map, perhaps 128x128x128 in size. Your radar is like a finger; the origin of this imaginary finger is the center of the finger (insides) and at the end of the finger (other end -from- the finger nail, the part that you s!@#$%^&*ch onto the hand). The origin of this finger is at the origin of the ship [model]. It points forward (ie, the warbird - the finger is aimed at the nose of the warbird). This radar will render in 3D. As you fly around that cube, it rotates accordingly in your radar. A ship on the radar might be a sprite. Since this is just a cube, it will be gray colored in the radar. Now add shading (we don't want the 3D stuff in this to be full bright, but very much shaded so that it becomes a no-duh when determining which side is the closest to being perpendicular to that finger). http://www.hlrse.net/Qwerty/tsradar.gif I think my illustration says it all (regarding the radar). Would be very nice to see a fully restored HUD/GUI from Continuum and Subspace, even the chat! Mill, if need to be, we should talk (through AIM/MSN/YIM/ICQ) more about *.map/lvl.

Screenshots really don't prove very much. It isn't very hard to alter them. I've gotten over 40,000ms on dialup some few months ago. :\ Wasn't cool.

lol. By the way, MP3 is open source I believe. Ever heard of FMOD? FMOD allows MP3 support. No license required. Milkshape is a piece of !@#$%^&*. Get a better format for levels. Man, even give Valve Hammer Editor a go. Brushes are very easy to work with. *.map is a human readable format (RMF might be open-source or something). If you take this into thought, you could even create a little compiler for *.map that basically optimizes the file and renames it to something like *.lvl. Follow the Half-Life style; have FGD and MAP->LVL support. A FGD would contain all the en!@#$%^&*ies for point and brush based en!@#$%^&*ies. Point based en!@#$%^&*ies are like light spots, light (sphere-style), or an environmental light (global across the entire map). Nothing fancy at all. It is completely possible and doable to make a FGD that isn't really usable by Half-Life or a Half-Life mod. Infact one possible advantage to this is that you could allow mappers (for map properties, aka "worldspawn" en!@#$%^&*y) to put in a passcode that would allow an Official Thirdspace LVL decompiler to decompile it. Prevent map stealing, eh? 3D work becomes more of a value to mappers than it does 2D maps (based on witty tiles) in Subspace. generic (brush) door (brush) door_rotating (brush) light (point) light_environment (point) light_spot (point) model (point) sound (point) spawn (point, not required) sprite (point) teleport (brush) teleport_destina (point) trigger (brush) worldspawn (point, not included in FGD, you goto Map Properties in Valve Hammer Editor) generic - applies for any or all brushes. Use this to control the opacity/transparency, illumination, color, etc of a brush. Even styles such as imitating a door fade-in-fade-out effect. door - Obviously a door. Ability to set opacity/transparency, illumination, color, etc. Possibly even set that it has to be triggered by a trigger_button or trigger_field. door_rotating - Also a door, but has the special ability of rotating around the brush origin or an !@#$%^&*igned origin on the x, y, or z axis. light - Featuring the color of the light, brightness, intensity, maximum light distance (can be as far as it needs to go; can set whether this is the border and it will fade the light to the border or nastily "freezes" or "stops" the light at that point). light_environment - Same thing as above but you can define the XYZ angle that its pointing towards. Kind of like a sun; it will light the entire map in a linear form, just like the way the sun lights the earth. light_spot - Same thing as above, but is more like a like. The difference is that this point en!@#$%^&*y is the origin of where the light is being casted or shined from. model - Browse/indicate which model will be in the placeholder here. Can be a Milkshape file (which makes this all the more easier). Can control the opacity/transparency, color, and brightness. sound - Define a sound file (*.wav, *.mp3, or *.ogg). Then set its maximum distance (and be able to set whether the volume fades out the farther you move away [aka move towards its max distance] or rudely toggles on and off), its initial volume (scale of 0 to 10). spawn - In case someone wants to have fixed spawn points, wherever these are will be where players spawn or warp. In the settings you can define whether players warp perfectly and precisely at this point, or spawn randomly within a specific range (this is in the arena settings, not en!@#$%^&*y properties). In the settings you can also disable whether players ever spawn at these en!@#$%^&*ies. However, this would be very effective for a *warpto shortcut; ie. *warpto baseTrenchFR sprite - Define the destination of a sprite. Be able to set the opacity/transparency, brightness, color, and framerate. teleport - If a player runs into this space, then they are warped to this en!@#$%^&*y's target (it can be teleport_destina or a spawn) teleport_destina - This is the "exit" of a teleportal field. trigger - Be able to set whether this is triggered by touching or bumping into it, shooting it, shooting a bomb or gun, or projectile. It will target whatever is specified. You can create a field using this brush based en!@#$%^&*y, where if a player flies into this field (they'll go right through it by the way), then it will trigger whatever you specified. The trigger en!@#$%^&*y has a "Target" field. All en!@#$%^&*ies have a "Name" field. Thirdspace would dynamically render or generate lightmaps. Unlike Half-Life maps, there wouldn't be a need for compiling lightmaps. Thirdspace should be able to execute *.map and *.lvl, but must use the proper FGD in order to load/player in the map correctly (trying to load Half-Life *.map's might be cool and weird). As for textures, there are two methods that can be chosen (forced or free decision): (1) have all textures contained in WADs for Thirdspace, (2) have all textures be contained inside a textures folder as raw TGA/BMP/PNG/JPGs, but require the mapper to put them into a *.WAD for editting and making maps in Valve Hammer Editor. Sprites could be multiple textures with a special prefix in their filenames. For example: -0test, -1test (-0 is the first frame, -1 the second; any texture on any brush can be animated as long as...) One thing that I forgot. For all brushes you can set whether the textures on its faces are animated or not, if possible. For most of these en!@#$%^&*ies, the mapper should have the ability to decide whether they are turned off at first (which would then require them to be triggered to turn them on). There are a few special textures that Thirdspace will interpret differently. A texture !@#$%^&*led 'null,' and 'function.' Null simply tells the engine "don't render this face." Function does the same, basically, but is there to seperate nulled faces from brush-based en!@#$%^&*ies like trigger (that might be an invisible field or space of area that a player would have to fly into to trigger). When Thirdspace loads a *.map, it will do atleast a few things that compiling tools would: it will generate a resources file that basically contains locations to all the images, textures, sprites, models, sounds, etc used in the map so that next time it won't have to figure it out from scratch, but would be able to preload all those resources into memory in the loading process as quick as possible. It will also "generate" all the nulled faces; next time the client wouldn't have to calculate all the faces it shouldn't render, so that it will effortlessly not render those faces. Difference between Thirdspace generation and compiling: when you compile, you save the time of having to generate anything in Thirdspace and do it for you, plus have the additional feature of having your map optimized (filesize-wise). Because this reply is so enourmas, I can't think of anything that I've left out. A FGD isn't that hard to make. One big PLUS to using *.MAP/LVL rather than Milkshape files is that it is far easier to learn and handle than it is modeling. One disadvantage though is that you can't make spheres very easily (even if it is a geo-sphere) in Hammer v3.4/3.5b - but if you ask me, after weighing the advantages and disadvantages, this would be better than using Milkshape files. One advantage of this versus Half-Life is that you don't need to have a skybox in the *.map/lvl, as Thirdspace automatically handles that stuff. However a player could make an invisible wall to create map borders. Player sizes in the grid (for an average Subspace ship) could be something like 64x32x64 (64 in length, 32 in heighth, 64 in width), which is far from hard to remember. A mapper would have to play around with this if they used a custom model exceeding these limits (or was smaller). NOW I ran out of things to say.

Mill, what are the filenames for the levels? The way I like mapping sometimes is having the game and editor open at the same time; I modify something in the editor, save, then quickly load it up in the game to see what I've done. Then disconnect, make minor adjustment, save, loop. I want to experiment with the mapping and do something.

I just made a large update to my last reply (Post #168). Be sure to read the new content. By the way, I realized that having the levels and such in a Milkshape format is..well... I was able to open and edit any of the models/levels as I pleased with Milkshape (I've got registered v1.8.1) -- which was very convenient and nice to see. However there are many disadvantages also by using this method. Let's make a quick talk about doors - they can be done. Either as literally "lasers" (like in Half-Life) or transparent walls/brushes that fade in and out (not completely) that at some point fades out completely to allow passage (and after x amount of time fades back into its fade-in-fade-out cycle [this cycle doesn't fade in or out to 100% or 0% opacity, but the fades alternate from some 40% to % in smooth blending]). You REALLY need to get a video card, even if its a GeForce2 MX220 on a PCI slot. That graphics accelerator was far from designed for playing any 3D games. If your computer can't handle Thirdspace, it wouldn't even be able to handle Half-Life on the lowest resolution of 640x480 @ 16bit. Software mode on those settings would even be chuggy for you.

Which also means the netcode needs optimization. O_o By the looks, I honestly don't think any lower than 56k to 112k is all it takes to play with a few people. You should check out the netcode (indirectly) for Half-Life, as it is very well made and is a good example of what 3D netcodes should be like in my opinion. cl_upspeed rate cl_rate fps_modem sv_sendvelocity sv_maxrate sv_minrate There's a few more commands but I'm too lazy to look them up. Compared to Half-Life2, Half-Life2's netcode to Half-Life is worse. Not as flexible when it comes to configuring it for dialup play. I strongly disagree for the support of DX10. That's like trying to force everyone to upgrade to Vista (which we all know is a total piece of sh*t and has no or ultra terrible backwards-compatibility...and is an eye candy and memory-hogging operating system -- my cousin bought 2GB more RAM for his laptop, which already had 1GB, and that STILL isn't enough for his Vista). DirectX7 is more than capable enough to handle all the graphics that are displayed in Thirdspace as we speak. Thirdspace won't get very far if it's overally "restricting" or "forcing" users to DirectX10 systems. If you plan on having DX10 support, I would strongly recommend that you atleast implement either DX7, DX8, or DX9 - or possibly all three stages. It wouldn't be a wise business move to make by not having proper support for the majority of players. However, DX9L is a work in progress I believe and is equivilant to DX10, but for Windows XP. Probably the number one reason why. I would recommend getting more RAM. Windows XP. I experimented with the Weasel for about 30 to 45 minutes; on my end I can confirm that the analysis I gave on the weasel (of when it does and does not work/produces a crash) is correct. Bots + Weasel = Insane Potential for crash; if no bots are in a weasel but you are, as soon as you start moving around the client crashes. You can shoot and do whatever you want as long as you don't move (and by not moving I'm only using CTRL, TAB, and the mouse itself [discluding right click/thrust]). Obviously bots can't sit still very easily, so as soon as one hops into a weasel the game will crash. If you turn off bots altogether than you can use the weasel to its full (100%) potentials. EDIT :: Hosting zones, billers, bots, etc really shouldn't consume much bandwidth. C&C Renegade for example - its netcode is quite efficient for a 3D game (featuring helicopter-based aircrafts). I've seen 64 player servers with perfect latency. The only thing that held anyone (the server or player) was whether the player's computers could handle it or not. I personally prefer the idea of "as long as my/your computer can handle it" limits. Someone with a very high-end machine would be able to exceed the "limits" of the average gaming computer, why lock it out? Unlocked ftw. Shouldn't be limited to everyone, but as much as any person wants it (and to them, it's a situation where they figure the limits of their machine). C&C Renegade can handle up to 128 players; all that matters is whether players' computers can handle calculating that many players, whether the server can handle it, and whether they all have enough internet juice to handle it. THAT is a good limit. PriitK could have made the netcode for Continuum to use a high amount of bandwidth per player, but he didn't. Continuum is very compatible with dialup. The more players that are within a dialup user's visibility, the higher the latency for the dialup player. For a game like Thirdspace, I see no reason to have some of the current limits. If some of the current limits are there only because of the netcode - then the netcode can be rated on a scale on 1 to 10 (10 being a very terrible netcode). For some reason I'm having a massive amount of difficulty trying to say exactly what I'm trying to describe in a few words (ie. last night I couldn't remember the word replicate, but kept thinking recreate). A netcode should only be what needs to be/happen. Eh? Take Continuum's client-side and server-side netcode for example. All that has to be done is really to fight cheating, which shouldn't be a big deal after a presentable and ready-to-start-relaxing-more release. EDIT2 :: I should (or must) mention that before I went to bed last night, I had found out that I didn't quite install DX10 - as I was missing a key file that would get DX10 working altogether. So anything that I've said before this time of edit was on DX9c (Dec 2006).

I'm using Windows XP and an nVidia Zogis 6800XT (DX9c, Overclocked) with DirectX9.0c (December 2006) and DirectX10 installed ("unofficial" installation). Works perfectly fine if you have bots turned off. Would recommend replacing nightwasp.txt with weasel.txt; the latter the ships (closer to Ship the less bots that will be up that range. Start Multiplayer with no bots and you shouldn't have a problem with the weasel. Turn bots on -- and if you move your ship (or a bot gets into that ship and moves) then your client crashes. Shooting does not cause it to crash. After a few seconds of gameplay is because a bot probably happened to jump into the weasel and start moving it. I don't think it was meant to be DX10 only either, by the way. If you take the DirectX10 files and pop 'em into your C:\WINDOWS\system32\ folder, they seem to work backwards-compatible with Windows XP quite fine. (Many months ago there was an article on the frontpage of Slashdot regarding this.) Mill, I hope that eventually you'll be restoring (or importing) a clone of the Continuum HUD. Trench Wars map is really messed up. 1680x1050 Widescreen http://www.hlrse.net/Qwerty/ts0000.jpg http://www.hlrse.net/Qwerty/ts0001.jpg http://www.hlrse.net/Qwerty/ts0002.jpg http://www.hlrse.net/Qwerty/ts0003.jpg http://www.hlrse.net/Qwerty/ts0004.jpg http://www.hlrse.net/Qwerty/ts0005.jpg http://www.hlrse.net/Qwerty/ts0006.jpg Made a 640x480 recording (SATA-I sucks; it is pretty much the same thing as a regular IDE). If I had a camera I would have produced a 1680x1050 recording @ 30 to 60 fps. http://www.hlrse.net/Qwerty/ts0000.wmv (NOTE: Don't even try to download this until 4 hours have past from the time of this edit)

You can play in other ships such as the Borg, U.S.S. Enterprise, F30X Class Fighter, Dummy Plane, Spectator, Voyager or the disabled Weasel. In order to do this you must go to your \Thirdspace\shipdata\ directory and edit your shiplist.txt file. Just replace any of the 8 ships displayed in shiplist.txt with anything in the following list (in the same given order): borg.txt (Likely to crash client) F304.txt (Incomplete model) plane1.txt (Very easy to maneuver and control; thumbs up!) spec.txt (Invisible, invincible, and can kill using bombs and missles; bots try to kill you anyway) voyager.txt (Very big yet easy to control, poor camera positions and hard to move around small obsticals; strong on bullets I think) weasel.txt (Easy to maneuver and combat in) You can add custom resolution dimensions to Thirdspace by editting resolutions.txt and restarting Thirdspace. It should be very much self explanatory on how you would be editting this file. You should first realize how and where to change your resolution in Thirdspace before editting this file so that you have some awareness. Controls (TSConfig.xml): 1 - Offensive Modes 2 - Defensive Modes 3 - Flight Modes Tab - Bomb ~ - Toggle Scores ` - Toggle Scores Left - Roll Left Right - Roll Right Up - Forward Thrust Down - Reverse Thrust T - Target Lock V - Change Camera Escape - Pause R - Fire (Special) Control (CTRL) - Fire EDIT :: Crashed on weasel when I moved it (thrust). EDIT2 :: Second time client didn't crash at all. Could use Weasel completely without a single problem. First time (above edit) was with bots, this time I did it without bots. Mind you that I'm running Windows XP with DirectX 10 installed (not Microsoft approved ). EDIT3 :: Ya, I can confirm it. I confirm that somehow Bots + Weasel (atleast you using it) = Crash. Without bots the Weasel is perfectly fine.

Lower the resolution the game wants to play in or set one -- do this in Options. Having two different menus/GUIs is confusing (the in-game one and the Windows GUI one). No doubt you will, but it is kind of funny to play with the arrow keys and the mouse while the tab button fires thors and missles. Ironic, eh? That stuff is awesome. For nearly 3 hours now I've been downloading TSinst.exe off of HLRSE (88% complete as I write). I'm imagining the day where Thirdspace GUI will be nearly a perfect clone of the Subspace v1.34 (of course with some minor imperfections from the process of replication). The oldschool nostalgia feeling (and style ). Some parts of the work shouldn't be as hard, since you can just rip some of this data straight out of the *.dlls of v1.34 (such as the coordinates and sizes for textboxes, each window, options windows, etc). Sorry, just a bit excited. :]

Question whether it would be free or not hasn't been answered, but I presume and hope it will be free to play. I'm expecting your release soon (Saturday?). Curious to know what it turns out to be and how similar or comparable it may be to Galactic Melee (the "Melee" part of that game is ugly).

Mill, you really need a seperate website and forums for Thirdspace. Bug reports might get messy. First thing I noticed that would be real nice is if I could configure the keys myself. Kind of annoying having to use arrow keys + mouse. Usually I used WASD and Arrow Keys for aircrafts (ie. Battlefield 2 aircrafts). The mouse isn't particularly my thing for flying aircraft. D: Second: remove the maxplayers limit. You can do this in a few ways -- "Auto" (something you can check/uncheck, or is a button) the client would make a few calculations using a tested upstream speed and automatically set that as the maxplayers. If you try set maxplayers to 0, it would basically mean that there is no limit. Or you could set the maximum to 128 or 256 (read next paragraph). In the future you should probably lift the arena size limit altogether (or increase it by 10 to 100+ times the current radius). Graphics Settings: Texture Quality: Low, Medium, High, Ultra High Model Quality: Low, Medium, High Antialiasing: (autodetect or..) 2x 4x 6x 8x 16x 32x Anisotropic: (autodetect or..?) Maximum Visibility: xx% Something like that..maybe some more stuff (such as mouse, keyboard, joystick sensitivity). Music and SFX volumes. Maximum visibility would be an atmospheric fog (fades player ships out to the background/structures/etc - basically controlling the transparency of the ships until it his 100% transparency, which it then completely cuts out of the net and rendering process [z maximum]). Tried this on a computer with 320MB RAM, 1.6GHz CPU, and I think a crappy Radeon 8500LE (not sure, might have been a card far worse than that). Pretty chuggy on 640x480. Though most modern cards (mid-ranged included) should be able to handle it. Tried it on my cousin's laptop (wasn't designed for gaming) and works perfectly on 1024x768. Still yet to try it on my PC (1.5GB DDR400 PC3200 RAM w/ Dual Channel, 2GHz AMD Athlon XP [maxed out on SocketA clocking], nVidia Zogis 6800XT Overclocked [with huge 3-PCI heatsink + heatpipes]). When you first launch the game, it would be nice if there would be a proper window around the menu (so that for example, I could move the window around on my desktop, rather than it being locked and occupying the center of my screen). In my opinion you should just go ahead and use the menu animations for ships 1 through 8. For the wasp, it may require some "reverse engineering" ( ) to replicate the animations (or photoshopping). Just open some of the files that come with Subspace v1.34 in a resource editor to get the original animations -- but I think you've already got that part long long ago accomplished.

Yup. You've got my support; if you ever run out of bandwidth/get close to it, I would just give you more for free. ;o You don't pay anything (except for the yourdomain.com if you're going to do it that way; otherwise it is ________.hlrse.net). Mirror: http://www.hlrse.net/files/Unrelated/Thirdspace/TSinst.exe

Which is why it doesn't go well with any resolution. I've never seen a resolution that was square. I've still yet to see one... O_o Oh. Then that's cool. :] Kind of Halo, where you can choose the flag that is embroidered onto the shoulder of the suit/armor. Now support for PNG and BMP would be real nice. You really have to be careful with what formats you choose, like GIF (as it has been known that malware could be injected into images and be executed just by looking at the images). JPG and JPEG might work too. GIF is nice but if it weren't for the past exploits with this format... *fades out*

I think you should keep it proportioned with 16x14 atleast. I think that if you have too many things squared it becomes a wasted space. Screen resolutions aren't square either (1024x768 instead of 1024x1024 or 768x768). You might even want to even consider a 4:3 ratio (8:7 is the traditional ratio). Time saver: 8:7 Traditional 16x14 32x28 48x42 64x56 80x70 96x84 112x98 128x112 4:3 Native 16x12 32x24 48x36 64x48 80x60 96x72 112x84 128x96 Probably wouldn't recommend doing a 16:9 or 16:10 ratio. Not sure how I could explain it to you why I say that 128x128 would be worse than 128x112 or 128x96; just an internal feeling -- a kind of knowing that 128^2 just doesn't feel right as a banner for a game like Subspace. Works in social community sites and avatars, but when it comes to signatures (which is kind of what a banner is, although this thought could be debated against avatars) images should be slim vertically and wide. I mean, 128x128 is quite awkward... :S If you still haven't found my perspective here, that's ok.

Bump. Status?

What will happen to Continuum even after those updates? The updates are primarily focusing on just stopping cheating, but not adding new features. Like PunkBuster for Continuum; atleast there won't be as many people to ban. Continuum will still decline as normal, don'cha think?

You forgot the Server Kit. X_x http://www.hlrse.net/subspace/ServerKit-Full.exe

So, is there any public changelog available before it release?

Where did Ghost Ship say that? All of a sudden I'm confused.