Vianna

@edit: Here's an updated version

I've worked with the Fimbulwinter Client in C#/XNA and everything was doing OK, but we found out there was no reason to use XNA. We can't use its Content Pipeline, and it was taking a little while to load everything from the GRF (I think the main reason is because Texture2D.FromStream doesn't support .bmp files). Also, it looks like Microsoft isn't going to update XNA anymore.

Change your etcinfo.txt loadingscreen# 4# 4 is the amount of loading screens you have.

Isn't it already done? Last time I checked, they changed it so <yellow> accounts have the suit and <admin> accounts have the right click commands. Unless <admin> accounts only trigger the menu if they are also <yellow> accounts, but then it would be pretty easy to change. If no one else wants to make it, I will as soon as I have enough time.

make sure that different client include this WDGForceClientHashPacket.dll on his diff. or else it cannot connect to the server if the client_hash_check is on what i mean is i want to change the "error" that client given if they're using different client. It's somewhere in msgstringtable.txt

Make sure there isn't a line like this in your clientinfo.xml <readfolder></readfolder>

You must change // Units types affected by max_lv and aura_lv settings. (Note 3) // Note: If an unit type, which normally does not show an aura, is // set it will obtain an aura when it meets the level requirement. // Default: 0 (none) client_limit_unit_lv: 0 to // Units types affected by max_lv and aura_lv settings. (Note 3) // Note: If an unit type, which normally does not show an aura, is // set it will obtain an aura when it meets the level requirement. // Default: 0 (none) client_limit_unit_lv: 1

I think he said he wouldn't do that one because rAthena already supports it.

Why don't you add a new data section to the PE with all the translated strings, so there's no limit to the character count? It'd take longer to patch because you would have to search for all references to the string, but wouldn't it be work the effort? Or maybe you could use the same functions the client uses to access strings from msgstring_kr.lua, using custom indexes (that would look less hacky)

They use a generic formula to generate the table... It's not like the exp table, where every level has an arbitrary amount of exp. Well, if you're going with the fixed table format, it would be nice to include documentation on how the tables can be generated and maybe a new tool to the /src/tool/ folder, so it would still be easy to buff/nerf classes HP and SP while preserving the original increase patterns. AEGIS probably uses a table only to allow the publishers to modify the values without having to ask for recompiled binaries

IMO..for now yes..but once they add a new function to support sending of modified Hash code to server..well that's a hole.. They already do, and it's been a while since it had been implemented. It's still undocumented, though. *coughs* clientHash *cough* servers.txt ~

Enabling/not disabling HackShield using only a diffpatcher wouldn't work. First of all, it would only block packet editors and other cheats that require the original client to be running. OpenKore would still work. X-Kore wouldn't work, but X-Kore Proxy would. And it could be simply disabled by modifying the client to remove it and then intercepting the checksum checks. You need server-side checks.

I meant these settings: // Account data storage configuration // SQL //account.sql.db_hostname: 127.0.0.1 //account.sql.db_port: 3306 //account.sql.db_username: ragnarok //account.sql.db_password: ragnarok //account.sql.db_database: ragnarok //account.sql.codepage: //account.sql.case_sensitive: no //account.sql.account_db: login //account.sql.accreg_db: global_reg_value

Did you change the account database settings in login_athena.conf?

+1 and/or an option to completely disable aura Lv 99/150. max_lv: 98 aura_lv: max level Characters with level 1~(max level - 1) will be sent as level 97 and characters with level (max level) will be sent as level 98: no aura.

Themida does code virtualization. Hot-patching virtualized sections would be rather difficult.

@edit: removed because it could possibly be exploited in production servers, see bugreport:6509

Then we would have to give privileges to alter tables to the MySQL account used by the server =( The database itself could have a row somewhere telling its version, and then when a dev changed the tables in a way that they would have to be updated using upgrade_rXXXXX.sql, he would also increment a constant, let's say, MIN_SQL_DB_VERSION, in mmo.h. The upgrade_rXXXXX.sql file would also change the version number. Then, whenever a server started, it would compare the database's version with MIN_SQL_DB_VERSION and it would print a message saying that the tables were changed and that they have to be updated manually.

I think he means /conf/battle/exp.conf and your max level settings.

Yeah, it's a micro-optimization. I don't think it's worth worrying about it. Let the compiler do its job =)

Maybe the packets moved to their own functions could be moved to their own inline functions instead, so there's no calling overhead and you still have the 'pretty' effect.

You'd better completely remove these maps. Comment their lines from /db/map_index.txt and /conf/maps_athena.conf. So, even if you forget to disable a way to warp to these maps, the players won't be warped and the map-server will report an error message.

http://pastebin.com/zy4TVgM9 tries to find the x, y and z for the recursive function HP(level) = HP(level - 1) + x + ((y + (level - 101) * z) / 1000) given HP(100) and a table to compare the results of HP(a). Using the Ranger table as input, the following output is generated: 90 304 924 (off by one 0 times) 90 305 924 (off by one 0 times) 90 306 924 (off by one 0 times) 90 307 924 (off by one 0 times) 90 308 924 (off by one 0 times) 90 309 924 (off by one 0 times) 90 310 924 (off by one 0 times) 90 311 923 (off by one 0 times) 90 311 924 (off by one 0 times) 90 312 923 (off by one 0 times) 90 312 924 (off by one 0 times) 90 313 923 (off by one 0 times) 90 313 924 (off by one 0 times) 90 314 923 (off by one 0 times) 90 314 924 (off by one 0 times) 90 315 923 (off by one 0 times) 90 315 924 (off by one 0 times) 90 316 923 (off by one 0 times) 90 316 924 (off by one 0 times) 90 317 923 (off by one 0 times) 90 317 924 (off by one 0 times) 90 318 923 (off by one 0 times) 90 318 924 (off by one 0 times) 90 319 923 (off by one 0 times) 90 319 924 (off by one 0 times) 90 320 923 (off by one 0 times) 90 320 924 (off by one 0 times) 90 321 923 (off by one 0 times) 90 321 924 (off by one 0 times) 90 322 923 (off by one 0 times) 90 322 924 (off by one 0 times) 90 323 923 (off by one 0 times) 90 323 924 (off by one 0 times) 90 324 923 (off by one 0 times) 90 324 924 (off by one 0 times) 90 325 923 (off by one 0 times) 90 325 924 (off by one 0 times) 90 326 923 (off by one 0 times) 90 326 924 (off by one 0 times) 90 327 923 (off by one 0 times) 90 327 924 (off by one 0 times) 90 328 923 (off by one 0 times) 90 328 924 (off by one 0 times) 90 329 923 (off by one 0 times) 90 329 924 (off by one 0 times) 90 330 923 (off by one 0 times) 90 330 924 (off by one 0 times) 90 331 923 (off by one 0 times) 90 331 924 (off by one 0 times) 90 332 923 (off by one 0 times) 90 332 924 (off by one 0 times) 90 333 923 (off by one 0 times) 90 333 924 (off by one 0 times) 90 334 923 (off by one 0 times) 90 334 924 (off by one 0 times) 90 335 923 (off by one 0 times) 90 335 924 (off by one 0 times) 90 336 923 (off by one 0 times) 90 336 924 (off by one 0 times) 90 337 923 (off by one 0 times) 90 337 924 (off by one 0 times) 90 338 923 (off by one 0 times) 90 338 924 (off by one 0 times) 90 339 923 (off by one 0 times) 90 339 924 (off by one 0 times) 90 340 923 (off by one 0 times) 90 340 924 (off by one 0 times) 90 341 923 (off by one 0 times) 90 341 924 (off by one 0 times) 90 342 923 (off by one 0 times) 90 342 924 (off by one 0 times) 90 343 923 (off by one 0 times) 90 343 924 (off by one 0 times) 90 344 923 (off by one 0 times) 90 345 923 (off by one 0 times) 90 346 923 (off by one 0 times) 90 347 923 (off by one 0 times) 90 348 923 (off by one 0 times) 90 349 923 (off by one 0 times) 90 350 923 (off by one 0 times) 90 351 923 (off by one 0 times) 90 352 923 (off by one 0 times) 90 353 923 (off by one 0 times) 90 354 922 (off by one 0 times) 90 354 923 (off by one 0 times) 90 355 922 (off by one 0 times) 90 355 923 (off by one 0 times) 90 356 922 (off by one 0 times) 90 356 923 (off by one 0 times) 90 357 922 (off by one 0 times) 90 357 923 (off by one 0 times) 90 358 922 (off by one 0 times) 90 358 923 (off by one 0 times) 90 359 922 (off by one 0 times) 90 359 923 (off by one 0 times) 90 360 922 (off by one 0 times) 90 360 923 (off by one 0 times) 90 361 922 (off by one 0 times) 90 361 923 (off by one 0 times) 90 362 922 (off by one 0 times) 90 362 923 (off by one 0 times) 90 363 922 (off by one 0 times) 90 363 923 (off by one 0 times) 90 364 922 (off by one 0 times) 90 364 923 (off by one 0 times) 90 365 922 (off by one 0 times) 90 365 923 (off by one 0 times) 90 366 922 (off by one 0 times) 90 366 923 (off by one 0 times) 90 367 922 (off by one 0 times) 90 367 923 (off by one 0 times) 90 368 922 (off by one 0 times) 90 368 923 (off by one 0 times) 90 369 922 (off by one 0 times) 90 369 923 (off by one 0 times) 90 370 922 (off by one 0 times) 90 370 923 (off by one 0 times) 90 371 922 (off by one 0 times) 90 371 923 (off by one 0 times) 90 372 922 (off by one 0 times) 90 372 923 (off by one 0 times) 90 373 922 (off by one 0 times) 90 373 923 (off by one 0 times) 90 374 922 (off by one 0 times) 90 374 923 (off by one 0 times) 90 375 922 (off by one 0 times) 90 375 923 (off by one 0 times) 90 376 922 (off by one 0 times) 90 376 923 (off by one 0 times) 90 377 922 (off by one 0 times) 90 377 923 (off by one 0 times) 90 378 922 (off by one 0 times) 90 378 923 (off by one 0 times) 90 379 922 (off by one 0 times) 90 379 923 (off by one 0 times) 90 380 922 (off by one 0 times) 90 380 923 (off by one 0 times) 90 381 922 (off by one 0 times) 90 381 923 (off by one 0 times) 90 382 922 (off by one 0 times) 90 382 923 (off by one 0 times) 90 383 922 (off by one 0 times) 90 383 923 (off by one 0 times) 90 384 922 (off by one 0 times) 90 384 923 (off by one 0 times) 90 385 922 (off by one 0 times) 90 386 922 (off by one 0 times) 90 387 922 (off by one 0 times) 90 388 922 (off by one 0 times) 90 389 922 (off by one 0 times) So, perfect matches for all the levels, it seems like it's the formula used by kRO =P And if it's not, it's good enough.

In my opinion, Vulture's Eye bonus not showing up in AEGIS is a bug and it shouldn't be replicated in rAthena... @edit When bRO updated to Renewal, ItachiSan from Cronus Emulator figured out how the HP formula works above level 99. AEGIS used a table only to avoid calculating the values in runtime (and probably to allow server-specific values). http://trac.cronus-e.../changeset/3144 Formula: HP(level) = undefined, if level < 99 HP_99, if level == 99 HP_100, if level == 100 HP(level - 1) + Job_HP + floor(Base_Value + (level - 101) * Level_Multiplier), if level > 100 Level_Multiplier and Base_Value have at most 2 decimal places. All constants are unique to each job (but not to each class, so Baby Rune Knight, Rune Knight and Rune Knight Trans have the same values). I'm not sure if bRO and kRO formulae are the same, but it's a start. Also, according to him, there seems to be a rounding bug that was only noticed after the HPs got big enough. rAthena does: MAX_HP = floor(floor((BASE_HP * (1 + VIT / 100)) * TRANS_BONUS) AEGIS does: MAX_HP = floor(floor((BASE_HP * TRANS_BONUS) * (1 + VIT / 100))

Relevant information: For those worrying about user-friendliness of TortoiseGit, the new GitHub for Windows looks pretty simple to use.