The Lycan ABS - Printable Version+- Save-Point (https://www.save-point.org)
+-- Forum: Material Development (https://www.save-point.org/forum-8.html)
+--- Forum: Scripts Database (https://www.save-point.org/forum-39.html)
+---- Forum: RPGMaker XP (RGSS) Engine (https://www.save-point.org/forum-116.html)
+---- Thread:
The Lycan ABS (/thread-4422.html)RE: The Lycan ABS - DerVVulfman - 02-07-2014
The method used is based on the order in which the hotkeys are stored. This means the absolute least amount of time is needed to gather, place and render them within the hud. Yep, in the ABS hud addon script. If you wanna look into changing their order, you would be hitting up the refresh_item_hotkeys and refresh_skill_hotkeys methods.
RE: The Lycan ABS - DerVVulfman - 03-12-2014
BUMP!
to Version 5.0
to Version 5.0
For those of you interested in knowing why the new update, many things have been changed in The Lycan ABS. The major changes within come in three parts and are nearly exclusive to the ABS ENGINE code segment itself. A few changes have been performed within other script sections, but those will be explained.
First, The ABS Engine itself has been subdivided into four smaller units: General, Enemy, Player and Companion. The reason for this is to let a coder (like myself) to more easily find a method within the vast system, such as a feature that controlled a player's missile attack trigger. Before, you would have to search through nearly 5500 lines of code to find the correct method. Now, you only have 1300 for the player system. Yes, it is still over 1000 lines for the player, but it is a very detailed and comprehensive system.
Second, the methods within the Enemy, Player and Companion sections of the ABS Engine have been renamed so they all follow the same naming convention. No longer would you have a method called 'update_enemy_attack_skill' for enemies while a companion uses 'companion_ranged_spell?' Now, the three types of battlers (enemy, player and companions) use the same naming style for virtually all action methods. Insofar as attacks are concerned, all attacks follow the premise of combatant decision (you pressing a key or the enemy decides to be aggressive), readying an attack, starting the attack animation and delay set, and getting a result when the delay runs out. The typical naming standards would be update_xx_attack, update_xx_attack_*type*, update_xx_attack_*type*_perform, update_xx_attack_*type_result. The *type* would be substituted with melee, ranged, skill, and so on.
Before anyone frets over the methods being renamed, I did make a list of all methods renamed and know what classes/methods needed to be changed.
In fact, here's the list of renamed methods:
Code:
PART 1: GENERAL METHODS
# Method Name # Original Name (Renamed)
----------- -----------------------
update_range_missile update_range_fired_weapon
update_range_skill update_range_fired_skill
update_range_barrier update_range_fired_barrier
update_range_barrier_event barrier_event
update_range_barrier_tile_available? barrier_tile_available?
================================================================================
PART 2: ENEMY HANDLING
#Method Name # Original Name (Renamed)
update_enemy_test_alive update_enemy_alive
update_enemy_test_coward cowardice_check
update_enemy_force_call_set force_enemy_call_set
update_enemy_force_call_remove force_enemy_call_remove
update_enemy_force_move force_enemy_move
update_enemy_force_see force_enemy_see
update_enemy_force_attack force_enemy_attack
update_enemy_force_obtain_hp force_enemy_obtain_hp
update_enemy_force_obtain_sp force_enemy_obtain_sp
update_enemy_force_obtain_hpmax force_enemy_obtain_hp (corrected)
update_enemy_force_obtain_spmax force_enemy_obtain_sp (corrected)
update_enemy_force_damage_hp force_enemy_damage_hp
update_enemy_force_damage_sp force_enemy_damage_sp
update_enemy_force_apply_state force_enemy_apply_state
update_enemy_respawn update_respawn
update_enemy_respawn_locations update_respawn_locations
update_enemy_attack_result update_enemy_reactions
update_enemy_attack_result_melee update_enemy_attack_melee_result
update_enemy_attack_result_skill update_enemy_attack_skill_result
update_enemy_attack_result_barrier update_enemy_attack_barrier_result
update_enemy_event_movement_style update_enemy_target_and_movement
================================================================================
PART 3: PLAYER HANDLING
#Method Name # Original Name (Renamed)
update_player_attack_defend update_player_defend
update_player_attack_skill update_player_skill
update_player_attack_item update_player_item
update_player_attack_mine update_mine_trigger
update_player_attack_action update_player_attack_switch
update_player_attack_skill_action update_player_attack_skill
update_player_attack_item_action update_player_attack_item
update_player_attack_result update_player_reactions
update_player_attack_result_attack update_player_attack_result
update_player_attack_result_melee update_player_attack_melee_result
update_player_attack_result_ranged update_player_attack_ranged_result
update_player_attack_result_skill update_player_attack_skill_result
update_player_attack_result_item update_player_attack_item_result
update_player_attack_result_barrier update_player_attack_barrier_result
update_player_attack_result_mine update_player_attack_mine_result
================================================================================
PART 4: COMPANION HANDLING
#Method Name # Original Name (Renamed)
update_companion_attack_melee companion_melee_attack
update_companion_attack_ranged_action companion_ranged_weapon?
update_companion_attack_spell_action companion_ranged_spell?
update_companion_attack_barrier_action companion_ranged_barrier?
update_companion_attack_heal_action companion_heal?
update_companion_attack_force_heal_action companion_force_heal
update_companion_attack_cure_action companion_cure?
update_companion_range_attack companion_range_attack?
update_companion_range_help companion_range_help
update_companion_attack_result_melee companion_melee_result
update_companion_attack_result_range companion_ranged_weapon_result?
update_companion_attack_result_spell companion_ranged_spell_result?
update_companion_attack_result_barrier companion_ranged_barrier_result?
update_companion_attack_result_heal companion_heal_result?Routines outside the ABS Engine Affected:
Code:
update_enemy_force_see (formerly force_enemy_see)
* Used within 'move_toward_player' in Game Code: Game_Character
update_enemy_force_attack (formerly force_enemy_attack
* Used within 'move_toward_player' in Game Code: Game_Character
update_enemy_event_movement_style (formerly update_enemy_target_and_movement)
* Used within 'hit_event' and 'explode event' in...
- Game_Ranged_Weapon, Game_Ranged_Skill, Game_Ranged_Item,
- Game_Ranged_Barrier and Game_Landmine
* Used within 'reset_enemies_after_load' within Scene Code: Scene_Load
Combatant Code: Game_ABS_Companion > update
* update_companion_range_help (formerly companion_range_help)
* update_companion_attack_melee (formerly companion_melee_attack)
* update_companion_range_attack (formerly companion_range_attack?)
* update_companion_range_help (formerly companion_range_help)
Combatant Code: Game_ABS_Companion > heal
* update_companion_attack_force_heal_action (formerly companion_force_heal)
* update_companion_range_help (formerly companion_range_help)
Combatant Code: Game_ABS_Companion > update_reactions
* update_companion_attack_result_melee (formerly companion_melee_result)
* update_companion_attack_result_range (formerly companion_ranged_weapon_result?)
* update_companion_attack_result_spell (formerly companion_ranged_spell_result?)
* update_companion_attack_result_barrier (formerly companion_ranged_barrier_result?)
* update_companion_attack_result_heal (formerly companion_heal_result?)
And third, many systems have been subdivided into smaller components for both cleanliness sake and a streamlining feature. Some of these smaller components are being shared by two or more methods, so some semblance of reduced code size has been made (if it wasn't for all my 'comments ^_^ ). This should enable coders (again... like myself) to create new script add-ons which can attach to The Lycan ABS without the necessity to overwrite sections.
I did move the 'enemy states' method out of update_enemies and move it into update_states. It seemed fitting as it is a routine to check all other status effects if any.
MEANWHILE: It also includes an updated version of The Lycan HUD and JayRay's Lycan GameLog.
RE: The Lycan ABS - DerVVulfman - 03-14-2014
Time for a
BUMP!
to Version 5.1
BUMP!
to Version 5.1
Two more methods were renamed in the demo, the first to differentiate it from a another method with a nearly identical name while the other to show it's similarity to a default system method.
Within the ABS Engine, the 'in_range' method (not the in_range? method) was renamed to 'targets_in_range'. The name was chosen to show how it is used to acquire targets within a certain range, and while used mainly in the ABS engine itself, it is also used by the 'update_destroy' method in the Game_Companion class... a part of the Game_Code page.
Meanwhile, the method known as 'update_enemy_attack_decisions' was renamed into 'update_enemy_attack_make_action' in order to punctuate a similarity to the 'make_action' method within the default Game_Enemy class.
So no actual bug fixes were performed...
HOWEVER, the .chm manual for the Lycan ABS was updated in regards to descriptions within the Q/A section and the Feature Effects section.
And now included is an .rtf file which catalogs each method in the ABS engine itself.
Oh... and Uruhara finally got me to post a pair of screenies from the demo.
RE: The Lycan ABS - DerVVulfman - 04-03-2014
Ladies and gentlemen...
Boys and girls...
BUMPIN! TIME is here.
Boys and girls...
BUMPIN! TIME is here.
Now at version 5.3, there are two things have been changed in the ABS engine itself.
First, the system apparently responds faster, so it stood to reason that I needed to put in safeguards into the system that checked if a
target was killed. A simple fix, I added an additional statement into the 'victim_not_dead?' method to prevent already erased enemies from
being run through again.
And the second was a repair to the companion's skill using system. A minor alteration was performed which allowed you to set up whether a skill being used was a normal skill or a barrier skill. Unfortunately, it was hard-set to only a barrier skill, even when using a minor fire missile skill... something that needed repairing in the 'update_companion_attack_skill_action_perform'.
Easy enough to upgrade your system... Either replace the methods I so noted, or just the 1st and 4th parts of the ABS Engine itself.
RE: The Lycan ABS - DerVVulfman - 04-03-2014
Whoops...
DerVVulfman is doin' tha BUMP once again.
Now at version 5.4, this repairs something I accidentally broke in the last update. I erased a statement within the method that checks if a victim is dead or not. I re-inserted that line, cleaned it up, and added another method that ensures that enemies that re-spawn do not show up a second time to drop off more treasure.
Yep, you heard that right guys. Enemies that re-spawned coulda dropped off TWICE the amount of loot that they should have dropped. No more double-dipping!!!
Meanwhile, I added a bit more to the Questions and Answers section of the help/.chm file available in the demo downloads.
RE: The Lycan ABS - DerVVulfman - 04-18-2014
We have a Semi-BUMP going on right now.....
This bump isn't for the actual Lycan ABS, but for the bonus Multiple Pose and Paperdoll systems that are included in the forum's exclusive demo. Refined a bit, the new versions repairs a glitch where the ABS's default animated pattern system interfered with the revised one within the multiple pose's system. In doing so, I also fixed a weird glitch that affected the way idle animations had shown. And the standing pose (if the player used a separate standing frame) doesn't flicker anymore.
RE: The Lycan ABS - DerVVulfman - 05-08-2014
Greetings,fellow readers, as it is now time for one more LYCAN BUMP to occur! Yes, two more things have changed to the system, and both repairs of diverse natures.
The first thing that was changed was within the Ballistics Code of the system. To be specific, the change occured on line #282 in the explode method of the Game_Ranged_Base class. The change performed properly centers the explosion animation at the point of impact.
Code:
animation3 = Animation.new('tile',@x,@y-1,@animate_id, 1)Now you may see the code and wonder 'Why is the y value raised one tile?' To be honest, it is a visual factor as most targets are 'taller' than the normal 32x32 tile and this is an aesthetic decision which appears to work nicely.
The second thing that was changed was a bug fix, yet no one made any report. The fix relates to a feature called barriers, which is a skill effect where a battler can create a wall (be it a static wall of stone or a moving wall of fire). To affect the fix, the ABS Engine (General) page had to be edited. The change takes place on line #1584 in the animation_routine_skill method of the Game_ABS class. This change allows the system to properly read from the BARRIER_CUSTOM array when it was accidentally reading from the RANGE_SKILLS array by accident.
Code:
suffix_img = Lycan::BARRIER_CUSTOM[skill_id][15]As popular the feature was with the game 'Diablo', I was surprised no one made any such bug report.
* * *
Meanwhile, the HELP file accompanying the demos had been given an update in the Q&A section for those curious about having a WASD system; credits to swickster for the inquiry.
RE: The Lycan ABS - DerVVulfman - 05-16-2014
Time for a
BUMP!
to Version 6.6
BUMP!
to Version 6.6
First off, I performed some cleanup and changes to all six classes within the Ballistics section. Not much was changed save for some cleanup and the creation of new methods within the Game_Ranged_Base class which are used throughout most of the other classes. If it weren't for the extensive amount of comments within, the page would be even smaller than it is now.
While nearly all methods within still have the same names, only six of note were changed, mainly for naming conventions. Two of these were the methods 'abs_through_target' (now 'is_through_target?') and 'abs_dead_companion?' (now 'is_dead_companion?') from the Game_Ranged_Base class, It was done this way to give a more standardized look as it is inquiring if a companion was dead or etc. The 'get_all_explode' method in both Game_Ranged_Base and Game_Landmine has now become the 'explode_all_object_range' method, aptly renamed as it is only used to detect objects in an explosive radius. And the 'set_engaged' method was renamed 'set_engaged_enemy' as a matching ''set_engaged_actor' method was created. Finally, the 'blow' method in Game_Landmine was renamed to 'explode' to mimic the name of a like method within Game_Ranged_Base.
Ballistics Code Changes
After that, I began tackling the code in the Game ABS engine code once again. Like before, this was to make some of the methods cleaner by subdividing them with smaller components. Like I did with the ballistics section, I added a routine into the page that handles most general routines (aka Pg 1, General Routines). This routine is called 'update_range_attack?' and is a method used in various enemy and player melee and skill attack systems. It checks to ensure that the attacker is facing his target and that the target is in range of his attack.
The section that covers enemy handling systems had the coward checking and respawn systems made smaller by having it execute subroutines themselves. These separate routines cycle through enemies and companions for their related check and delay systems. Meanwhile, I altered some methods that handled some of the enemy behavior routines. They weren't changed bigtime, but had marginal changes to make the methods appear cleaner and more concise.
For the Player control section, I altered the attack melee routine that actually performs strikes upon enemies and companions by creating two new smaller routines that handles their strikes.
ABS Engine Changes
And though it is not within the actual ABS Engine code, a new method was added within the Game_ABS_Companion class, a part of the Game Code page. This method, update_melee_attack_decision, performs in the same way as the 'update_range_attack?' method in the Game Engine. However, it doesn't have to check facing. Before each attack, the companion always turns to face the target. Automatics are nice.
However, two methods were lightly touched to make them appear cleaner. They handle traps and scouting actions.
Game Code Changes
And that's it!
RE: The Lycan ABS - DerVVulfman - 05-27-2014
Lets give the Lycan ABS a
BUMP!
to Version 7.4
BUMP!
to Version 7.4
Some more changes and streamlining were done, breaking down some of the methods in the various pages in the ABS.
My first job was to search through and tackle anything that needed altering in the Modules page. My first actual target was the RPG::Sprite class itself. Streamlining in the class name itself was performed, but that isn't a big deal. However, more work was performed to make the RPG Sprite class more compatible with other systems. Initially, the animation and update_animation methods were rewrites, but I eliminated the update_animation code from the system and decided to alias both the animation and dispose_animation methods as a fix. I had also broken up the update method, and created two new methods for its use; update_abs_system_collapse and update_abs_system_duration. And after that, I followed suit and made three new methods for use between the damage pop methods, these new methods are damage_pop_bitmap_set, damage_pop_bitmap_ouline and damage_pop_sprite.
After that, I went towards the Combatant code, cleaning up a little here and there. The Game_ABS_Enemy class went through the most, having deleted almost everything. As the class was an almost exact copy of the Game_Enemy class, I decided to have Game_Enemy be the parent class to Game_ABE_Enemy rather than Game_Battler. In that, I only needed to keep two methods and the attributes section. However, the initialize method was rewritten to be stand-alone, not drawing on Game_Enemy's 'initialize' as that requests both troop and member index values. So instead, I copied most of the 'initialize' method of Game_Battler and added it to Game_ABS_Enemy's. Besides the 'initialize' method, only the 'can_use_skill?' method remained. By doing so, the amount of code for the class was literally cut in half.
Also, this required very minor changes to both Lycan Enemy Bars and Lycan Audible Alerts. That was the very first change I ever made to the Lycan Enemy Bars since I coded it three years ago! Three years?
The Game_ABS_Companion class was more complicated than the Game_ABS_Enemy class though, being a child to the Game_Character class and relying on ties to the Game_Actor database for purposes of damage and combat mechanics. The first revision I made was towards the 'refresh' method, extracting some of the code to form three new methods called 'refresh_no_members?', 'refresh_not_valid?' and 'refresh_character'. This was followed up by editing the 'update' method and forming the 'update_ai_attack?' method and its two smaller parts, 'update_position_forward' and 'update_position_rear'. These two last pieces are used to handle companion attack decisions based on whether they stand back or get into close quarter combat. And the 'update_reactions' method was renamed 'update_attack_result' much like the 'update_player_attack_result' method in Game_ABS.
Meanwhile, it bothered me that I could 'TALK TO THE CAT' throughout the whole demo. Sure, i made the companion command system. But it would be a total cheat for the demo if you just left Jane the Cat on one map while you faced all the dangers. Part of the challenge is that you had to make sure she didn't get killed too, and if you could tell her to stay put on a map kinda ruined that. So I made a minor change to the Game_ABS initialize and attributes sections (ABS Engine Pg 1), added a new command to the Companions page (ABS Engine Pg 4) and to the 'check_event_trigger_here' method for the Game Player class in the Game Code page. Now you can use a new script call to turn the dialog system on and off.
While I was IN the Dialog mood, I did some minor 'subdividing' of the Window_Dialog class used by the companions dialog system. At the same time, I also attacked the Window_MenuStatus and Window_Ammo classes in my Window Code page. Alas, some methods in there are actual rewrites which could not be avoided. But if I can break them into smaller and more manageable portions, I will.
And the last thing I had to deal with in regards to the Lycan ABS itself was an error detected in the ballistics section. It appeared when an explosive effect was to take place around companions. At the same time, a similar error was found when an enemy was caught in an explosion. Obviously, these errors have been corrected.
* * *
So again, I did some minor changes to Lycan Enemy Bars and Lycan Audible Alerts. But for those using the paperdoll system, I performed a minor change to Frank's MultiPose Charactersets. It was in the 'animation_single_action_pose' that additional error-preventative values were introduced to prevent crashes.And that's that!
RE: The Lycan ABS - DerVVulfman - 05-28-2014
BUMP!
to Version 8.4
to Version 8.4
My last update to the Lycan ABS involved a little touch-up to the Windows Page. Again, I mentioned how I was forced to rewrite a couple of methods some time ago, specifically the 'draw_item' methods within Window_Item and Window_Skill and the 'refresh' method in Window_MenuStatus. These rewrites were merely so the player could see if targeted skills or items were able to be used during ABS play, or if a companion was available.
I had returned to my Windows page and disected the methods within and broke them down into more manageable and much smaller components. And on a separte note, I plan on doing the same within the ReGaL project. Meanwhile, I also wish to point out that the methods that render icons use my cache testing system ensure the icon is available before rendering is attempted. If the icon isn't in the project, this will prevent accidental crashing.
And after that, I went after some of the classes within the Scene Code page itself. I targeted the Scene_Title class, breaking into the command_new_game method to create two new methods to handle the companions. Then, I tackled the Scene_Map class, splintering off sections of code from its update method so the additional animations, music timer and combo delay features were isolated. And after that, I targeted both the Scene_Item and Scene_Skill classes, slicing up their update_item (or update_skill) methods and sliced up Scene_Item's ammunition clip system. The classes that followed (Load, Save, Battle...) didn't really need much in way of edits, though I may return at a later date for them.
And in case no one knew, I have been updating the help file with a list of the methods in each script page.