Indeed, by building locally the boost libraries with bjam (did you used any parameters?) I could find all lib files inside the /stage/lib directory (including libboost_thread-* files). The first time I had the wrong impression that the installers from boostpro.com/download are also installing the libs.
In order to leave out all issues regards the paths, I copied and built boost_1_42_0 in the same directory “c:\C++\boost_1_42_0” as it is in the set in the projects paths from vcmi.eu/vc10.7z .
However, when I am building VCMI_lib I am receiving the error:
Usually I use no parameters (I have to set the toolset to have MSVC 9.0 compile boost when both MSVC 10.0 and 9.0 are present).
boostpro installers install some of the libs but I don’t think they are worth using - if you don’t have really fast Internet connection, building is faster than downloading. And you get all the libraries by default. Furthermore, boostpro doesn’t have libraries for newer boosts.
You’ve found all the documentation except that written in source code files. That “more detailed TODO list” is actually our university project description not intended for normal developers. You can find cheat code list useful too ( wiki.vcmi.eu/index.php?title=Cheat_codes ).
object options will be configurable (as in H3 is RAND_TRN.TXT + fields for “treasure values” (treasure section of rmg.txt) that seems to be hardcoded in OH3. I`ll not try to reverse engineer it so meaning of VALUE will different, but similar to original as long as some aspects of value calculation are already could be found in Net.).
defs will be read from zobcjts.txt and/or any additional files; for each def file separate options file could be provided (so mods can be configured w/o changing options of original wog objects).
*mods will have the opportunity to have objects with identical IDs but such objects can`t be used simultaneously until another mod object identification will be implemented in VCMI. Ids will not be used internally. so it will be easy to implement another identification mechanism *
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
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.
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!
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:
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.
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?
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)
