vcmi_build.diff fixes the build system (cleanups, add missing sources and AI build)
vcmi_ai_warning.diff emits the same warning than windows when the AI is not found
vcmi_offbyone.diff fixes an off by one bug
vcmi_unsigned.diff changes the sign of a couple variables. It’s just a sample because the code is full of the same. Sometimes it’s a bug, sometimes it doesn’t matter. vcmi_linux_patches.zip (3.69 KB)
Another set to fix a crash, add the empty AI, fix some warning and avoid an infinite busy loop in the main client event loop.
As a related note, it seems to me that there is quite a few object variables that are not initialized. That was causing at least one of the crash I saw. However it’s hard to quickly tell which ones need to be initialized and which ones can be omitted. vcmi_linux_patches2.zip (2.57 KB)
Patches from first three posts has been committed by Tow Dragon in r794 (first two packages) and r795 (third package).
Thanks again for patches! I can add you to the Authors list, if you give me your name
If you want I can give you also a direct write repository access (I need you login at sourceforge).
Committed with r800.
Why? Initialization order is same as declaration order anyway, so effectively it doesn’t change anything. If you really want both orders to be the same, I’d rather change the order in the initialization lists. Firstly, you won’t change any behaviour (in case if initialization order actually does difference - unlikely but…), secondly member declarations are often grouped in the logic blocks (“subtype” looks better next to “type” than “description”).
My contribution so far is a bit short that I’d be considered an author. Beside c++ gives me headaches, so I can’t do much coding. I’m interrested in making vcmi work well on linux so I can play those huge adventure maps that keep crashing my heroes copy
If variable declaration and constructor initialization orders don’t match, then g cc complains. It’s usually harmless, but sometimes it’s not. That’s about 1/3 of the warnings I get and I’d like to clear them. But you’re right, it’s better to change the init order and not touch the declarations.
And do you know why this board is crashing whenever I write “g c c” with no space ?
Edit: attached new patch to fix the remaining initialization order issues. vcmi_linux_patches4.zip (3.09 KB)
Here’s a re-implementation of CMessage::breakText and CMessage::drawText. They’re more correct and robust than the existing ones.
And there’s a one line fix to display the ressources on two lines in a dialog message when there’s too many (>5) of them. The output still needs some adjustment, but it’s better than the current code. vcmi_patches1.zip (2.76 KB)
It needs to support blank lines which were quite often used in various dialogs (eg. if dialog has a title, it’s followed by a blank line).
Code should follow the convention used in VCMI. Each brace ‘{’ should have its own line, variable names uses camelCase (not underscore_separated_names, except for macros, enums and some global vars - but they’re also capitalized then).
I’ve committed fixes for both issues.
I’ve used trim_if(text,boost::algorithm::is_any_of(" ")) because we don’t want LF signs to be removed (one may want to use following or trailing LFs to adjust text position). Other changes are obvious (I hope).*
That is not enough. Function won’t enter neither elseif nor else block since it’ll enter first if if(z) ]. “some … words” will be pushed as the first line then \n will be removed (user break line) which will end the function.
Fixing this isn’t probably effort-worthy, trailing/following black lines AFAIK are not used anywhere.