qan

Had the misfortune to find an awful bug today while playing with a tileset in DCME. It's reproduceable (I just did it again now). Here is what I did: - Loaded map A. - Loaded map B. - Saved map B's tileset to a BMP. - Opened the Tileset Editor. - Opened the BMP just saved as the source image. - Selected tiles in the source image, and copied them into map A's tileset. - Hit close on the tileset window. - When asked whether to apply the tiles, I hit yes. - Closed the map -- decided I didn't like the tiles, and was going to Photoshop some new ones. At the prompt to save I said no. - Opened the map afterward: the map is now completely blank, and the tileset change that I didn't like remains (probably was written to disk rather than memory at the tileset editor closing prompt?). If it's useful to know, I used a tileset internal to the map rather than an external file, and was using 24bit color in the tileset. Fortunately I have a pretty recent backup of the map on a server. If this is the worst DCME brings me, for all the time it's so far saved, I have no big complaints. (For example, the ability to move tiles around on the fly and observe the results on the map has made aesthetic decisions about tiles ... actually enjoyable.) Thanks. I forgot to mention: as the subject of the thread implies, the autosave file was also overwritten and was in every way the same as the regular file.

Wanted to say, as I'm sure is the almost unanimous response on discovering this editor, that it's pretty much amazing. Your improvements have allowed mapdev to proceed at about 3 times the pace previous, where one was forced to work with several haphazard tools in a kludge of desired functionality. Now pretty much all that's needed is DCME. Again: amazing. My question is about color bitdepth. By default Cont defaults to 8-bit, but for those that switch this, the rewards of higher bitdepth tilesets (possibly also LVZ contents?) can be reaped. I usually design a tileset in 24-bit, as apparently this has the best conversion between various depths. However, I still have to upload and physically test the map with the various options for color in order to ensure it looks all right. Is there any way to do this in DCME beforehand?

Hi guys, Working on the new release of TWCore, and I'm running into a problem with the position packets that I'm sure many here are familiar with. SS has two different versions of the player position packet, a short and a long or "weapons" version of the packet. The short packet saves on space, the long one provides verbose details as needed. A nasty difference, though, that becomes acutely painful on zones that routinely have over 255 players, is that the short version only sends playerIDs as bytes, whereas the full ID is actually a 2-byte/16-bit shortint. So if you rely on the short version's ID to tell you what player it's talking about, you stand a chance of grabbing the wrong player, or even more likely, no player at all. (Player X is ID 0, or "0000000000000000"; player Y is ID 256, or "0000000100000000". If you remove the first byte, as the short packet does, you get Y = "00000000" = X = "00000000." This sucks terribly.) So my question is, being the packet newbie that I am, when is the short version sent versus the long version? Long I'm !@#$%^&*uming is sent when a weapon's fired, but any other times? Certainly the Cont client doesn't seem to suffer from the problems !@#$%^&*ociated with one-byte IDs... does it have a way of always requesting the long version of the position packet? Or somehow coping with the short version's obvious limitations? The reason I ask this is because we recently made some efficiency changes in the core, not "overstoring" parsed packet data in containers two or four times too large. PlayerID used to be a 32-bit int, and now it's a shortint. However, we now end up throwing all kinds of null pointer exceptions on our dev core from IDs that can't be retreived, whereas before with int storage we had no such problem. This raises a big "what the !@#$%^&*?" about packet presumptions... what was the int able to store that the short wasn't? Is it some other related change that's causing this instead? Or were the NPEs simply repressed beforehand? Confusing, to say the least. Any information about the differences between these two packet types, or any intuition on a possible solution to resolve this problem would be of course greatly appreciated. Excessively yours, qan