Santa

dmap2tiled --project "C:\NewCOMaps\Map01" --client "C:\ClientsConquer\5579\" --dmap "map\map\canyon.dmap" -f

Hey sley, if you have a particular issue or a particular map you are struggling with please start an issue or discussion on github.

There are a couple of utilities in my map editing utility that should assist with copying only the resources that are used in a given map. Not super thoroughly tested so I'm sure there are some edge cases that are missed. https://github.com/SantasCode/Tiled2Dmap#extract and https://github.com/SantasCode/Tiled2Dmap#install

Looks like you didn't copy all of the map resources over. I'm going to guess there should be two .pul files + resources that should have been copied for this map.

Ah yeah, looking at them now those totally aren't right. They are offsets form the entry point of the app. Add 0x400000 and it should look more familair. Not a whole lot of context in this image, and I haven't opened the client in a disassembler to get that context but my gut is that its not going to be relevant for screen size. This looks like it has something to be with the actual loading of each individual puzzle piece

The screen width and height are set in several spots in the client. You've increased the window size but you also need to find the "draw" function of the puzzle (background). The reason you are seeing what you are seeing is because its still drawing the puzzle with a width of 1024. The reason it "sometimes" looks normal is because it still draws the complete puzzle piece (typically 256x256), it doesn't only draw partial puzzle pieces. There is also essentially a viewport that is passed around that will need to be set with the new window size as well. Should be able to search for constants "768" (1024 is far more common). General rule is probably that it's only related to screen/viewport is you see both 1024 and 768 in the some chunk of asm. Here are the address I found when searching a few years ago. I never took the time to see what each address did, I just overwrote everything, which I wouldn't recommend. widths = { 0x10E6, 0x84A8B, 0x84A5B, 0x85721, 0x86E0E, 0x86EE8, 0x95FE5,0x96026,0x96058,0x960F4,0x96141,0x9629C,0x962CD, 0xADFF3 }; heights = { 0x10ED,0x84A95, 0x84A68, 0x8572E,0x86E1B,0x86EF5,0x95FF5,0x96032,0x9605F,0x96100,0x9614A,0x962AC,0x962DD, 0xAE00A, 0xAE02A }; Also, I think these addresses might have something to do with spawn distance(again, been a while): 0x004A0911, 0x004A0925 If you are sticking with patch 5065 I'd recommend starting a ghidra or ida project and documenting things as you discover them. Also, find the EO client source code that's floating around. 5065 is structured very similarly to that client.

I'm a little lost. What is it that you are trying to do exactly? Sounds like you are setting up the server on your home network and then trying to access it from outside of your network? Have you tried connecting to the server from a client on the local network?

I can understand the reasoning behind the majority of these....but Dummy? Hard time following that one. Also, most of the alternatives for a Master/Slave alternative don't really make much sense to me. I could maybe see Leader/Follower(duplicated in the list btw) or Orchestrator/Worker. The other ones don't share the same relationship principals that we see in what we have historically referred to as a master/slave relationship. From the Bluetooth SIG: Stumped on what SCA stands for.

They do live in a PuzzleSaves folder. I can't seem to find any information on this Tian Yuan game do you have any more information on that? (edit: found it, another netdragon game, there any dev forums or anything for it you know of?). Yeah, fairly sure they aren't roll values. The images that belong to a "UnitData" are far to different for them to be interchanged and not look messed up. Here is the complete snippet to read a pux file. using (TextWriter wr = new StreamWriter(File.OpenWrite(@"C:\Temp\puxFile.txt"))) using (BinaryReader br = new BinaryReader(Stream)) { this.PuzzleType = br.ReadASCIIString(16); wr.WriteLine(PuzzleType); uint token1000 = br.ReadUInt32();//1000 if (token1000 != 1000) Debug.WriteLine("Unknown Token in .pux file is not 1000"); uint unkWidth = br.ReadUInt32();//52 uint unkHeight = br.ReadUInt32();//28 wr.WriteLine("Size: {0},{1}", unkWidth, unkHeight); //CAoxPuzzle::LoadTextureGroup uint unk5 = br.ReadUInt32();//1000 ushort numTextureGroups = br.ReadUInt16(); wr.WriteLine("Num of TextureGroups: {0}", numTextureGroups); for (int i = 0; i < numTextureGroups; i++) { ushort unkLength = br.ReadUInt16(); byte[] unkBytes = br.ReadBytes(unkLength); ushort aniLength = br.ReadUInt16(); string aniFile = br.ReadASCIIString(aniLength); ushort puzpieceLen = br.ReadUInt16(); string puzPiece = br.ReadASCIIString(puzpieceLen); uint unk6 = br.ReadUInt32(); uint unk7 = br.ReadUInt32(); uint unk8 = br.ReadUInt32(); uint unk9 = br.ReadUInt32(); uint max = br.ReadUInt32(); wr.WriteLine("Texture Group: {0} AniFile: {1}, PuzzleEntry: {2}, {3}, {4}, {5}, {6}, {7}", unkBytes.GetString(), aniFile, puzPiece, unk6, unk7, unk8, unk9, max); } //End LoadtextureGroup //CAoxPuzzle::LoadEdgeGroup uint unk10 = br.ReadUInt32();//1000 ushort numEdgeGroups = br.ReadUInt16(); wr.WriteLine("Num of EdgeGroups: {0}", numEdgeGroups); for (int i = 0; i < numEdgeGroups; i++) { ushort unkLength = br.ReadUInt16(); byte[] unkBytes = br.ReadBytes(unkLength); ushort aniLength = br.ReadUInt16(); string aniFile = br.ReadASCIIString(aniLength); ushort puzpieceLen = br.ReadUInt16(); string puzPiece = br.ReadASCIIString(puzpieceLen); uint unk6 = br.ReadUInt32(); uint unk7 = br.ReadUInt32(); uint unk8 = br.ReadUInt32(); uint unk9 = br.ReadUInt32(); uint max = br.ReadUInt32(); wr.WriteLine("Edge Group: {0} AniFile: {1}, PuzzleEntry: {2}, {3}, {4}, {5}, {6}, {7}", unkBytes.GetString(), aniFile, puzPiece, unk6, unk7, unk8, unk9, max); } //End LoadEdgeGroup //PuzzleUnitData uint puzzGridCnt = br.ReadUInt32(); wr.WriteLine("PuzzleUnitData Size: {0}", puzzGridCnt); for (int i = 0; i < puzzGridCnt; i++) { byte dataCnt = br.ReadByte(); if (dataCnt != 0) { for (int j = 0; j < dataCnt; j++) { ushort aniID = br.ReadUInt16(); uint unk2 = br.ReadUInt32(); wr.WriteLine("PuzzleUnitLayer({2} - {3}): {0}, {1:X8}", aniID, unk2, i, j); } } } uint numEdgeData = br.ReadUInt32(); wr.WriteLine("EdgeLayer Size: {0}", numEdgeData); for (int i = 0; i < numEdgeData; i++) { uint unk = br.ReadUInt32(); byte[] unkBytes = br.ReadBytes(4); wr.WriteLine("EdgeLayer: {0}, {1}, {2}, {3}, {4}", unk, unkBytes[0], unkBytes[1], unkBytes[2], unkBytes[3]); } Debug.WriteLine("Finished reading pux"); }

Hello, Hoping someone might have some info regarding the newer conquer maps. Not sure what patch they show up in but looks like they have a new revision of their puzzle files. A dmap can either reference a traditional ".pul" file or this new ".pux" file. Was pretty straight forward grabbing the format of the file out of the client, but how it's all used is, so far, a mystery. For the most part it just allows for puzzle pieces to be defined in multiple ani files, instead of a single one. Another large difference is that the "puzzle grid" in a ".pul" file is simple an array of ID's, being the puzzle piece number, that is the size of the width*height. In a ".pux" file it is a little different. It is an array of objects the size of width*height. The object is a "PuzzleUnitData" consisting of an array of IDs and an unknown uint. uint puzzGridCnt = br.ReadUInt32(); wr.WriteLine("PuzzleUnitData Size: {0}", puzzGridCnt); for (int i = 0; i < puzzGridCnt; i++) { byte dataCnt = br.ReadByte(); if (dataCnt != 0) { for (int j = 0; j < dataCnt; j++) { ushort aniID = br.ReadUInt16(); uint unk2 = br.ReadUInt32(); wr.WriteLine("PuzzleUnitLayer({2} - {3}): {0}, {1:X8}", aniID, unk2, i, j); } } } I kind of get the feeling that they might be blending multiple textures together to get more reusability out of assets, but this is pure speculation at this point. I've not logged into the official servers to actually see if I can identify places on the map that corelate to my findings. Here is a sample of what I'm dumping out of the data grid portion of the ".pux" file. PuzzleUnitLayer(639 - 0): 280, 01800000 PuzzleUnitLayer(640 - 0): 280, 00300000 PuzzleUnitLayer(761 - 0): 241, 01000000 PuzzleUnitLayer(762 - 0): 241, 00700000 PuzzleUnitLayer(762 - 1): 241, 01800000 PuzzleUnitLayer(762 - 2): 280, 00004300 PuzzleUnitLayer(763 - 0): 241, 00010000 PuzzleUnitLayer(763 - 1): 242, 00620000 PuzzleUnitLayer(763 - 2): 241, 00100000 PuzzleUnitLayer(763 - 3): 280, 018C7DE0 PuzzleUnitLayer(764 - 0): 241, 00800000 PuzzleUnitLayer(764 - 1): 280, 017FFF18 PuzzleUnitLayer(764 - 2): 277, 00000200 looking at the first item, 639 is the index of the grid, 0 is the index of the unit data item, 280 is the puzzle ID, and 01800000 is an unknown. I'm taking a wild guess and thinking it has something to do with blending, perhaps a per channel deal, but haven't had any break throughs. Wonder if this kind of thing, blending multiple images with channel weights (or something), has been seen by anyone around here? Been trying to do some static analysis on the latest client but its not going so well. Would love to do some dynamic analysis but of the sources I've found on sketchy sites, they still don't target a high enough client to have these files.

Yes, this is the brain child of Relic and I. (Not Co Fuse, that's all him and Craft). Took roughly 20 hooks with half of those just being window visibility checks. Probably a few we could consolidate but that can come later.

Wow, he didn't tell you about me? Rude

^^ can do this, can't embed a video...

I'm think that the "Progress" bar is part of the login or role create screen. When you initiate login with both of those dialogs disabled you still see the messages without that bar. adrian, what patch are you working with? I'm assuming a higher 5xxx patch? At some point they refactored a bunch of their code so its a little more difficult to follow