Munsie

https://munsie.itch.io/artisan-swindler This tool was designed to help players better understand the total cost of upgrading items with mets and DBs using ArtisanWind in TC or MagicArtisan in Market. Should work for any server that's using the original retail TQ rates for repair costs and upgrade chance.

At some point TQ switched from storing a lot of data in .ini files to .dbc files nested inside of .wdb files. You'll notice in 5165 you have a "c3.wdb" file in your /ini/ folder. The new 3DEffect.dbc is in there, and that's the file the client is actually using to load effects. Any changes you make to 3DEffect.ini will be ignored. CptSky has a tool for unpacking wdb files. There are a number of tools for converting the wdb files to ini and back again. Unfortunately, none of them (in my experience) worked for 3DEffect specifically-- At least going from 3DEffect.ini back into 3DEffect.dbc. You can find some details about the EFFE file format here. I ended up writing my own janky little utility for converting them, and if it weren't so user-unfriendly I'd consider sharing it. That said, even if you obtain the ability to edit 3DEffect.dbc, I offer no guarantees that the offset values will do anything-- Sometimes TQ just has fields in their files that don't do anything (because it's all hard-coded in the client, or part of the .c3 animation file, etc).

It appears that source does have a database, but it's only used for player data. For monsters, you'd have to define the new monster in MobInfos.txt and then set a spawn for it in MobSpawns.txt. The source appears to read that data in Database.cs -> LoadMobs(), which may give you some clues on what each of those values are for. The animations would be handled by 3DMotion.dbc in the client. There's one line per body type, weapon type, and animation (which multiplies out to be tens of thousands of lines), though many of them share the same c3 animation file.

Does the server emulator you downloaded have a name? If it's a commonly known / open source one, it may help narrow down the issue you're experiencing. Adding extra monster IDs wouldn't normally break NPCs, so I do wonder how that data is structured. Does that source have a proper database?

I think you're spot on with a lot of your analysis (and several of your proposed solutions), but here's some thoughts on a few of your other topics. Those are also, incidentally, the classes that can deal damage from long distances with minimal mouse precision required. An archer doesn't deal much damage, but can also be played by somebody with ten thumbs and triple digit ping to moderate success. I feel like you're also overlooking the implications of warriors and trojans also being resource-limited, but it's by stamina rather than mana/arrows. Scarcity breeds conflict, which I think is important in a PVP-heavy game. TQ took advantage of the situation to sell you the answers, but in theory systems like that are good for generating content in the form of player to player interactions. The flip side to such systems, however, is it becomes possible to monopolize the resource/spawn/reward if a large enough or strong enough group of players decide to commit to it. Perhaps an ideal server hands out "must have" items liberally, while other items and bonuses that are merely "nice to have" have limited access or supply. An example of this from later patches would be the Snow Banshee world boss. They don't have to make people quit, but Conquer does excel at giving people as many 'exit points' as possible. There are a dozen different situations you could find yourself in where any normal person will go "well this sucks, I'm out." More successful full loot PVP games have put a lot of work into ensuring that there's content available for the 90% of the player base that aren't hardcore PVP fanatics. Take a look at something like EVE Online or Albion Online setup their world and economy to facilitate that. On a Conquer server, if you have enough active players that every single market booth is full, and there's a bit of competition to claim a spot when one opens up, I think you're getting pretty close to "too crowded". That would be ~150+ characters actively looking to sell things. I'm not sure how you'd ever get to that point, since there aren't enough hunting/plvling spots to continuously generate items for said sellers. Maybe a very active mining scene?

While poking around this morning I came across "booth.ini" in the \ini\ directory. Turns out that file has a mapping between NPC ID and ShopFlag number and I never had to trial-and-error my way to that info in the first place. Haven't tested it, but presumably you can just edit this file to the NPC IDs you're using and call it a day. [boothNumber] 50=133 51=134 52=135 53=136 ...

That seems reasonable enough to me. I've seen a few servers recently where Gourds were only available via the shop which seems crazy when you crunch the numbers on how much extra HP that gets you (3008 on a Trojan, assuming you had 400 mana for stig). Do you have a list of what benefits VIP provides currently? The only one I saw mentioned on the website was mining, which I'm guessing is the usual arrangement to stop your inventory from filling up with junk ores.

$45 Gourds and $25 super gem garments in the Donation section is a bit concerning-- Are those obtainable by other in-game means? On the surface it just seems a bit at odds with the "no pay2win" bullet point.

At some point in 2.0 TQ added numbered labels above each of the ShopFlags in market, likely in response to players complaining that they had a hard time finding a particular market stall when somebody in trade chat said "come market 159, 189". I discovered three things while trying to get all the ShopFlags numbered: First is that the number that appears above the ShopFlag is directly related to the ID you give it in the server-side NPC database table. Second is that the numbers don't go in any pattern/order in the slightest. It's pure chaos. Third is that nobody seems to have documented this quirky nonsense anywhere on the internet, so here we go. After a bit of trial and error, I was able to get all of the flags correctly numbered, in order. Below is the matching NPC IDs and ShopFlag numbers: npc_id shop_flag_num 186 1 187 2 188 3 189 4 190 5 191 6 192 7 193 8 194 9 196 10 197 11 122 12 210 13 211 14 212 15 213 16 214 17 215 18 216 19 217 20 218 21 219 22 220 23 221 24 198 25 199 26 200 27 201 28 202 29 203 30 204 31 205 32 206 33 207 34 208 35 209 36 174 37 175 38 176 39 177 40 178 41 179 42 180 43 181 44 182 45 183 46 184 47 185 48 116 49 117 50 118 51 119 52 120 53 121 54 110 55 111 56 112 57 113 58 114 59 115 60 104 61 105 62 106 63 107 64 108 65 109 66 98 67 99 68 100 69 101 70 102 71 103 72 168 73 169 74 170 75 171 76 172 77 173 78 162 79 163 80 164 81 165 82 166 83 167 84 156 85 157 86 158 87 159 88 160 89 161 90 150 91 151 92 152 93 153 94 154 95 155 96 86 97 87 98 88 99 89 100 90 101 91 102 92 103 93 104 94 105 95 106 96 107 97 108 74 109 75 110 76 111 77 112 78 113 79 114 80 115 81 116 82 117 83 118 84 119 85 120 62 121 63 122 64 123 65 124 66 125 67 126 68 127 69 128 70 129 71 130 72 131 73 132 50 133 51 134 52 135 53 136 54 137 55 138 56 139 57 140 58 141 59 142 60 143 61 144 As an added bonus, if you want to change what those numbers look like, all the UI component images can be found in this directory of the client: \data\interface\Style01\Stall\

It's not ideal, but unless Santa/Relic decide they want to make their login stuff public/release a tutorial (and I certainly wouldn't blame them if they didn't), I think I'm at Flash's mercy for the time being. Unfortunately I don't know the first thing about binary modification/hooking/etc. I'll have to look into it one day though, since my "client mod wish list" gets longer and longer every day.

Windows just snuck update KB4577586 onto my machine yesterday which completely broke the flash fix I was using (Felipe's). Kept getting the error "Please install Flash 6.0 or above" whenever I launched the client, even if I rolled the clock back. The solution that worked for me, on Windows 10, was using this patcher: https://github.com/leecher1337/flashpatch Downloaded flashpatcher_x64.exe and reinst_flash_w10.cmd, and then ran the cmd file as admin from command prompt with /force. It did some magical wizard shit, and now I can launch CO again. Hopefully this comes in handy to somebody that ends up in the same situation I did.

Today I learned that Windows' indexed search doesn't look for matches in the middle of words. Bumping MaleFaceAmount from 107 to 108 did exactly what I was hoping it would. Thanks Spirited.

Howdy, I've been trying to figure out if there's a way to add new player faces without replacing any of the existing ones. This is proving to be more difficult than I would have guessed. If it matters, this is on a 5187 client. Here's what I know so far: All the images are stored in \data\PlayerFace The images are connected to a face ID via \ani\PlayerFace.ani Clicking on the Beautician in-game doesn't actually send anything to the server, it's all handled client-side until you click the "Change" button As a quick test I duplicated the male face 107 and renamed it to 108, and verified there was an entry for [Face108] in the ani file that points to 108.dds. I duplicated and renamed 107 in the \JPG\64 and \JPG\16 folder as well, just in case the Beautician looked at those. Alas, the Beautician doesn't show the newly added face 108 at the end of the list. However if a character in the DB is manually edited to have face 108, then it displays fine in-game when you mouse over them. I've done some pretty heavy searching for "face", "avatar", "look", "beautician", etc in the client's files to try to uncover any other files that pertain to the Beautician's UI, but haven't found anything of note. I'm beginning to fear there's some hard-coded number somewhere (possibly in the client's binary) that dictates the total/max number of faces to display, something that TQ would have manually increased from 102 to 107 when they added the ninja avatars, for example. As a worst case scenario/work around, I could create a new (normal text-based) NPC named Beautician2, stick them beside the original NPC, and use the regular dialogue interface to list out a bunch of options that players could choose "Face108", "Face109", etc, sorta like the hairstyle NPCs, and let the player mouse over their character to see each of the new ones. I'd like to avoid that if possible though. Does anybody happen to know the secrets to wrestling the Beautician into submission?

Aha, figures there would be a 15th ini file you have to change. :) I had made changes for 3dtexture.ini, but not for 3dobj.ini. This also made me realize I had misunderstood what exactly the weapon.ini file was actually doing-- I was under the impression the Mesh0 and Texture0 fields were supposed to list the actual file names (and it was just assuming .c3/.dds extensions), but in reality those fields tell the client which value to look up from the 3dobj and 3dtexture files. Which also means 3dobj and 3dtexture don't need to be entered by the itemid, it seems any random number will work as long as you link it to weapon.ini correctly. https://i.imgur.com/05GHtpX.png 120 shields in 5017 hype. 3DEffectObj seems like it's specifically related to skill/character effects, but I poked around in Action3DEffect and found the 110 shield glow (which I promptly commandeered for the 120 shields). https://i.imgur.com/PZQu2yH.png Unfortunately I won't know if everything related to these shields is fully working until Tinter and MagicArtisan work, but at the very least I can spawn them in and they look great. Thank you both for your help. :)

'Evening, I'm working on adding the level 120 shields to a 5017 client and have hit a bit of a snag with the c3 mesh/texture not being visible. I can see the shields on the ground, in the inventory, and equipped in the character status panel, that's all working great. The only issue is not being able to see the shield in my character's hand, though I did notice that when I equip the shield their stance changes as if they're holding an invisible one. The mesh and texture were taken from a 5290 client, with the hopes that they'd be in the correct format for what Conquer clients expect. So far I've... - Added entries for the 120 shields on both the client's and server's ItemType listing, copying along the format from the previous shields as best I could (https://i.imgur.com/ETuMZzd.png) - Added the mesh file <900100.c3> from the 5290 client into \5017\c3\mesh\ - Added the texture files <901000.dds, 901010.dds, etc> for each colour to \5017\c3\texture\ (https://i.imgur.com/RSXOajk.png) - Added entries to for each shield itemid that points to the mesh and texture files (https://i.imgur.com/PNSQODa.png) - Added entries to and for each itemid - Updated on the client and server for the plus composition bonus Things I've tested/verified... - The c3 mesh appear to be valid, I was able to open it up in a model viewer and it's definitely the 120 shield. - Pointing the 120 shield itemids to the 110 mesh/texture in weapon.ini causes an equipped 120 shield to be visible in-game (albeit with the wrong look), leading me to believe that the way I've inserted the new items into all these .ani/.ini files is likely correct. Anyone have any ideas on what I might be missing? Cheers, Munsie