Frogames

@ Kirb

>> Which damage dealer settings are you talking about?

I'm talking about the prefab. I think you can reproduce the bug using this process:
- In ability damage dealer settings, add prefab and choose a particle emitter.
- In the BattleEvent of the Animation Settings, deactivate Auto Damage Dealer in the Event Settings and use the Activate Damage Dealer event step.

Animation and damage are working fine, but the particle emitter is not spawned.

gamingislove

@Kirb
I guess you're not using single screen?
I'll look into it - would also help having your ORK project file :)

@Frogames
The Activate Damage Dealer only uses the tags of the item/ability (if you've enabled Use Action Tags) - the prefab/audio settings of the ability aren't used here, they're only for the auto activation (currently). Seems like we need an option for that :)
The environmental damage dealers aren't activated through abilities or whatever, that's the whole point of them - they also don't use the ability's damage dealer settings, so no audio/prefab from there ... guess that goes also on my to-do list :)

Frogames

Great :)

Kirb

@GiL
Yep! No single screen on any of those menus, since they're all overlapping each other. I'll toss you the project file right now.

Juryiel

Hey GiL,

I had time to play with it today. It looks like the problem was that the Move AI was not running at all, the combatant was only moving to me because he was trying to perform the attack. This is because I was using a Raycast for the Move AI detection, which I forgot was broken. I disabled it for now and added the None block to the battle AI and the hunting conditions do in fact work :)

JellyPaladin

I've noticed that equipment requirements that check status values don't account for bonuses from the combatant or the combatant's class. e.g. If I have a status value with a starting value of 1, then, even if the combatant has a bonus of 5 and the combatant's class has a bonus of 5, I still can't equip an armor with a requirement of 3+.

I've thought about it and I guess this could be intentional, but I'm not clear what the advantages would be... combatant-specific bonuses are about as permanent as anything.


Edit: If it is intentional, feel free to leave it the way it is. =) Finding this out helped me realize that I could set up my own status values in a slightly different and better way, so it's nothing I need fixed for myself. Just mentioning it in case it's not on purpose.

gamingislove

@JellyPaladin
After doing some tests, I can't confirm that one - the requirements are the same as everywhere else when it comes to status requirements, and that's including bonuses :)

LordHogFred

So I've been having some issues with combatants in Real Time moving towards a position and then circling around their target.

I've taken a look in the source and I think that there are some problems with the stopTime and stopDistance. The combatant reaches their position and stops for one Update cycle and then continues to try and reach the target. I've tried a few things but can't seem to solve the problem.

I also noticed that stopDistance doesn't take combatant BoxRadius into account if the target position is that of a combatant. I added a check to see if tcIgnComRad is false and if so subtracts the BoxRadius of both the source combatant and target combatant.

Hopefully I've provided enough information to help identify the issue. If anyone could offer any advice while GiL is on holiday that would be great.

EDIT: While I think there is still an issue related to what I described above, disabling smooth movement on the SimpleMove component appears to fix the circling around a target position. I fixed this by added a check in the source to not use smooth movement if the combatant is too close to their target position. This doesn't take BoxRadius into account (as that information isn't in scope by the time SimpleMove is being used) but if the above issues are tweaked then it shouldn't need to.

Cheers :)

Ntelliware

Minor bug found. It was my own stupidity that found it, but if you get too lazy to click the "More" then "Special" then "Wait" buttons while entering dialogues and just type #wait1# instead, if you mistype it and enter #wait1$, then when you play through the event will completely lock up Unity when it gets to that step.

Also, when having multiple boxes in a menu (one for a button list, one for equipment, one for inventory), if you want to select a button from any box other than the last one created in the Menu Screens section, you have to click the box once to set it active, then click the button (double clicking the button works as well naturally). And yes they are all on the same GUILayer.

Kirb

Heya GiL,

Found an issue with Status Effect prefabs.

If a Status Effect is auto-removed, it ignores the 'Spawn Prefab' Destroy settings.

For example, if I have a status effect with a glowy fire effect, and it only lasts 5 seconds, the particles stop emitting and it is destroyed gracefully. However, if auto-remove is invoked, the fire effect just blinks out of existence, which doesn't look too good.

JellyPaladin

@gamingislove [when back from your vacation =) ]

I've been doing some more testing with the equipment requirement thing I brought up before and here's what I've come up with. The requirements themselves are perfectly fine, like you thought, but if all of these things are true:

1) a combatant has starting equipment
2) that equipment has equip requirements and auto unequip turned on
3) the combatant only meets the equip requirements with class/combatant bonuses factored in

Then the combatant won't spawn wearing the starting equipment... and it won't be in the inventory. That's what was throwing me off; I believed the starting equipment was there and I just couldn't see it because I didn't meet the requirements. But no, it actually stops existing.

I'm guessing all that's needed is that, as a combatant spawns, status value bonuses should go into effect before starting equipment is added.

RunawayDev

I've ran across some issues I thought I would post, just in case they're bugs and not me misunderstanding something.

- In animations when using set horizontal speed under the mecanim settings it bases the
speed off what direction the character is facing, not what direction he's moving in.
Either that or it's based off world position, since I've noticed if I keep running forward
my speed variable will randomly flip from positive to negative. Say for example I'm using a
first person camera, and I'm pressing up to move forward. If I turn the character around
using the camera, my speed variable gets set to negative, playing the walk backwards
animation even though I'm still pressing the forward key. It needs to set the
horizontal/vertical speed based off what key is being pressed.

-Raycast settings: If there is no enemy in view the skill activates above the user. If
ignore user is turned off the skill activates on the user. Ray origin screen is buggy, uses
skill on the closest enemy, not the one in the center of the screen (I suspect it's using AI
settings for targeting). There is no difference if I use the mouse/touch control settings.
But as an aside if I was going to use the mouse control settings I need it to use keys
from the input manager or input keys instead of hard coded mouse clicks. Using hard
coded mouse clicks gave me some issues with my last game and additionally will get in the
way of players being able to customize their controls or use gamepads.
Also using the user as the ray origin works , except that I cant target an enemy above or below the player. These are pretty big issues and basically make the raycast settings unusable.

Also a few questions:

-What does change collider under damage dealer settings do?

-What does the add ability option under the damage settings in the damage dealer do?

Sorry if these issues have been brought up elsewear. I did a search and didn't see anything, so i thought i would go ahead and post. Thanks!

Ntelliware

Ok, another little bug. If in an event you block player controls and the player is not actually spawned (for example using the actual model for an animation sequence for a cut scene, but not actually spawning the combatant itself) the screen displays a blank GUI Box as set up in the first (default) GUI Box settings.

tanaka

Bug: In battle, a Target Cursor does not get removed from its target enemy if a different target is selected with a mouse click or touch input.

Steps to reproduce:
1) Enable Target Cursor in Battle System->Battle Settings
2) Enable Mouse/Touch Control in Battle System->Battle Settings
3) Begin a turn-based battle with more than one enemy combatant
4) Select "Attack" from battle menu (This will place a cursor over one of the enemies)
5) Mouse click or touch an enemy that does NOT have the cursor over its head
6) Player will attack the enemy you clicked/touched in step 5, but the cursor will not be removed from the enemy you didn't attack.

ORK Framework 2.0.8
Unity 4.3.4

Kirb

Found an issue with the Description in Menus.

If displaying the title, using the %n text code to display an item's name (as instructed on the GUI itself), does not work. Typing anything else will display text, but using %n to display the selected item's name will result in a blank box.

This was a description part for my equipment (armor) menu; not sure if it applies to weapons or normal items.