[Archived] I want to help

@spell scrolls
I think its best to make spellscrolls make new type of herobonus tempspell and spellID willl be subtype of bonus

or is it indifrientable now which scroll contains which spell?

also maybe add to CArtifact a field
vector BindHBonuses
which will be handled as adding those bonuses to hero when equip?

then it will be able not only to check type of spellscroll, but also thee will be a possibility to enchant artifact which may be good subject of future mods

It seems inevitable that there needs to be a new class representing artifact instances which can hold these parameters. Will be a lot of work migrating from using CArtifact to that, though. :frowning:

@majaczek: The problem is that the CArtifact class represents the different artifact types, not each individual artifact you might encounter in the game. If you were to change bonuses of a CArtifact you would change bonuses for all artifacts of that type.

So do class CScroll which derives from CArtifact :unamused:

OR maybe create class which have function I though - class of individual artifact with CArtifact as friendā€¦ so things like Spell scrolls will be resolved also my thought of enchanting etc.

Thereā€™s also a third error on line 52, which is some sort of circular dependency that gcc cannot figure out how to deal with (and neither can I).

Connection.h: In instantiation of 'CPointerLoader<CISer<CConnection>, CGTownInstance>': 
Connection.h:482:   instantiated from 'void CISer<Serializer>::registerType(const T*) [with T = CGHeroInstance, Serializer = CConnection]'
../lib/RegisterTypes.cpp:23:   instantiated from 'void registerTypes1(Serializer&) [with Serializer = CISer<CConnection>]'
../lib/RegisterTypes.cpp:158:   instantiated from 'void registerTypes(Serializer&) [with Serializer = CISer<CConnection>]'
Connection.cpp:52:   instantiated from here
Connection.h:437: warning: 'class CPointerLoader<CISer<CConnection>, CGHeroInstance>' has virtual functions but non-virtual destructor

which keeps repeating until gcc throws in the towel.

Deriving CArtifact wonā€™t really change anything. If you stick to just using CArtifact youā€™ll end up with a solution where you assign new artifact IDs to each spell, giving lots of different spell scroll artifacts.

@deriving
understood. of course if CArtifact is assigned via artifact ID it wont change anything :unamused: I feel like silly boy

@scrolls
I vote for Class which represent artifact instances! so instead having ID only we will be having this class. the most important field of this class will be artifact ID (so acces to CArtifact isnā€™t broken) and a few more fields like
vector UniqueArtHeroBonuses;
which will be applied if that instance of artifact will be worn and disapplied if it will be worn out. so we will make only one CArtifact for scrolls like now, we will have difffrient scrolls, and we will be able to enchant artifacts (add bonuses to one instance keeping rest the same) for a mod

The code you pasted is not about an error but about a warning.
But actually G CC is right. CBasicPointerLoader / *Saver should receive virtual destructors. And be deleted. There was a possible leak.
Fixed in r1411.
Are there any further issues with code on G CC?

PS. Mysterious g cc issue hit again :confused:

Looks like I was wrong, I thought I fixed the errors and then it still wouldnā€™t compile. It compiles now (r1412), but the compile time is a bit extreme. gcc didnā€™t get stuck as I thought, it just took literally 3 minutes to compile CGameState.cpp. I suppose itā€™s a pathological template case. Hereā€™s a slew of warning output for these files, lots of non-virtual destructor complaints.
All in all it takes about half an hour to compile VCMI from scratch with gcc :open_mouth:, but I guess thatā€™s to be expected with C++.

I also still get the gcc posting issue, but I use a zero-width workaround by typing

g****cc

It is not, I think it must be some issue with gcc.
With MSVC it takes 10-12 secs to compile CGameState.cpp in debug mode or 7 secs in release mode. Rebuild solution in debug mode takes one minute. I have Intel i7 860 CPU which surely helps a lot but even on slow CPUs single file absolutely shouldnā€™t take 3 minutes!

Should be better now. (r1415)

Tricky! :wink:

Maybe this could be the answer for this problem (a part of GCC 4.5 changelog gcc.gnu.org/gcc-4.5/changes.html ):

CGameState.cpp instantiates a lot of templatesā€¦ but then this issue should have been noticed long time ago (or nobody cared about compilation time?)

Hello everybody, Iā€™m new on this forums. Yesterday I tried compiling the VCMI source code like itā€™s written here, but it didnā€™t compile.
The first problem I enountered was that a file named CMapInfo.h was missing (CGameState.cpp was trying to include it).
I was using windows XP SP3 and Visual C++ 2010 Express edition, I included the boost libraries afaik, and downloaded the sources with tortoisesvn (else I couldnā€™t have compiled:) )
I hope someone can help.
Thanks,
Ozsy

ps.: I tried to register yesterday, but the CAPTCHA is not showing up.

Jezusā€¦
[forum.vcmi.eu/t/cant-register/335/4)

As to missing files, solutions may be outdated. Just add/ remove files to projects, following recent revision and compilation errors. With MSV it should be relatively easy.
I canā€™t see CMapInfo in repository anymore, possibly it was removed / renamed.

Thanks for the link, but I managed to find the post a bit after my last message.

So, after several hours of trying, I managed to compile and link VCMI_lib and genius, but not the client and server. I had to change back to revision 1817, because in revisions 1818 and 1819 CMapInfo.h is included in CGameState.cpp, which I still donā€™t have.

There was a problem with my boost install, but managed to solve it (the multithread debugger version was requied of the libraries).

Iā€™ll try to compile revision 1817, then change to newer versions.

I lied, CMapInfo is indeed missing. I was not able to find such a file in repository at all, so it must have been added recently.

What a messā€¦

Iā€™ve uploaded missing files, sorry for trouble.

Thanks, both of you itā€™s almost working now! I managed to compile all 4 projects (revision 1822), and link each except for the client. As far as I can tell, it misses the files of CMapHandler.
I managed to start the server, so I think itā€™s the only thing left before I can ask: ā€œHow can I help?ā€

Edit:
I managed to find it, itā€™s just called maphandler.cpp, the client is built succesfully.

Edit2:
The client is working, I managed to run 2 instances and start up a MP lobby :slight_smile:

So, how can I help?

Just have a look
wiki.vcmi.eu/index.php?title=TODO_list

However, itā€™s not a good moment to add new functionalities as old code is hardly working and needs fixes, though no one has time for that.

@Ozsy

You can always take an older, stable revision and improve our AI. The interface does not change significantly over time so merging with trunk when itā€™s more stable will be easy.

I donā€™t recommend bugfixing for beginners as itā€™s hard, not satisfying and time-consuming.

One more question: How much work should be done before updating the repository? I made some changes in BattleHelper (and a bit in BattleLogic).

Actually we donā€™t have precise guidelines but:

  1. the code in repository should always compile, especially trunk
  2. donā€™t commit more than 2 times a day if you donā€™t think it really necessary
  3. itā€™s good when you donā€™t break features that already worked, especially just before releases (but itā€™s not obligatory in some cases)
  4. donā€™t commit unnecessary files (like Warmonger did in rev 1822); if you accidentally do, remove them once you see what happened
  5. enjoy coding!

Next question: how can I get access to upload my files?