Probably the most common situation is when you have two members in your party attacking the same enemy and the first members attack is fatal, the second member will "smoothly" switch to another alive target instead of skipping their turn.
Also what about adding a control on the skill id? If it's equal to this "Help" one it'll skip that line otherwise it will act like always. This way I shouldn't modify too much the original scripts and behaviour.
By using the method you can distinguish between skills that are supposed to be used on incapacitated targets and skills that are not. A suggestion was to use the notebox for that, but you could also go with the skills/items ID instead of course. It's use is similar to your RPG::State#poison? method.
The existence of the method alone does not prevent the user from anything. You have to modify the implementation of the target selection/validation process accordingly to make the result of this method have an impact.
So assuming you set the scope of your skill to "One Ally" (scope 7) and added "<target immovable>" to its notebox, then this should happen:
Target Determination Process:
A list of target battlers is created by invoking make_targets upon the attackers current action:
576#-------------------------------------------------------------------------- 577# * Use Skill/Item 578#-------------------------------------------------------------------------- 579 def use_item
580 item = @subject.current_action.item 581 @log_window.display_use_item(@subject, item) 582 @subject.use_item(item) 583 refresh_status 584 targets = @subject.current_action.make_targets.compact
585 show_animation(targets, item.animation_id) 586 targets.each {|target| item.repeats.times { invoke_item(target, item) } } 587 end
Depending on whether the skill is meant for use on enemies or friends, this method calculates the corresponding target list. Since the attacker is probably not confused (line 147) and the skill is not "for_opponent?" (line 149; here comes the scope into play for the first time) but "for_friend?" (line 151) the targets are decided by the targets_for_friends method.
This method specifies the selected targets depending on the items scope. Since the skill is neither "for_user?" nor "for_dead_friend?" but "for_friend?", the section between line 204 and 208 is considered for deciding the final targets.
As the skill is also "for_one?", the target list will only consist of a single battler retrieved from the units smooth_target method you already found.
191 #-------------------------------------------------------------------------- 192 # * Targets for Allies 193 #-------------------------------------------------------------------------- 194 def targets_for_friends 195 if item.for_user? 196 [subject] 197 elsif item.for_dead_friend? 198 if item.for_one? 199 [friends_unit.smooth_dead_target(@target_index)] 200 else 201 friends_unit.dead_members 202 end 203 elsif item.for_friend? 204 if item.for_one? 205 [friends_unit.smooth_target(@target_index)] 206 else 207 friends_unit.alive_members 208 end 209 end 210 end
---
If you wanted to add additional conditions for a specific scope, you can either modify the corresponding section or extend the method to handle specific cases separately. For example, you could check whether the skill/item is "for_immovable?" first and search for fitting targets.
(This method could probably also be reduced as the "dead friend" section does exactly the same as the "alive friend" section, only for a different set of possible targets)
Target Validation Process:
During the validation test, there is still the problem that "One Ally" as a scope means that the target must be alive, otherwise the condition in line 70 ("The item is for a dead friend" does not equal "the target is dead") is met and the method immediately returns false.
You have to modify this condition if you want to be able to use certain items on alive/dead targets alike. You could change it into
return false if item.for_dead_friend? != dead? && item.for_opponent?
to limit this condition to items that are meant to be used on opponents.
Also, since the method is terminated when the first "return" statement is executed, the upper lines take precedence over the lower ones. Any line past line 71 does not have any effect during battle, so you'll usually have to add custom conditions at the start of the method.
66 #--------------------------------------------------------------------------
67 # * overwrites item_test metod 68 #-------------------------------------------------------------------------- 69 def item_test(user, item) 70return false if item.for_dead_friend? != dead? 71 return true if $game_party.in_battle# <- Everything past this line is not reached in battle 72 return true if item.for_opponent? 73 return true if item.damage.recover? && item.damage.to_hp? && hp < mhp 74 return true if item.damage.recover? && item.damage.to_mp? && mp < mmp 75 return true if item_has_any_valid_effects?(user, item)
76 return false if item.for_immovable? && movable? 77 return false 78 end
I always told my DA fans how much I hate slot machines. They're fine in games as a risk-and-reward system. But when you're spending REAL MONEY in a Vegas casino to try and hit the jackpot (which very, very few people will), it can really hurt your budget. Gambling is a bad habit, and I don't like wasting my money on a slim chance. Go to Vegas for the experience, not the jackpot.
Took the kids to a corn maze. They gave us a map and had lights at certain points in the maze. Not overwhelming... or underwhelming... just... whelming.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
