H3 vcmi

Object IDs is very risky topic in general, as we didn’t decide any way of describing new possible objects. It probably will have to be smarter than just fixed list of IDs.

But dynamic lists and configurability is the way to go. Just leave some back door to implement mods later and focus on generating maps :wink:

I am not sure what I should get my hands on? Is there anything importing I could try?
Even though I have few years of experience in c++ and even more years with H3 WOG, I am a beginner in this project. Can anybody guide me?

I’m not sure if important things should be done by newcomers… I think you could start with implementing Hall of Fame window. You can pattern after other windows from CPreGame.cpp. You have to extract .lod files using resedit, look for appropriate .defs / bitmaps and put them together.

How about battle abilities? Some of them looks simple, but are still missing.

Apart from that, there are more interface windows missing, check Wiki or Mantis.

To implement a pregame window you just need to know how to make windows in our GUI system. Implementation of creature abilities requires knowledge on in-game GUI, client-server interactions, bonus system, and preferred style of architecture. Many remaining creature abilities require taking care of interference with other abilities. I wouldn’t like to leave it to people new to the project.

BTW, some hero specialties are broken for some time because you wrote them in CStack::stackEffectToFeature which is not supposed to handle that. If you don’t understand our architecture I don’t expect that others do.

I am not sure what you mean by that? You mean the window triggered by the “High Score” menu entry, right at the start?

Sure I can take a look at that. I have just created an account on MantisBT. Are there any bugs posted regarding this? Or is there a certain filter I can apply to search easier for these kind of bugs?
My previous programmer experience is mostly related to GUI. So any issues related to GUI might be easier for me to approach.

I am not the type of programmer that jumps right in the heart of the issues without a good knowledge of the architecture/framework. So I am guessing something easy, that is not connected too much with the rest, should be good enough for me at the beginning. I’m easy! :wink:

Yes, I mean high score lists.

If you really want to handle battle-related bugs I would suggest to start with easier ones, not related to mechanics. You can filter them out by selecting those assigned to me and with resolution ‘open’. I think you could start with solving these bugs:

bugs.vcmi.eu/view.php?id=64
bugs.vcmi.eu/view.php?id=37
bugs.vcmi.eu/view.php?id=27
bugs.vcmi.eu/view.php?id=69
bugs.vcmi.eu/view.php?id=48

Our GUI system is a bit specific but I hope you’ll get used to it.

I’m glad to hear it :).

I took a look on these bugs. 64 and 27 seem to be related. I would start with these ones (I will first try to reproduce it). Any idea on where to debug it?
Also 69 and 48 seem to be related, but I would leave these after.

You’ll probably need to change CBattleInterface::mouseMoved.

Indeed, I have found where the issue is by debugging it and I have fixed the bug 64. Now, how do I proceed next? I mean, I have to assign bugs.vcmi.eu/view.php?id=64 to me, than submit my code, than assign the bug for review? What is the proper flow for fixing a bug?

Hi ungureanuli,

I’ve assigned #64 to you on Mantis. Once you commit your changes, you can change the status to Resolved and when doing so you will get the chance to add a note. There you can say something like “Fixed in r20xx” and any other comments you may want to add.

#64 seems related to #27, though the latter was never very clear to me what was it referring to (seems to me more like a duplicate of #48 actually; but again, I could be wrong)

If you fixed the bug, you should make a patch using your SVN client and send it to me. I’ll review it and either upload it directly to SVN, make a few corrections or ask you to fix something. When I accept one bigger or a few smaller patches from you, I’ll give you write access to our repository and developer status on mantis. Then you will be able to fix bugs on your own - Zamolxis explained how to do that. BTW, When you fix more complicated bug, you may want to assign it to yourself before fixing it.

I have attached the patch file to this comment. I have created the function playOneAnimation that was extracted from the old place and it’s called from two places (inside a big and nasty if/else).
I have noticed that the creatures from the enemy are also not animated (in H3 WOG they are). Should I also add these to be animated?

I can reproduce #27 : just move fast enough the cursor inside or inside-outside-inside the hexagon of a friendly creature. In WOG it seems to be happening only once, when you’re inside of the hexagon but it is also reproducing for the inside-outside-inside movement, meaning the animation is started again even though the previous animation did not finished. So I am thinking either to detect when the animation has been finished and only then to eventually let another animation to be triggered or to insert a minimum time frame between two successive animation.
What do you think is the best solution?
AnimationFix_Bug64.zip (997 Bytes)

This function seems to be a good idea but I think name ‘playOneAnimation’ doesn’t fit it. I think you should change it’s name to f.e. playMouseonAnimation (since it cannot play other animations). It would also be better if you prepare a bigger patch before it’s committed.

The first options would be easier but I’m not sure that’s exactly what we have in Heroes III. If we don’t need minimum time frame between animarions I would suggest taking the easier way.

Well, intuitive naming was always my strong point… :laughing: nott

By a bigger patch I suppose you mean to also include fixes for other bugs in only one patch?

I am investigating to see if I can get both solutions working and then I will pick the one that resembles more with H3 behavior. But anyway, I should find at least a solution to solve the annoying repeating animation.

Yes, I think the patch should have at least 10 - 15 kB. You can fix in it a few bugs.

I have fixed 64 and 27.
I will continue with 69 and 48.

I am attaching the patch for fixing #64 and #27.
#48 was fixed - I cannot reproduce it anymore.
#69 is valid. The issue is that the pulsing glowing (selecting or hovering a stack in the battle) is starting from a transparent color (and it continues to a visible yellow/blue), but it should start from a visible value (let’s say with transparency set at half). As far as I investigated I found that

aCountMod = (animCount & 0x20) ? ((animCount & 0x1e)>>1)<<4 : 0x0f - ((animCount & 0x1e)>>1)<<4;

from CCreatureAnimation::nextFrameT is responsible but is a puzzle for me what this values mean. Can somebody point me to the right direction with this bug?
I have also started to work on #37
Fix_64_27.zip (1.72 KB)

A few comments about your patch:

  1. the name of the new argument of playMouseHoveredAnimation (isHovered) should sound setAsHovered (since that’s what actually this it does),
  2. I think you should use struct instead of pair as type of lastMouseHoveredStackAnimation. Furthermore, storing CStacks as IDs is deprecated (you should use pointers to CStack instead).

Besides these two minor issues your code looks well :).

Actually CCreatureAnimation is an old, ugly code that should be replaced by Ivan’s CCreatureAnim. I think you should leave #69 for now.