Bak

that's not true. The animated team map both teams can go through while the animated enemy brick is more of a ranomly timed warp pad. See http://wiki.minegoboom.com/index.php?!...;*le=LVL_Format

When I play the game often goes into the entering arena screen when I'm in the middle of something. It doesn't matter if i'm in game or in spec, or even alt tabbed. As you can imagine this is very frustrating. I've heard of someone else having this bug too, but I forget who. It just enters the entering arena screen and then never leaves... I need to quit and re-enter. Anyone else get this? or just me? My prediction is that I'm getting sent random packets on the same port as continuum is using, and some of them get decrypted to the enter area packet... but I may be completely off.

That's a good idea for the rotator.

Most zones have trouble filling a 1024x1024 map, and using ASSS you could send the player to a different arena when he reaches a boundry if you really want to emulate a bigger map. What's stoping you from do this already? Just subs!@#$%^&*ute docking with attaching and give one of the ships a lot more energy (kinda like starcon).

you can customize fonts through lvz, just override the default font graphic. *getfile custom save locations (and write locations) are already in ASSS. Keeping zone owners in control can be done through ASSS. the history can be done (and I'm pretty sure has been) through ASSS.

You really shouldn't be worried much about OpenGL or sockets, as all that stuff won't take long at all to code. The OpenGL code required to just draw a 2d image on the screen is just two lines of code(once you set it up, which you can take from sample code), one to tell the location of where to draw it, and another to actually do the drawing. As for sockets, once you figure out how to send a packet, you're all set, as all data will be in packets. The more difficult part of the project will be in the organization. Server authentication, in my opinion, will never work. It would require running a physics engine inside the server, which I suppose is do-able. However, players will complain when the server says they got hit even though on their screen they dodged the bullet/bomb. Plus what happens if the bullet or bomb that missed them bounces off a wall and hits them again? Can they take double damage from a single bullet? Perhaps the projectile should just disappear if the server says they were hit, in which case it may look ugly on people's screens. The problem with an open source client is that cheating client side will become very easy. Preventing cheating will be difficult if all the source is available to everyone.

http://www.angelfire.com/film/clips1/MoveAna/MoveAna.html If it doesn't load the first time or an image is missing just press refresh... here's a screen shot, it's more impressive in motion: http://img.photobucket.com/albums/v622/bak2007/moveAn!@#$%^&*.png

images don't seem to work, unless you were referring to the hearts as images (they're not, just unicode letters).

Use !@#$%^&* to edit your tileset: !@#$%^&* Site http://www.rshl.org/!@#$%^&*

Use !@#$%^&*, an all in one level graphics and ASSS Region editor: !@#$%^&* - http://www.rshl.org/!@#$%^&*

kinda bump... but meh from lvzformat.txt: 12 bits gives you numbers up to -> 2^12 or 4096 409.6 seconds is 6.82 minutes that may be why it's only displaying for about 7 minutes, a limitation of the format lvz are saved in.

The reason there is a 2nd small asteriod is that VIE removed the large asteriod. You're right that it may seem useful to have the option to easily make a repeated animation, but I hope to allow the user to copy/paste both tiles and lvz in the same selection in a future release(instead of just tiles), allowing for the same effect without using a 2nd asteroid. Have to add layers first... so people woudln't copy background lvz if they're zone has it.

Update in version 1-1-05: Added eLVL region and ATTR tag support, sped up program while reducing memory usage, fixed the zooming "centering" bug, added square and squarefill tools. Fixed random bugs. Eliminated drawing scaled tiles at high zoom levels, user can now press "delete" to delete a selected map object. Will now remember position / size of window between sessions. the IOException you're getting means that the program can't execute "cmd" off your computer. Are you using windows XP ?

ok, ban lifted

and make another one that allows cheating so we can all go and cheat without getting banned.

nike said it will be lifted early in time for the duel tourniment. I have a reason not to get banned again now...

I'm not banned funk, put me back in. It was all a misunderstanding.

basing the ball makes me happy

the subspace encryption has been broken, you're thinking of continuum encryption. this is straight from http://www.ssihosting.com/catid/files/addendum.txt -=Encryption=- SubSpace uses encryption.  Encryption means to obscure the true meaning of a message using a numerical pattern. When SubSpace connects to a SubGame game server, it firsts completes a key exchange. ie. 00 01 KK KK KK KK VV VV 00 05 SS SS RR RR 00 06 SS SS RR RR TT TT TT TT 00 02 ~K ~K ~K ~K 'KK = Random number (must be negative) 'VV = Encryption version (1 for SubSpace, 16 for Continuum) 'SS = Number of connections since last recycle 'RR = Random number 'TT = Local time '~K = Session key (must be unary -KK) There is some protocol that goes along with these packets: 00 01 gets resent until 00 02 is recv'd. If KK >= 0, then a proper SubSpace server will not acknowledge your connection. 00 05/00 06 isn't used in older SubSpace servers, it's recommended you take this  into account while designing your own stack. Up until the 00 02 response, no other packet types (should be) accepted by the server. Why we use 00 05/00 06: A few years ago I discovered that sending a massive load of 00 01 packets to a SubGame would effectively create a Denial of Service condition; PriitK patched it by masterfully recoding the connection protocol for SubGame to ignore requests until it gets an 00 06 response to SG's 00 05.  It is therefore a fix for a nasty problem. Why we use packets limited to 520 bytes: For both bandwidth reasons and, interestingly enough, the hard fact that SubSpace's encryption uses a buffer of 520 bytes - anything longer cannot be decoded. There are some ways to disable encryption: Send a KK field of 0.  00 01 00 00 00 00 01 00 The server must respond with a NULL key (no encryption). Custom SubSpace stacks may ignore this. Encryption may be disabled server-side if the key you send is the same as the key you get back. But if you want to use encryption: The lengthy DOC by Coconut emulator explains how he ripped SS encryption to a DLL file with SoftICE for use in VB programs.  MERVBot contains C++ code which encapsulates all aspects of maintaining a SubSpace session, including encryption. Security of the encryption: This method of encryption is very weak to a chosen-plaintext attack, and tends to share every fourth byte of the keystream with other connections established within ~48 hours. For example, SECRET_KEY ^ PLAINTEXT -> CIPHER_TEXT, if you know PLAINTEXT then PLAINTEXT ^ CIPHER_TEXT = SECRET_KEY.  In short, do not trust any personal data on a logged connection to SubSpace.  Continuum, on the other hand, has military-grade encryption =)) Then from mervbot's encrypt.cpp: //////// Misc. encryption //////// char ROT13(char c) { if (c >= 'a' && c <= 'z') { c += 13; if (c > 'z') c -= 26; } else if (c >= 'A' && c <= 'Z') { c += 13; if (c > 'Z') c -= 26; } return c; } //////// SubSpace packet encryption //////// // Courtesy of Coconut Emulator SS_ENCR::SS_ENCR() { key = 0; sentKey = 0; } Uint32 SS_ENCR::generateKey() { if (sentKey) return sentKey; Uint32 edx = getTime() * 0xCCCCCCCD; Uint32 res = (keygen.getNext() << 16) + (edx >> 3) + keygen.getNext(); res = (res ^ edx) - edx; if (res <= 0x7fffffff) res = ~res + 1; return (sentKey = res); } Uint32 SS_ENCR::getSessionKey(Uint32 clientKey) { return ((~clientKey) + 1); // Two's complement, same as arithmetic minus on unsigned data } bool SS_ENCR::validateSessionKey(Uint32 serverKey) { return ((serverKey == sentKey) || (serverKey == getSessionKey(sentKey))); } bool SS_ENCR::initializeEncryption(Uint32 serverKey) { if (!validateSessionKey(serverKey)) return false; if (sentKey == serverKey) { key = 0; memset(keystream, 0, 520); } else { key = serverKey; Uint16 *stream = (Uint16*)keystream; prng.seed(serverKey); for (Uint32 i = 0; i < 260; ++i) { stream[i] = prng.getNextE(); } } return true; } void SS_ENCR::encrypt(char *msg, Uint32 len) { if (!key) return; Uint32 ksi = 0, i = 1, IV = key; if (*msg == 0) { if (len <= 2) return; ++i; } while (i + 4 <= len) { *(Uint32*)&msg[i] = IV = (getLong(msg, i) ^ getLong(keystream, ksi) ^ IV); i += 4; ksi += 4; } Uint32 diff = len - i; if (diff) { Uint32 buffer = 0; memcpy(&buffer, msg + i, diff); buffer ^= getLong(keystream, ksi) ^ IV; memcpy(msg + i, &buffer, diff); } } void SS_ENCR::decrypt(char *msg, Uint32 len) { if (!key) return; Uint32 ksi = 0, i = 1, IV = key, EDX; if (*msg == 0) { if (len <= 2) return; ++i; } while (i + 4 <= len) { EDX = getLong(msg, i); *(Uint32*)&msg[i] = getLong(keystream, ksi) ^ IV ^ EDX; IV = EDX; i += 4; ksi += 4; } Uint32 diff = len - i; if (diff) { Uint32 buffer = 0; memcpy(&buffer, msg + i, diff); buffer ^= getLong(keystream, ksi) ^ IV; memcpy(msg + i, &buffer, diff); } } void SS_ENCR::reset() { key = 0; sentKey = 0; } //////// Billing password encryption //////// // Also from Coconut Emulator void hashP!@#$%^&*word(BYTE *in, BYTE *out) { Uint32 StrLen = STRLEN((char*)in); BYTE Factor = simpleChecksum(in, StrLen); BYTE Char; for (Uint32 L = 0; L < StrLen; ++L) { Char = in[L] ^ Factor; Factor = (Factor ^ (Char << (Char & 3))) & 255; if (Char == 0) Char = 0xED; out[L] = Char; } out[L] = 0; } //////// Billing password decryption //////// void inverseHash(BYTE *In, BYTE *Out, BYTE Key) { size_t StrLen = STRLEN((char*)In); for (Uint32 L = 0; L < StrLen; ++L) { BYTE Char = In[L]; if (Char == 0xED) Char = 0; Out[L] = Char ^ (BYTE)Key; Key = (Key ^ (Char << (Char & 3))) & 255; } } void decryptHashedP!@#$%^&*word(BYTE *password) { Uint32 StrLen = STRLEN((char*)password); BYTE *Buffer = new BYTE[StrLen + 1]; Buffer[StrLen] = 0; // passwords of EVEN length are very easy to crack. if (StrLen & 1) { // Guess and check to find one of the solutions for (int i = 0; i < 256; ++i) { // Generate a possible solution inverseHash(password, Buffer, i); // Compare resultant hash with given hash BYTE Char, Key = i; bool OK = true; for (Uint32 L = 0; L < StrLen; ++L) { Char = Buffer[L]; if (!isPrintable(Char)) { OK = false; break; } Char ^= Key; Key = (Key ^ (Char << (Char & 3))) & 255; if (Char == 0) Char = 0xED; if (Char != password[L]) { OK = false; break; } } if (OK) break; } } else { // Generate password checksum inverseHash(password, Buffer, 0); // Generate actual password inverseHash(password, Buffer, simpleChecksum(Buffer, StrLen)); } memcpy(password, Buffer, StrLen); delete Buffer; Buffer = NULL; } make what you want of it...

first off, I don't think there's much chance of getting ekted or priitk aboard the open source train. That said, the security module could be kept private (dll) and use a hash of all the other sections of code for validation reasons, so that the zones that don't want to allow a modified client in, won't allow them. But then a few people would make accepted clients and those could be allowed in too simply by putting their hash code on the accepted list.

is that lvz size? or just as a raw image. Harddrives are by no means low on space, so it's not an issue if the lvz size is the same. JPG is a lossy format, so it wouldn't be benefitial to save everything as JPG's.

rockets result in a speed increase... you have no right to express your opinion, stfy -TOPIC LOCKED-

I also told you that you have no right to express your opinion here. Until you get some skill take everyone's advice and STFY.

I know if you use E (energy bar) and then you spec making the energy bar dissapear it just moves up flush with the top of the screen. I'd imagine this is the case with the player name box too.

what about portals? not allowed to use then from the hypertunnels?