Wildcard

I really really wanted to avoid weighing in on this, mostly because of how I feel guilty about just disappeared from the scene, but what the hell. I am not saying I'd resume working as a dev on rA if the switch to GIT and a RE-branch was made. That would be grossly unfair, untrue and I am not sure I would have the time and motivation to go through with it. But I will say that not adressing my issues with the code bloat from #defines has played a part in my silent retirement and cease to work on RE-atk. In my opinion, to do RE right, it has to be done.We know so much more about the internal workings of AEGIS these days that rewriting the atk/battle system should come with a complete revision of a LOT of parts of the code. And that is just plainly not doable without breaking the compatibility of that branch with pre-RE. For those who care, here is what I think would need to happen for a really good implementation fo RE-atk, gathered in my months of working on it: Item DB needs a column for MDef (in addition to the script command). The reason for this is complicated (lr_flag) Item scripts would need a complete overhaul. Race/Size/Ele/Range/Etc modifiers need to be changed to a format that more closely follows AEGIS' (to simplify battle calcs); struct weapon_data needs to follow suit The special treatment of the arrow equip slot needs to be changed. It results in so much redundant, unnecessary code (lr_flag) A lot of the status code needs adapting to those new formats (most prevalently, status_calc_def2) A few side effects should be put from the battle calcs to more fitting places. A calc function should be able to be called without side effects I'm sure I'm forgetting something A lot of stats/substats need to be re-typed to signed types (atk, def...). this is probably one of the biggest ones on my list I dont think a "proper" solution is possible without branching. One could argue for putting those db/script changes into pre-re as well, but I plainly don't see that happening. There are too many unknowns. All that said, this is just my rambling as a short-time ex-dev. You guys have to find your own priorities, and I cannot promise you I will ever find the drive to work on rA again. I wish I could! Best of luck with the project, Wildcard

Alright, time for some Q&A! In my most recent version, just changing away from 3rd class constitutes a break from the class hierarchy, as well it should. Thanks for pointing it out! Super novice is a bit ugly because for all intents and purposes, it's a 2nd job, but it has no 1st job associated with it. It thus needs special handling in many parts of the source. And yes, the code will read the max job level for the current job from the db. An argument could be made to not give the maximum number of skill points for any job that has a jobchange_level associated with it, though. I'm still brooding over this, since I don't want to make life harder for custom max job levels. As I stated in the bug report itself, that issue is unrelated, and will be fixed as soon as we implement the feature I described. It's rather ugly to do with the current source, though. (the code zeroes skill ids you are not allowed to put skill points into, durrr.) Sorry for the slow progress on this, it will be rather busy for me still until mid-august.

Oh look a dead topic resurrected! I will re-furbish the code a little, torture test it some more, adress the concerns voiced and commit it as soon as I get my internet back at home (hopefully this thursday, or else!) <3

I've added a TODO in the wiki a while ago. I'm currently not in a position to do this myself anytime soon though. My 50 cents on this are that it should probably be done in a seperate branch and torture tested with lots and lots of clients to avoid breakage. Probably also relevant for exact(?) dates when packets were changed/introduced: packet deltas.

This is true, and has been brought up many times, it's just that noone has gone through with it yet. I added a TODO on the wiki.

Summary I would like to propose a modification to the job change system that deals with cases that are not supposed to happen in regular gameplay. By using @job, or just a haphazard jobchange npc, it is possible to create characters that never went through the right job order, and thus lack skill points/cannot skill certain skills/exhibit other flaws especially revolving around the NV_BASIC skill. My modification would force the code to go back to novice and walk the job tree all the way, and provide the right amount of skill points along with a skill reset. In essence, it is supposed to give GMs cleaner scenarios when testing jobs. Motivation There is a large number of would-be bugs and generally random/undesirable effects in the current system (see this bug) that this change would address. In light of r15625, where I removed a couple of clumsy workarounds in the source that sort of dealt with the issues(but really only masked them), The fact that I need to use @skpoint to fix such characters is also something that has been personally bugging me since the first time I ever used @job on *Athena. I want to commit this more than anything. However, since it is a rather substantial modification, I thought I would run it by everyone before committing the changeset. Are there any objections or concerns on your side? Anything I may have missed? Proposed Solution This diff also includes a couple of related fixes to what I can only believe to be oversights on the authors. I should probably commit those regardless of what we decide on this issue. Testing is still ongoing on my end as well. pc_jc.patch

Should be fixed in r15609.

Good changes, but may I suggest adopting the import-tmpl/import logic for this file as well, since if one file violates the concept, it's pretty much moot