L.C.

Mill will probably (and obviously?) eventually fix whatever needs fixing. I find that ESC + # would be the most logical shortcut. Also known as a directory server. If MillenniumMan makes a simple and stable Directory Server for Thirdspace, I'm volunteering to host it on a high-end Dedicated Server (see System Specs page at hlrse.net). :]

Hmm, what would also be cool (for different "maps" or "arenas") if a mapper could decide whether it be space-based battle or planet-based. Planet based is the same as space based except with gravity, collidable terrain, etc. Maybe a whole planet you can fly around on or something...or mapper-set boundaries. lol.

JabJabJab, oh you're such a suckup. Sorted by "ugliness" of name to the least (or most prettiest): ASSS/!@#$%^&*S, CNL, Continuum (honostly), Thirdspace, Subspace. Actually I don't know about Continuum and Thirdspace, seem like they tie to me.

Oh by the way, regarding the GUI, is that temporary or do you plan to atleast have a "Classic" skin with the old Subspace/Continuum GUI and graphics?

If Thirdspace turns out like the Subspace Intro, then I'll be entirely convinced. -_- I've asked a few people around, and they and I would want to play the Subspace intro. ;P JabJabJab, you can't win on this Post-War!

Sorry. I suppose if TS turns out very much accepted and approved, it could be worthy to take on the name of Subspace2? Some of the lighint on the Warbird looks a bit ... well ... the warbird in your signature looks better.

Er. MillenniumMan, lookup "Thirdspace" on Wikipedia. :S

That's the problem with Continuum nowadays. PriitK should just get back onto his arse and "unlock" Continuum to give it a few more years. All the limits we now know (in my opinion) are too small. You would probably disagree, but the 190/256 tileset is way too small, and so is the different special effects that you can assign to a number of tiles (it would be nicer if the mapper could just choose one), the maximum map, news, graphics, and LVZ filesize limits, the fact that the news is plain/rich text without any support for some decent limited or restricted HTML (maybe even BBCode with some things like [backgroundcolor]), more than 256 maximums, etc. Perhaps "unlimited" as long as the machine can handle it. He should even add in an entry to the server.ini that could control maximum Subgame upstream and downstream speeds, and maximum upstream and downstream speeds per user, and even just a simple HTTP content server ability (this would be more efficient than Subgame, because then Subgame might be losing precious bandwidth to downloaders while peole might be playing).

I think overall vBulletin is far greater than IP.Board. IP.Board might be just a bit more user friendly, but the difference should hardly be too much. The Sven Co-op community never seemed to have any problems with their copy of vBulletin (I've been in that community for atleast 5 years). When it comes to IP.Board, I literally always see some kind of problem with the boards popping up every once in a while and stuff. :S My primary reason for going to vBulletin over IP.Board if I were choosing for Jackpot SVS would be that vBulletin is simply better, less ugly, more professional, cleaner, optimal (this could be argued very easily, not something I want to go through ), etc. I found vBulletin very easy to use and a breeze, while delivering an all-around, quality, and professional spectrum of being a forum. My penny. :X

Alpha Release: Video:

k that's not what I meant. Nevermind about it. :S I was being very vague. Don't you think it'd be worth it for having the ability to have whatever effect for whatever tile you want? The last part of your reply kind of confuses me. :? No hard feelings, by the way. :\

EDIT :: Nevermind about Cube2. Forget that. The video is just... wow. Oh my... *jaws dropped* Even though the FPS and quality wasn't the best, that looks almost and very much like VIE-styled work, and quite an accurate portrayal too! The content of that video was just that good that I didn't even finish watching it. Work it Mill! Work it! (Even though your Alpha release wasn't intended and was somewhat relieving to some people here, I think you shouldn't release anything except videos and pictures of development until you can get to a stable and sturdy release point). Man, when I get home today I'll have to make a website for you/Thirdspace... Now I just gotta get design ideas. EDIT2 :: Got any screenshots to show, Mill?

Not like I think you would switch engines (which I would imagine being a very exhausting and difficult task to port from one engine to another), but have you heard about the Cube2 engine, Mill? :X To me that looks like a pretty large engine base to start anything off of. Or maybe a few examples/snippets from the code? Heh. I think you know better. EDIT :: Mmmh. *downloads 3rdspace1.zip*

Not unless you used all 1048576 tiles up. If you drew a lines in the middle of nowhere that is 1x16 (units) and is AfterTiles, then it would make a single screenshot of it. And depending how far away you make another structure/object, it might decide or not to include that in the same image. Indexed Colors on GIF makes decent compression (but isn't always the best extension to use), and since we're mostly dealing with 256 colors it also makes a big plus. Of course it is, but I partially disagree for the fact that about 95% of those extra tiles are 100% useless. Only a few of them can be used for their special effect (although brick and prize has a tile graphic of their own). As I recall, you (or Samapico) had told me that it isn't possible to change this. Maybe you should just cut out the majority of the useless tiles in the extra tiles to reduce the size of the tileset in DCME. You wouldn't literally have 20 1024^2 images. DCME would make the images as small as possible by cutting out unneeded margins of pure black (unless there is a tile in there with Translucancy turned off / Opacity on) and saving it in 1 to 3 different formats (hidden; only might do this for filesize and quality comparison). Some people would rather spent extra bytes to have greater performance and abilities (such as being able to assign an effect to any tile on their tileset, which is the way it should have been done in the first place). Optimization. DCME cuts out unnecessary parts of the image and does whatever it can to get the best quality and best (lowest) filesize. Whatever. I need a lot more than 128. The complaint I've had personally for atleast 5 years has been that "128/256 tileset is way too fricken small; I need more tiles with different effects!" Since when did you and Samapico actually start playing Subspace/Continuum and getting to know everything about it? :X (I don't doubt it, but the last time I saw a response to this was that you guys didn't know too much of anything in Subspace, but atleast enough to start off a simple map editor.) Atleast give it an experimental try. -_- If you've got nothing better to do and is too lazy to fix some bugs and glitches...

Oh that's right. Forgot that I didn't abbreviate anything when I made those webpages. http://www.hlrse.net/hostingplans.html

Maybe in the future to support something like *.MDL? I'm thinking of a directory structure like this... / = /Thirdspace/ / /textures /models /sounds /zones /maps /shaders A folder in /zones/ might be structured like this: / = /zones/SSCI Dragonball Z/ / (would contain possible scripts, xml, news file, F1 or commands.hlp file, LVZ2, stuff like that) /textures /models /sounds /maps /shaders LVZ2 could be like ripenting a Half-Life map almost. Or maybe the compressed content of the above folders. Either way: (1) could be just LVZ2 alone and be loaded by Thirdspace, (2) could be LVZ2 that would be decompressed and extracted to folders for possible and slight increase in load times, (3) could just be raw data in the folders. 3 would in inefficient. I'm not sure if 1 is as efficient as 2, but either 1 or 2 would work for me. X-P Shaders could be in this kind of form (Shadowgrounds uses this; diffuse_pixel_shader.txt): ps.1.1 ;def c0, 0.25f,0.25f,0.25f,0.25f ; Diffuse texture p!@#$%^&* tex t0; Diffuse ; Clamp add r0, t0, c0 sub r0, r0, c0Though of course it would require more technical experience, which I don't mind. Shader coding is not my business. -_- Scripts and Shaders could be taken to advantage to create different kinds and varieties of thrust and thruster trails (ie. Snowboarding games, when you are leaving behind a decal that looks like you glided over the snow; maybe stuff like this). Or perhaps to eventually imitate a Freespace atmosphere (man, when I first saw that game years ago...it was the most beautiful space game I have ever seen). I personally hold Freespace and Starfox 64 as a role model for a 3D Subspace. Both like SF64 and FS; pretty graphics, effects and space atmosphere (FS) -- spaceship and control, perspectives, camera action (SF64). Hah, you would just need to combine Freespace, Starfox 64, and Subspace to get a 3D Subspace almost. Then again, is Thirdspace going to have stuff like billers, zones, directory servers, etc? Or is it going to be like most FPS games where someone hosts a server to play in? EDIT :: Bleh, sorry about this post. :\ I get adrenaline rushes and excitement when I see something like this go into a bit of motion. ^_^

Crowd: FIGHT! FIGHT! FIGHT! I'm ok if Mill chooses your hosting. By the way, where's your webhosting page and what do ya' offer? http://www.hlrse.net/hostingplans.html is mine. -_-

Well, yup..you guys did miss detail. I think I later mentioned that a better idea instead of 16x16 tiles and hundreds of entries was to take screenshots of the entire map for each effect, then split it into smaller images if necessary. Load up a single LVZ as much as possible before making LVZM1, 2, 3, etc. Post #3 It can be done. Forget about the whole 16x16 per tile/per lvz/per whatever thing. EDIT :: And to mention that not only would it be more FPS efficient compared to normal mapping, but it would be more efficient than to have all your tiles as a 16x16 image per tile in the LVZ. I would find it a bit hard to believe if it couldn't be done in under 256 different images like this, especially if you're using somewhere between a maximum of 768 to 1024 squared screenshot/image sizes. Look at my example LVZ-map to get an idea what I mean. If you haven't looked at the LVZ Map Example I gave and read the above details, then you're outdated from this topic. Catch up. EDIT2 :: If you think 128 customizable tiles is enough, then that's you. For ages I have been wishing for more tiles. After gaining access to the next 128 through DCME, that was only part of a relief...until I found out that you can't customize those tiles, which makes almost all of the extra tiles 100% useless. This is for the sake of efficiency, variety, and larger and more optimal tilesets. If you made a small base entirely of Solid LVZ tiles that is the size of 1024x1024 pixels, then what DCME would do is take a screenshot of that base as a 1024x1024 image and turn it into one LVZ graphic. Then it would do the rest of the compiling that needs to be done. -_- I feel now that I have fully clarified this well enough that I'm sure you can understand it perfectly fine. :X

Here's an example. This is the center safety of SSCI Dragonball Z, probably one of the most FPS draining parts of the map. On 1280x1024 with my 6800XT (256MB GDDR2 AGP), I would get 22 frames per second and below just hanging around center safety. After I overclocked the card from 300mhz/525mhz (GPU/Memory) to 350mhz/625mhz, I would usually get 40 and above (44 on average). Now I took the center safety and chopped it up accordingly. I saved each image as _x-y.gif. Where is obviously the LVZ layer it is set to; x is the numerator and y is the denominator for the total number of the same LayerMode LVZ-Maps. Since each image had less than 256 different colors, I got the advantage to have Photoshop save these GIFs with indexed colors (meaning that whatever different colors these images have will be the color palette in the saved GIF itself - as long as it is under 256 colors though; 256 is the max GIF can hold according to Photoshop). If you were to exceed 256 colors, the way I would sometimes do it is same one in GIF, JPG, PNG, and maybe some other supported format. Then compare the filesizes and qualities to determine which one is the better pick from the format to use. DCME should do likewise to provide the most efficient, the least demanding in space, LVZ-maps. So I test this out. From the very center of the safety, I get a grand 20+ more FPS than I would with Normal-Maps. And around the whole structure, I get an additional 20 to 100 frames per second. Compared to flying around the safety with Normal-Maps, the LVZ-Map skyrocketted my FPS above 100 fps here and there. Infact I did not even get past frames per second with the Normal-Maps just flying around the safety. As for AfterBackground_1-1.gif, I didn't even need to include that there, since it was pretty much 100% black. I'm too lazy to go research about the opacity and translucancy. Download the test map (only contains LVZ-Map) from http://www.hlrse.net/Qwerty/LVZMapping.rar

Instead of a tile-to-tile when it compiles, it could compile the LVZ Map by simply taking a screenshot of the entire map (one big image), and split it into any defined image sizes (ie. 512x512 images). !@#$%^&*uming that most of the map will be just solid tiles, it's a big plus for solid tiles. So it could take each of the 17 effects and make one big full-map screenshot of them. Then size down the canvas to the lowest possible. Then chop the image up into any defined sizes (32, 64, 128, 256, 512, 768, 1024 squared; etc. Anything with a multiple of 16). I think this might be more FPS efficient compared to Normal Mapping if this is how LVZ images are compiled. -_-

I gave him a webhosting account at http://ssdev.hlrse.net/ on the Beginners plan. -_-

Mill, you seriously need some decent hosting. I'll give you the Beginners plan from http://www.hlrse.net/ for free; you can use it as a .hlrse.net or a yourdomain.com. It's all yours to keep, so just give me a holler to let me know that I've got your attention. EDIT :: Heh, I can see what you mean by needs more work. It definately needs a lot of work. Try to make this as if you were making Starfox 64. SF64 has some pretty nice details on how Subspace in 3D could be. EDIT2 :: Make a 3D interior for the ships! I think the different views are fine, except for that one where you're pretty much at a side-view. That one should be smoothly locked onto the behind of the warbird at a slight al!@#$%^&*ude (overview, 3rd Person). The 3D interior would be pretty cool to see. (Of course, just a small technical note: the interior and exterior views are pretty much almost two different models. One would be off while the other on.

If someone suffers from something for playing Subspace, they really can't sue anybody (except maybe PriitK, but I doubt it). My message to them: haha, tough luck buddy. Get outta here! I don't think this community needs those kind of sue-happy, angry people around. :\

Guess how long it took me to write this up.

EDIT :: Ugh, accidentally posted this one again through a cache-glitch. DCME-WallTilesGlitch.rar Step 1: Open baseconvert.lvl Step 2: Load the baseconvert.lvl.wtl wall tiles Step 3: Examine the wall tiles for glitching or problems (anything that doesn't look right) Step 4: Close baseconvert.lvl Step 5: Open _server115.lvl Step 6: Load the baseconvert.lvl.wtl wall tiles Step 7: Examine the wall tiles for glitching or problems (anything that doesn't look right) By Step 7, you should notice a strange glitch with the 6th and 7th wall tiles, where the center and center-bottom tile switches places when you load it up in _server115.lvl. It looks fine in baseconvert.lvl, but when you bring it to _server115.lvl, it's a whole new issue. Why can I only move LVZ graphics at a 1:2 zoom ratio? When I select an LVZ graphic (and this should be a feature by the way), I want to know that it is selected by having a user-specifiable 2px to 3px colored border around the image boundaries. Then if I have multiple LVZ graphics laying on top/below each other (as you see in the screenshot), I want to be able to click in the same spot (at half the rate of an average double click) and cycle through selecting each of the LVZ graphic objects (until I've selected all of them it would start the cycle from top to bottom over). http://www.hlrse.net/errors/dcme-lvzgraphic.gif Second, why is DCME rendering PNGs and LVZ incorrectly? Notice the fading-out safety graphic. There is one thing I must mention, all the LVZs in this LVZ file I loaded have a black background and no actual transparent parts in the PNG images. So why is DCME rendering that fade-out graphic with transparency (and to mention that it has additive rendering on it, which is absolutely incorrect and not supported by Continuum)? DCME should render it by color, where by default #000000 or 0 0 0 is transparency (should be user specifiable, although this is useless; not sure if someone might have a use for this), strictly. Now see that Dragonball Z character in the orange (his name is Goku)? The first problem of that which comes to mind is that it is incorrectly rendered by layer. It should be behind tiles (and everything) except in front of the background (stars, planets, etc). The second thought is that the black (previous paragraph problem) is not transparent. By the way, you might want to fix this for the sake of decency : http://www.hlrse.net/errors/dcme-TileSwoopInShip.gif DCME_WallTilesGlitch.rar