I just think that missing features should not be mixed with bugs - there are other threads for them.
We haven’t yet decided if we should use sourceforge tracker or the one from Trac tool. Please report bugs and missing features on this forum until we decide which one is better.
functional bug/feature-after launching vcmi and selcting single player game->begin
it will won’t run without internet connection (i just blocked it once with firewall without selecting “remember setting” and it keeps trying to connect but here a little weird thing my firewall doesn’t ask me for it every time but when i relaunch application it asks. i’m writing it just in case :P) and then when i close console (because i can’t do in main window anything from that point)
it gives error i40.tinypic.com/211rw1u.png
also i noticed when moving hero sometimes animation is lagged it slows down somehow i don’t remember such behavior in earlier versions … it seems to be easiest way to catch it is 3-4 square moving and point with mouse at hero
also here a feature(or bug :P) you can’t stop a hero while he’s moving
I’ve finished checking the status of all bugs reported in this thread. Many of them are fixed, a couple logged in SourceForge and one reported in the 0.72c thread (Spacebar @ Subterranean Gate - I think it was fixed but came back). There is another issue regarding the interaction with firewalls, which never received a log, and I’ll address it in a separate post below. But first I wanted to add a few comments on #24 & 29 (intentionally left unchanged, and I agree with the devs on this):
[quote=“Steven Aus”]
#24 - I don’t know why it was coded as such in H3, but it was an annoying “feature”. Imagine having to choose between Eagle Eye & Navigation on a map with no water in one of the first days on an XL map (with no way to escape it). It will be a very frustrating getting yourself stuck with a useless skill for the rest of the scenario (or even campaign). I know that if you think of the H3 AI, it would be unfair to give ourselves the chance to “duck” useless skills. But instead of making things uglier for us, why shouldn’t we make things nicer for the AI? I don’t know what the devs think about this, but maybe it could be coded as such that the chances for the Computer Player to get one of these “bad” skills to be reduced considerably. So on this I keep my vote of leaving things as they are in VCMI, and only if there are enough voices asking otherwise, to make it an option otherwise.
#29 - This one is less important. For #24 it was a big deal to have the skill following you around for hours and days, until you finish the map, so it was worth it to try a reload for a different skill, so that I can enjoy the game better. But I would never bother reloading for resources. And I wonder who would? But okay, just in case someone would be interesting, it can be implemented as an option as well - if it will (as I’m not sure the coding effort is worth it - definitely not at this stage of the game I think).
I’m not sure if this is really a bug, but as it was never answered, I though of bringing it up. And because it wasn’t given any log number, let’s give it 0.7b**#35**.
I’m not sure what firewall amvmichael is using, but I have the same issue with my ZoneAlarm. And it’s only because of blocking the internet activity from the firewall. Simply unplugging the UTP cable does not affect VCMI. However if I stop internet activity from ZoneAlarm, the game does not even load as far as the Main Menu, and the Console goes in a loop every 2 seconds with the following lines:
Sounds like ZoneAlarm is a bit overzealous when blocking all internet acivity. The VCMI server and client communicate with each other over the network (even though it’s all happening locally on your machine, it’s still a network connection). If ZoneAlarm interprets your command to block the internet as shutting down all network activity, then it will block this local network connection too, and VCMI client and server won’t be able to communicate with each other. That would also explain why physically disconnecting the remote network (by unplugging the cable) doesn’t affect VCMI, it only needs the local (machine-internal) network connection.
I vaguely remember similar problems with ZoneAlarm some years ago, but I can’t remember with which project they appeared. Personally I never used ZoneAlarm because at least at that time it didn’t allow users to fine-tune the connection rules. The program may have evolved by now, check whether you can declare “trusted applications” which can use the network protocol on the local machine even if ZoneAlarm shuts down all connections to and from other computers.
In any case, if the problem is caused by an overzelous firewall shutting down the localhost, then there’s little that the VCMI programmers can do, since the architecture of VCMI relies on network ommunication between server and client. It probably should be mentioned in an (eventual) FAQ though, since many people will run into the same problem, and it’s not evident for everyone that a game that they only play on their local machine still uses network technology.
(And sorry if I’m only telling you things you already know. )
Yeah it’s zonealarm Still its kind of weird of course i can give it a remember to allow it all the time but blocking it just once while it doesn’t respond to next … maybe it remembers it until closing down program huh:P
Whats interesting now it doesn’t even ask with 0.7c version.
I didn’t know the more technical parts, so thanks!
I was pretty sure it’s not a VCMI bug, but I didn’t know how the VCMI client and server communicate with each other, in order to identify the reason why stopping the internet activity from ZA would cause the problem in VCMI.
But even though it’s not a VCMI bug, there are still things that can be done maybe:
Better handling of the situation:
a) Now the console goes in an endless loop trying to establish the connection. Perhaps at some point (after 5 or 10 attempts) it should ask the user if it should continue or terminate the application
b) or give the possibility to close the Client without an error (as it is now)
c) and/or give the possibility to close the Console without an error (as it is now - though in case of closing the console i/o the client, perhaps that error is normal)
Or if no enhancement is worth the coding effort, then at least - as suggested by Psyringe as well - we could include this in a future FAQ.