Guess what, fellow RM'ers? I have released KPortrait and KMessage XP early this morning. They have reached version 1.0.7 already. Did I say "released"? Well, actually I only sent it to the only authorized user in existence and nobody else. Curiously it seems they don't need any further debugging nor upgrade of any kind... unless that forumer comes up with another crazy idea... =_= Why do I say that? Because I have to implement some sort of typewriter speedometer! I also changed the default settings for face alignment as per request... I fixed some issues with not clearing images properly as well.

The Internet might be either your best friend or your worst enemy. It just depends on whether or not she has a bad hair day.

I have been thinking about adding appraisals in KyoDiscounts series so the shopkeepers can act as appraisers as well. In few words, storekeepers might find out what kind of item you have got, he or she will identify it for you. I will try to make it optional as some people might not want to let their players get their mysterious items appraised in every single town they included in their games.

The Internet might be either your best friend or your worst enemy. It just depends on whether or not she has a bad hair day.

Sounds like a good idea. What about having to pay a fee to get your items appraised? This way, you could gatekeep really rare items behind exorbitant prices to prevent the players from getting them earlier.

On a different subject, is there a way to make a status buff permanent on a player once they have learned a skill on XP?

Here I will leave my KyoDiscounts XP version 1.5.0 alpha or beta release in case anybody wants to report any issues with features already present in the previous version. That means people might test everything except for appraisals themselves since I haven't really worked on it. Nope, that is not a problem, what happened here is that I wanted to implement a different way to determine which command or buy or sell or discount window should be active at any given time to reduce the number of required checks and support future improvements, including appraisals. That might also mean I still have stuff that I have not fixed, yet...

# Whenever you obtain a discount card, such discount will be applied to all
# of your purchases if you have picked a card till it expires after a certain
# number of steps. Additional steps will be quickly added to your current card
# whenever you purchase any additional card of the same kind.

# One coupon will be spent every single time you purchase any specific item,
# you will need another one to purchase a different item later on.
# The discount card or coupon price is used to calculate the corresponding
# discount on every single purchase the player makes with it.

# Place this script below KItemRefill XP or KyoScriptPack Item XP if you
# included any of those scripts in your current game project.

# Now you can also setup exclusive store discount cards as well. Just keep in
# mind that you will need to setup the in game variable you picked so it will
# be able to store the Exclusive Store Code (an Integer) before you can add
# the shop event command. Common stores don't need any Store Code at all.

# Besides the player can also place orders to get an item that is supposed to
# be found at another store only. The player will be charged an extra fee, but
# he or she won't need to go back to another store. The player would only need
# to keep walking for a while before the goods are available at the store.
# Now the required steps for each placed order will be automatically increased
# between 0% and 50%, making it look a bit random but also kind of realistic.

# Script Calls #

# $game_party.discount_cards_expire
# Makes all Discount Cards expire as part of the game's plot.

# $game_party.disc_card_expire(Card_ID)
# Makes an specific Discount Card expire as part of the game's plot.

# KyoShopOrders << [Percent1, Percent2, etc.]
# Defines a Commission percent for every Item in the Place Order List.

# KyoShopOrders.steps = [Steps1, Steps2, etc.]
# KyoShopOrders.steps += [Steps5, Steps6, etc.]
# Defines Steps required by every Order in the Place Order List.
# The 2nd call will be required only if you couldn't include all steps.

# KyoShop.scarcity_lvl = 0 or higher
# Define all prices and maximum number of units per shop item.
# 0 means no scarcity, 1 or higher reflects how severe it is.
# You also have to configure the @scarce_limits hash in order to predefine
# :price and :max per scarcity level. The maximum scarcity level depends on
# how many values you entered in both :price and :max arrays.
# In few words, you define the maximum scarcity level ever possible!

def check_discounts
unless @discounts.empty?
for did in KyoShop::DISCOUNT_IDS
next unless @discounts[did] and @discounts[did] > 0
return true if $game_system.disc_store?(did)
return true if $game_system.excl_disc_store?(did)
end
end
for cid in KyoShop::COUPON_IDS
next unless item_number(cid) > 0
return true if $game_system.disc_store?(cid)
return true if $game_system.excl_disc_store?(cid)
end
return false
end

def update
@help_window.update
@gold_window.update
@dummy_window.update
@sell_window.update
@status_window.update
case @stage
when :main then update_command
when :option then update_option
when :purchase then update_purchase
when :place then update_place_order
when :pickup then update_pickup_order
when :discount then update_discount
when :appraise then update_appraisal
when :sell then update_sell
when :number then update_number
end
end

def check_number
return number = case @item
when RPG::Item then $game_party.item_number(@item.id)
when RPG::Weapon then $game_party.weapon_number(@item.id)
when RPG::Armor then $game_party.armor_number(@item.id)
end
end

(01-12-2019, 12:03 PM)Steel Beast 6Beets Wrote: On a different subject, is there a way to make a status buff permanent on a player once they have learned a skill on XP?

Are you talking about having a status bonus effect such as "Haste"? I never saw anyone make a status effect fully permanent. Well, not one that is not concealed in some way (ie ... vampirism or something ^_^). It need not require a script either. Performing a test, I just took DAZZLE, and knocked off anything that made the state vanish: Unchecked the 'Release at the end of battle' , set 'after X turns' to 0, and set both chance to release values to 0%. Other than making Aluxes totally weak on combat it works just fine. I used an event and made him already "Dazzled" before he enters battle, and he emerges still Dazzled after.

Up is down, left is right and sideways is straight ahead. - Cord "Circle of Iron", 1978 (written by Bruce Lee and James Coburn... really...)

# Whenever you obtain a discount card, such discount will be applied to all
# of your purchases if you have picked a card till it expires after a certain
# number of steps. Additional steps will be quickly added to your current card
# whenever you purchase any additional card of the same kind.

# One coupon will be spent every single time you purchase any specific item,
# you will need another one to purchase a different item later on.
# The discount card or coupon price is used to calculate the corresponding
# discount on every single purchase the player makes with it.

# Place this script below KItemRefill XP or KyoScriptPack Item XP if you
# included any of those scripts in your current game project.

# Now you can also setup exclusive store discount cards as well. Just keep in
# mind that you will need to setup the in game variable you picked so it will
# be able to store the Exclusive Store Code (an Integer) before you can add
# the shop event command. Common stores don't need any Store Code at all.

# Besides the player can also place orders to get an item that is supposed to
# be found at another store only. The player will be charged an extra fee, but
# he or she won't need to go back to another store. The player would only need
# to keep walking for a while before the goods are available at the store.
# Now the required steps for each placed order will be automatically increased
# between 0% and 50%, making it look a bit random but also kind of realistic.

# * Unknown Item or Weapon or Armor Appraisals *

# Use the Game Variable defined in the STORECODEVARID Constant to store the
# Shop ID that will include the appraisal service.
# Use the MYSTERIOUS series of Arrays to include as many IDs of unknown items
# or weapons or armors that will serve as fillers till they get replaced by
# the actual goods they represent.
# Follow the Instructions included in the APPRAISALS Hash to define all
# conditions that will affect an appraiser's task of identifying the item.

# Script Calls #

# $game_party.discount_cards_expire
# Makes all Discount Cards expire as part of the game's plot.

# $game_party.disc_card_expire(Card_ID)
# Makes an specific Discount Card expire as part of the game's plot.

# KyoShopOrders << [Percent1, Percent2, etc.]
# Defines a Commission percent for every Item in the Place Order List.

# KyoShopOrders.steps = [Steps1, Steps2, etc.]
# KyoShopOrders.steps += [Steps5, Steps6, etc.]
# Defines Steps required by every Order in the Place Order List.
# The 2nd call will be required only if you couldn't include all steps.

# KyoShop.scarcity_lvl = 0 or higher
# Define all prices and maximum number of units per shop item.
# 0 means no scarcity, 1 or higher reflects how severe it is.
# You also have to configure the @scarce_limits hash in order to predefine
# :price and :max per scarcity level. The maximum scarcity level depends on
# how many values you entered in both :price and :max arrays.
# In few words, you define the maximum scarcity level ever possible!

def check_discounts
unless @discounts.empty?
for did in KyoShop::DISCOUNT_IDS
next unless @discounts[did] and @discounts[did] > 0
return true if $game_system.disc_store?(did)
return true if $game_system.excl_disc_store?(did)
end
end
for cid in KyoShop::COUPON_IDS
next unless item_number(cid) > 0
return true if $game_system.disc_store?(cid)
return true if $game_system.excl_disc_store?(cid)
end
return false
end

def update
@help_window.update
@gold_window.update
@dummy_window.update
@sell_window.update
@status_window.update
case @stage
when :main then update_command
when :option then update_option
when :purchase then update_purchase
when :place then update_place_order
when :pickup then update_pickup_order
when :discount then update_discount
when :appraise then update_appraisal
when :sell then update_sell
when :number then update_number
end
end

def check_number
return number = case @item
when RPG::Item then $game_party.item_number(@item.id)
when RPG::Weapon then $game_party.weapon_number(@item.id)
when RPG::Armor then $game_party.armor_number(@item.id)
end
end

Have you ever tried using a mini-map script on a map that you copied from another project and it just went *KE-RASH*?

Well, I was dumbfounded.... particularly because it was MY mini-map script and I was trying to figure out what was forcing the script to go berserk. It was causing problems with the default Game_Map class's terrain_tag method. But the map itself, though jumbled in appearance, was appearing to run fine. That, and I ran traces on x/y coordinates for every tile, but found no joy. That, until I decided to check tileset of the map in the original project.

Map #81? I had no map #81 in this new project. Aaaarrrgh! Well, after creating an 81st tileset, the Mini-Map script works.

Mebby a test needs to be put in place for an error-checking and bypass feature.

Running a few compatibility checks, I discovered that my Lycan ABS does need a minor alteration. It appears that the RMXP SDK uses a method with the same name as a method within Lycan. This duplication causes an error forcing a crash. A simple fix, I just had to rename the method.

Just one more thing I have in store for the next Lycan ABS demo... when I can get to it.

Up is down, left is right and sideways is straight ahead. - Cord "Circle of Iron", 1978 (written by Bruce Lee and James Coburn... really...)

There have been a number of things that have been looked at, first being its compatability with the RMXP SDK version 2.4. It appears that its revised Sprite class created a method which didn't exist within the default Sprite class. And my Lycan ABS created s method within Sprite_Character with the same name. This resulted in an error, which was easily fixed just by changing the name of my method.

As simple as I made the 'main' processing method of the Lycan ABS's HUD script, it appears that some custom Map scripts had issue detecting whether it was disposed or not. So a minor fix was put into place.

The Paperdoll system... ah, yes... the Paperdoll system.... Not everyone uses multiple poses with their ABS, opting to use a simple 4-by-4 characterset, but still want the whole Paperdoll option. Initially, the paperdoll script required Frank's MultiPose script. But now, with some additions and modifications, it doesn't. The paperdoll script, in fact, checks for the actual existence of the Multipose's config module and the values within. And if it doesn't find any, it falls back upon tried and true default values.

Oh, DerVV... DerVV... DerVV... You found a bug in the ABS after all this time. And it was a feature you created years before! Ah, years ago, I worked with MrMo's ABS to create the 'ABS Ultimate' package. This was a package that included many features in the Lycan ABS, including treasure drops. Up until that point, MrMo's ABS didn't have them. But my work upon his system fixed that. However, when I recreated by option for treasure drops, I neglected to properly set up how items left behind were to be dropped upon the screen if the items were (a) grouped together and (b) not to be scavanged from a corpse to loot. It was something overtly simple... doh!

NOW to describe the FUN NEW ADDITIONS!

DIAGONAL ACTIONS has been redone and with a major change. If the system is set to normal four-directional actions, the player and the enemies can only use normal cartesian movement. And with that, they can only attack straight ahead and in only the four directions permitted. Up until this point, the option for Diagonal Actions only permitted the player and enemies to move in eight directions and performed a sort-of- sweep melee attack in front of themselves. The only caveat is that a player, if armed with a keyboard script that permitted 8-directions, can fire missiles in all eight directions while the enemies only four. This is no longer the case.

The new option with DIAGONAL ACTIONS now permits eight directional movement for all parties, sweeping attacks, and eight directional missile fire... even for the enemies!!! Let me tell you, I died a good number of times in Crag Canyon with those damned bushwhackers around there. Oh, I can alter things by setting individual delays in action after they CHOOSE to fire... sort of like setting which one is a faster draw of the gun. But now, things have gotten cranked up in the missile combat.

STRAFE! STRAFE! STRAFE! STRAFE! STRAFE!

Yes, you can now STRAFE with Lycan! Currently, I set the STAFE key to the SHIFT key, and my character stays locked facing one direction while it moves side to side! AND I can fire while strafing too! No more do you have to just move forward and turn to fire at a target... unless someone takes strafing out of their game.

Don't worry about having the gun kick you backwards into a wall. The same KICK system doublechecks to make sure you don't go "INTO" a wall or out the other side. Well, just as long as you don't set the STRAFE key to 'Ctrl' and are playing in Debug mode. Hehehe.. after all, debug mode lets you walk THROUGH walls. That kinda messes it up.

So do I have any more plans for the Lycan ABS? Certainly!!!

The Lycan ABS does simulate various status effects that can be applied to both the player and the enemies. However, some of the status effects have had little effect upon enemies, those dealing with enemy vision or hearing. Granted, a 'hearing' ailment has little effect for the player, so that is not likely to effect enemies. However, a feature that dims/hampers the player's screen should also affect enemy's 'Vision' options. Yeah, the BLIND_EFFECT slows enemies doewn, but doesn't affect their vision.

HASTE and SLOW... ah, fun ones in a sideview battlesystem with AT bars... so to should these be added for the ABS. In the ABS, you have a delay option called the MASH TIME. This gauges how often the player or enemy can perform an action. If I make the system HASTE this mash time, the delay should be shortened so attacks can be made more rapidly. And if SLOWED, the reverse! Optionally, a feature of similar nature should be set up for actual after-choice delays. I did mention the cowboy with the quick-draw, right?

So... any thoughts? ^_^

Up is down, left is right and sideways is straight ahead. - Cord "Circle of Iron", 1978 (written by Bruce Lee and James Coburn... really...)

(01-12-2019, 12:03 PM)Steel Beast 6Beets Wrote: On a different subject, is there a way to make a status buff permanent on a player once they have learned a skill on XP?

Are you talking about having a status bonus effect such as "Haste"? I never saw anyone make a status effect fully permanent. Well, not one that is not concealed in some way (ie ... vampirism or something ^_^). It need not require a script either. Performing a test, I just took DAZZLE, and knocked off anything that made the state vanish: Unchecked the 'Release at the end of battle' , set 'after X turns' to 0, and set both chance to release values to 0%. Other than making Aluxes totally weak on combat it works just fine. I used an event and made him already "Dazzled" before he enters battle, and he emerges still Dazzled after.

At last I can reply.

Well, that's indeed what I'm trying to do. Thing is, those status would be granted by learning passive skills. I got the idea after playing Final Fantasy Brave Exvius. For example there's this character I got, Ravus, who gained a skill called "Magitek Arm" that boots attack by 30%, defense by 20% and fire resistance by 10%.

I did manage to come across a way to do this via common events for skills that power up elemental damage. Of course, that's possible only in battle. What I'm looking for is a way to make status that increment stats permanently, like the example above, once the character learns a certain skill.

Quote:NOW to describe the FUN NEW ADDITIONS!

DIAGONAL ACTIONS has been redone and with a major change. If the system is set to normal four-directional actions, the player and the enemies can only use normal cartesian movement. And with that, they can only attack straight ahead and in only the four directions permitted. Up until this point, the option for Diagonal Actions only permitted the player and enemies to move in eight directions and performed a sort-of- sweep melee attack in front of themselves. The only caveat is that a player, if armed with a keyboard script that permitted 8-directions, can fire missiles in all eight directions while the enemies only four. This is no longer the case.

The new option with DIAGONAL ACTIONS now permits eight directional movement for all parties, sweeping attacks, and eight directional missile fire... even for the enemies!!! Let me tell you, I died a good number of times in Crag Canyon with those damned bushwhackers around there. Oh, I can alter things by setting individual delays in action after they CHOOSE to fire... sort of like setting which one is a faster draw of the gun. But now, things have gotten cranked up in the missile combat.

Would the system require that the attack animations also be in 8 directions or can be done with animations in the standard 4 directions?

If you are talking about RPGMaker's 'Battle Animations' that get played within the Default Battlesystem and can be used within Lycan, those never changed direction. The 'HIT' animation, if used when a target is struck, never rotated of flipped regardless of the target's facing direction. So changing to an 8-directional/diagonal attack doesn't look any different than when performed with a cartesian 4-directional attack.

To be fair, the hero had an unfair advantage over the enemies when missile combat was involved... enemies unable to attack diagonally while the player could... The 2nd story demo definitely pointed that out. Jame was able to attack and hit with 8-directional precision with same said battle animations while the cowboys were stuck attacking in just 4. Erm, the next time I update Lycan, this will change. Hehehe...

Did I mention I died over and over because the cowboys were crack shots?

Up is down, left is right and sideways is straight ahead. - Cord "Circle of Iron", 1978 (written by Bruce Lee and James Coburn... really...)