Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=4955
Not 100% sure, but I think that the previous exploit fix - to add extra checks - is the wrong way to go. Notice how it's still storing .@Economy as a player variable, with a player-controlled pause between the variable setting and the actual processing.
CODE
set .@Economy,GetCastleData(strnpcinfo(2),2);
...
if (.@Economy == 100) {
mes "^ff0000But the commercial growth level of our castle is peaked at 100%. ^000000";
close;
}
...
next;
...
SetCastleData strnpcinfo(2),4,GetCastleData(strnpcinfo(2),4)+1;
By coordinating two people and using @changegm, from this code it appears to be possible, once you have 99 invest, to achieve 101 invest, and then keep on going.
My proposal:
1. apply >= to these invest and defence checks (sure why not)
2. remove the extra checks added by
#49293. add a npc-level mutex (. variable), so that only one person at a time can talk to the npc
The problem with 3) is that
a) npc variables are shared between duplicates, so you'd have to use getd/setd to craft an unique var name for each npc
b) the variable would have to be set upon conversation start and unset upon conversation end - requires changing the structure of the script to have only one close; statement. Or inventing an OnClose event.
If this is not feasible, maybe the following edit can replace step 3)
CODE
switch(select("Invest in commercial growth:Cancel")) {
case 1:
if( GetCastleData(strnpcinfo(2),4) != .@Economy ) {
mes "<something about the invest value changing during conversation, talk to me again>";
close;
}