Roots wrote:Well considering that its been that way for some time and I know you've seen it, I guess it doesn't look so wrong does it?

Actually, I do realize now that the old battle mode was drawing damage text over characters heads. That was confusing too, and frankly looking at it again I think it looks bad, but the way it is now looks bad too.

I disagree that drawing it in the dead center of the sprite is the best option. I have been considering drawing it so that it covers the sprite partially or completely on its backside. Its really easy to tweak and figure out what you think looks best. (Go to battle_indicators.cpp line 111, function void IndicatorText::Draw() -- change the values passed in to the "MoveRelative" calls to adjust the indicator positions).

The text should cover the sprite so it's obvious what it's affecting. As a player, that's where my instinct is to look, because every other RPG does it this way or nearly this way (sometimes it may be a bit below the sprite, but never off to the side, and I don't think that would work well in our layout anyway) so if the text is off to the side or above I either miss it or I'm not 100% sure who it applied to.

Doesn't necessarily have to be in the absolute dead center, but it should be over the sprite and not next to it.

Hmm, yeah I think I agree with you there. I was actually thinking about possibly drawing the indicators from left to right instead of bottom to top and placing them over the actors. I was also thinking that maybe instead of keeping the indicators constantly in motion, which is a little...awkward, I would stop it in the middle for a brief period of time, then fade it away again. The issue with this then becomes the queueing up of multiple indicators. Its a design point that I suspect we'll be making tweaks to for a while until we get it the way I want it. For now at least, I'm going to move the indicators overhead and do the left<->right display without stopping in the middle.

gorzuate wrote:I think you said battles should be working now, but as of rev 1789, I can't attack anyone, so I'm eventually killed.

As I'm sure you know, it is very difficult to fix a problem that you can not reproduce. I have never had any problems with not being able to attack an enemy in battle so I don't know what it could be. I'm going to have to ask someone who does have this problem to fix it. Fortunately, the new battle code is much easier to read and modify than the old code ever was.

Do you ever see a message printed out from Lua (either a warning or an error, I can't remember at the moment) about ChangeSpriteAnimation being a nil value so Lua can't call it? It looks like that function is used a lot in attack.lua, so that might be my problem.

Yeah, the ChangeSpriteAnimation is a method on the BattleCharacter class. It *should* be bound in defs_modes.cpp and thus accessible to Lua. The attack fails because once Lua sees that it can't complete the function call successfully, it just aborts.

This is a semi-wild guess, but what might be happening is that Lua is trying to call that function on a pointer to a BattleActor class (IIRC, actor pointers are passed in to the script for both the user and the target). It might be a difference in implementation in Lua or Luabind that is causing the problem. In your case, Lua isn't recognizing that the BattleActor pointer is actually pointing to a BattleCharacter class and thus can look up the function call there. In my case, Lua is recognizing that the pointer is a BattleCharacter and not just a BattleActor (BattleActor is an abstract class anyway) and thus the function look-up for ChangeSpriteAnimation is successful. If I'm right about this, I don't know why it works on one system and not another. May have something to do with different Lua/Luabind versions.

Here's a fix to try. Add the ChangeSpriteAnimation function (with the same signature) to the BattleActor class. Make it virtual and leave the implementation of the function empty ({}). Then add it in defs_modes.cpp to the BattleActor class binding code. Then see if that works. I have confidence that it will.

[19:24:07] <marcavis> hey, I can attack again after applying Roots' fix viewtopic.php?f=17&t=5020&start=20[19:27:01] <rujasu> well, Roots said he was confident in it[19:27:28] <rujasu> off the top of my head, I'd guess that it might be related to the Luabind version[19:27:37] <marcavis> yep.[19:27:41] <rujasu> are you running with 0.8?[19:27:42] <marcavis> lemme see, mine is...[19:28:11] <marcavis> 0.8.1 it seems[19:28:33] <rujasu> yeah[19:28:44] <rujasu> I have 0.9[19:29:12] <rujasu> I'm guessing that Roots has 0.9 as well, since he's also on Debian[19:29:25] <rujasu> whereas Ubuntu and Mac users would still have 0.8[19:29:31] <marcavis> and you two are the only ones that can attack[19:29:36] <rujasu> bingo.[19:29:40] <marcavis> yep, ubuntu's still at 0.8.1

So I'm guessing there's a slight behavior difference here between the 0.8 and 0.9 versions. If we apply the fix you suggested, it should work fine on both versions of the library from what I understand.

Or, we could just enforce people to use the latest Luabind release. If we support older releases this problem will likely pop up more than once (not just in battle code) and I won't be able to catch these errors since they do not occur for me.

Roots wrote:Or, we could just enforce people to use the latest Luabind release. If we support older releases this problem will likely pop up more than once (not just in battle code) and I won't be able to catch these errors since they do not occur for me.

Unless this is evidence of an underlying bug in the 0.8 version of Luabind, I don't see a compelling reason to bump our dependency yet. I do think we should package the final demo release with 0.9 on all platforms, and by that point Ubuntu will have released their next stable version.

rujasu wrote:Or, we could just enforce people to use the latest Luabind release. If we support older releases this problem will likely pop up more than once (not just in battle code) and I won't be able to catch these errors since they do not occur for me.

Unless this is evidence of an underlying bug in the 0.8 version of Luabind, I don't see a compelling reason to bump our dependency yet. I do think we should package the final demo release with 0.9 on all platforms, and by that point Ubuntu will have released their next stable version.[/quote]

Well I guess that's fine, but all the people running older versions of Luabind are going to continue to be subject to these bugs and when they occur, they'll have to make the modifications to the code themselves and fix it, and also be sure to put plenty of "TEMP" comments around them so that we know to remove the hacks when we fully commit to Luabind 0.9.

----------

Anyway, I've kind of been lazy about coding the past few days but I needed a short break. I'm going to start documenting the current battle code design because what I have has reached maturity (at least for now). I've also sort of started on creating a set of dialogue classes for the common code, but its going to be more difficult to do this than I thought. And finally, I need to work on the "finish" code, which I have pretty much not touched at all. I'm going to do some improvements to the interface there as well, such as not showing the "skills learned" screen if there were no skills learned. I may do some interface drafts to get an opinion before I really get into the meat of it.

Off the top of my head, the current battle mode lacks a pause when the user selects an action, so enemies can always attack much faster than the player. Also, I was fighting a battle the other day from the map and couldn't use items. When do you expect to have this functionality back in place?

rujasu wrote:Off the top of my head, the current battle mode lacks a pause when the user selects an action, so enemies can always attack much faster than the player. Also, I was fighting a battle the other day from the map and couldn't use items. When do you expect to have this functionality back in place?

rujasu wrote:Off the top of my head, the current battle mode lacks a pause when the user selects an action, so enemies can always attack much faster than the player. Also, I was fighting a battle the other day from the map and couldn't use items. When do you expect to have this functionality back in place?

I have a new design dilemma I would like some feedback on. Right now I'm working on the BattleTimer class, which is an advanced timer that derives from SystemTimer and has an additional set of features. One of these features is the ability to apply a floating-point multiplier that can speed up or slow down the pace at which the timer updates. So for example, if we are to update the timer by 20ms but a 1.4f timer multiplier is active, we'd update the timer by 28ms instead. This feature will primarily used by status effects which change an actor's agility, though I can't predict what future uses it may have.

Now here's the problem. Lets say I'm supposed to apply a 1.5f multiplier to every update, but the system the game is running on is fast enough that every update is something like 5ms or 7ms. Well our timers only have an accuracy of 1ms, so we can't add 7.5ms or 10.5ms like this multiplier specifies. And you may say "so what, its only 0.5ms?". Well those missing half milliseconds are going to accumulate, and over the course of a typical 12 second idle wait time for an actor, that could theoretically lead to around 800ms of "lost time". Almost a full second off from where we are supposed to be.

So the solution I'm thinking of adding is one that waits for a certain amount of time to expire before applying the update. For example, it waits until 10ms has expired (across one or more loops) and it applies the multiplier to every 10ms that has passed, instead of at every single update time. Then those extra few milliseconds that were lost/gain are applied to the timer accordingly.

The problem with this approach is that it limits the granularity of the multiplier. If we specify a multiplier of "1.55", well its only going to have an effect of "1.5", since we still can't apply that extra 0.5ms (10ms * 1.55 = 15.5). We could solve this by making the update interval for the timer larger, but the larger we make the update interval, the longer it takes to apply the multiplier and thus our timer values would seem "jumpy". For example, an interval of 100ms would allow us a multiplier accuracy of 0.01 (as in, any change by this degree would be processed correctly), but for a multiplier of 1.5, we'd see a sudden 50ms jump every 100ms as the multiplier gets applied at that interval.

Right now I'm thinking we should stick with an update interval of 10ms, so multiplier effects are added at a small interval and should not be noticable to the player, and forget any desire/attempt to apply multipliers to a degree of accuracy that is greater than 0.1. What do you think? Is 10ms a good multiplier update interval to use? How about 20ms instead (giving us a multiplier accuracy of 0.05)? Or is there a completely different solution that is better and that I haven't though of yet?

After speaking with Jetryl on IRC, we agreed on a different approach. Apply the integer part of the float immediately and store the decimal remainders in an accumulator. Once the sum remainders are >= 1.0f, we apply them. Was sort of hoping to avoid additional floating point operations, but this solution should be fine.

gorzuate wrote:What is stopping the timers from having an accuracy better than 1ms?

Its a hardware limitation. Most operating systems that I'm aware of do not have timers more accurate than 1ms. I believe Windows timers have a maximum accuracy of 10ms, but I can't remember. I researched this back in like 2004 when Allacrost was first starting out so its been a while.

Also even if a particular OS had a more accurate timer available, the SDL library does not support timers more accurate than 1ms.

As for now, when a playable character has reached the point where you can choose his next action, the whole game stops and waits for the action to be selected.

I wondered whether you thought about the possibility of letting the game continue while the player is selecting the next action.

- Monsters would then not wait for the player anymore and be a little more dangerous.- The player could also wait for two or more playable characters and later maybe do combo damage, union skill use, or both possibilities?- The whole combat would be a bit more 'speedy'?