-
Notifications
You must be signed in to change notification settings - Fork 758
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update stylist.txt #2357
Update stylist.txt #2357
Conversation
yeah this looks better, the CVS style makes the script hard to read I leave it here in case anyone love to have a look |
0eae05a
to
dc7aef7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything seems good. Just a minor newline adjustment required
npc/custom/stylist.txt
Outdated
.maxstyles[LOOK_HAIR_COLOR] = getbattleflag("max_hair_color"); | ||
.maxstyles[LOOK_CLOTHES_COLOR] = getbattleflag("max_cloth_color"); | ||
|
||
.maxstyles[Job_Summoner + LOOK_HAIR] = getbattleflag("max_hair_style"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4218+1
, im not sure if the scripting engine actually allocates all of this but sounds like a bad practice for people that may look into this script for reference, I would suggest using the job id in the array name and use getd
for getting the value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, the script engine can parse it fine,
after Ind upgrade script engine years ago, our array become a pointer
you mean like
setd ".maxstyles"+ Job_Summoner +"["+ LOOK_HAIR +"]", getbattleflag("max_hair_style");
setting a bad practice ... you have a point
imo, instead of start at |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just saying ...
encourage better script practices? not to miss any of those end;
/ close;
. Member who're not aware of these may have issues with the script when they edit it?
if (BaseClass != Job_Summoner) | ||
callsub(L_styles, .@part, .minstyle[.@part], .maxstyle[.@part]); | ||
else | ||
callsub(L_styles, .@part, .summoner_minstyle[.@part], .summoner_maxstyle[.@part]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing end;
?
callsub(L_styles, .@part, .summoner_minstyle[.@part], .summoner_maxstyle[.@part]); | |
callsub(L_styles, .@part, .summoner_minstyle[.@part], .summoner_maxstyle[.@part]); | |
end; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/rathena/rathena/blob/master/npc/custom/battleground/bg_emp.txt#L79
you see, when I actually submit this script to Euphy,
I consider a little bit about changing my usual scripting style to suit rathena general behavior
OnRedDown:
callsub L_EmpDown, "Red", .blue;
end
OnBlueDown:
callsub L_EmpDown, "Blue", .red;
end;
L_EmpDown:
mapannounce "bat_a01", strcharinfo(0) +" has destroyed "+ getarg(0) +" Team's Emperium.", bc_map;
.winside = getarg(1);
awake strnpcinfo(0);
return;
this feels like OnRedDown and OnBlueDown has its own operation and nothing to do with each other
OnRedDown: callsub L_EmpDown, "Red", .blue; end;
OnBlueDown: callsub L_EmpDown, "Blue", .red; end;
L_EmpDown:
mapannounce "bat_a01", strcharinfo(0) +" has destroyed "+ getarg(0) +" Team's Emperium.", bc_map;
.winside = getarg(1);
awake strnpcinfo(0);
return;
I am wondering what the end;
is doing there
in the end, this 1 line method was accepted not only by Euphy, but also lots of rAthena developers
rathena/rathena#3025
I'm quite sure if the callsub
was meant never has a return; there's no need for an end; there
input(.@i, .@minstyle, .@maxstyle); | ||
break; | ||
case 4: | ||
.@i = .@revert; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing break;
?
.@i = .@revert; | |
.@i = .@revert; | |
break; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read a few c++ guide, most guide says there's no need to have break at the last case statement
although I admit I didn't have a default case there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for good practices/habits.
Since most of the cases look similar, its good to have the break;
for each of them.
Protect yourself from doing thing wrongly when you out of a sudden re-ordering the cases in future.
} | ||
} | ||
end; | ||
OnInit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I would prefer these:
OnInit: | |
setarray .look[0], LOOK_HAIR, LOOK_HAIR_COLOR, LOOK_CLOTHES_COLOR; | |
.minstyle[.look[0]] = .summoner_minstyle[.look[0]] = getbattleflag("min_hair_style"); | |
.maxstyle[.look[0]] = .summoner_maxstyle[.look[0]] = getbattleflag("max_hair_style"); | |
.minstyle[.look[1]] = .summoner_minstyle[.look[1]] = getbattleflag("min_hair_color"); | |
.maxstyle[.look[1]] = .summoner_maxstyle[.look[1]] = getbattleflag("max_hair_color"); | |
.minstyle[.look[2]] = .summoner_minstyle[.look[2]] = getbattleflag("min_cloth_color"); | |
.maxstyle[.look[2]] = .summoner_maxstyle[.look[2]] = getbattleflag("max_cloth_color"); | |
end; |
if in the future there are any changes to the constant, I would only need to change 1 line....
cons: it may make the array harder to read/understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.minstyle[.look[0]] = .summoner_minstyle[.look[0]] = getbattleflag("min_hair_style");
totally defeats the purpose of this script
I thought I post in the issue,
explain our stylist outdated because of the introduction of summoner class
if we combine them, when they need to change summoner class have different max_cloth_style,
they wonder why the normal job also change at the same time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope, i meant this
setarray .look[0], LOOK_HAIR, LOOK_HAIR_COLOR, LOOK_CLOTHES_COLOR;
.minstyle[.look[0]] = ......
.minstyle[.look[1]] = ......
.minstyle[.look[2]] = ......
.summoner_minstyle[.look[0]] = ......
.summoner_minstyle[.look[1]] = ......
.summoner_minstyle[.look[2]] = ......
beside the current emulator doesn't introduce a new setting for doram class, they are just sharing the same value at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does, but in stylist_db.conf. In there, Doram class can only go up to hairstyle 6. However, hair_style and hair_dye npcs don't even check class. Anyways, why not put 6 as default max hairstyle for Doram, just like stylist_db.conf? This way the script would be "plug n' play" for server owners with Doram class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's the problem, we want the emulator to simulate official ragnarok online
and not everyone are happy with the official settings
that's why battle_config exist ... to change certain popular configuration without restarting server
that's why custom scripts exist ... script support/request is the most generate post on the forum
what I'm trying to say is, this script should emulate official settings,
but the configuration is there for server who wish to change the value
and not everyone use number 6 either, my test server crash at value no.2
and members can also download/purchase extra cloth in graphic release
by the way, I can understand I need to change my scripting style to suit HULD but senseless, like I don't really see a point in doing like Emistry said because we need more people to help convert scripts into HULD readable format |
- fix ID start with .min_style instead of 1 - add Job_Summoner to have its own specific range
I even make this script HULD compatible, LOL I really wish I can promote HULD ... but the current HULD is not very usable, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good enough, a side note about the comments related to this being linked with stylist db, to be clear this is NOT an official script the goal of this should be to allow for customization and showcase how to do it. stylist_db.conf
is made to be used ONLY with the styling shop user interface and it has client side limitation.
I just notice this script doesn't support 3rd job body style
missing EDIT: can someone confirm Super Novice EX can change body style too ? |
Pull Request Prelude
Issues addressed
#2356
Changes Proposed
Update stylist.txt
Affected Branches
Known Issues and TODO List