Page 26 of 47
PostPosted: 28 Jun 2010, 16:58
by Krom
Try latest r861. Which error do you have?
PostPosted: 29 Jun 2010, 07:33
by dontmailme
With 860 and now 862 I get this:-
- Code:
KM_ResourceGFX.pas(1214,83) Error: Wrong number of parameters specified for call to "Max"
Common\KromUtils.pas(108,10) Hint: Found declaration: Max(const LongInt,const LongInt,const LongInt):LongInt;
Common\KromUtils.pas(113,10) Hint: Found declaration: Max(const Single,const Single,const Single):Single;
KM_ResourceGFX.pas(1215,83) Error: Wrong number of parameters specified for call to "Max"
Common\KromUtils.pas(108,10) Hint: Found declaration: Max(const LongInt,const LongInt,const LongInt):LongInt;
Common\KromUtils.pas(113,10) Hint: Found declaration: Max(const Single,const Single,const Single):Single;
KM_ResourceGFX.pas(1234) Fatal: There were 2 errors compiling module, stopping
[/quote]
PostPosted: 29 Jun 2010, 08:03
by Krom
You can fix this by putting Math.Max instead. Then it will be fine. Lazarus can't choose better function to call, unlike Delphi.
PostPosted: 29 Jun 2010, 09:19
by dontmailme
I did realise that but still can't see what changed from 857 to make this happen... but I don't know the code like you do
ok, now I got a crash... at the compressed tga handler again..... and found it was down to the MakeTerrainAnim flag being set, the anim tga's are compressed. Although the error isn't on the load line now, it's moved further to line 189 in KM_TGAtexture.pas
- Code:
i := uncompress(@TGAHeader, DestSize, Comp, InStream.Size);[/quote]
For the moment I just set the anim to FALSE and it seems to run ok now :)
If you have any uncompressed anim textures, or have a converter from compressed to uncompressed, I'd love a link :) I have searched and not found anything.
PostPosted: 29 Jun 2010, 10:02
by Krom
I have used custom zlib compression. See r863, it has uncompressed textures in a zip archive.
PostPosted: 29 Jun 2010, 12:00
by dontmailme
That seems to work good
Is saving / loading supposed to be working? I can't load anything I saved with latest version, but apart from that it all looks good now
PostPosted: 29 Jun 2010, 12:28
by Krom
Saves format is constantly changing since we add new features. E.g. at the moment I'm working on Projectiles and they will need to be included into saves format as well. Projectiles saves section is subject of changing too - it might need optimizations and new fields to support various types of ammo.
PostPosted: 29 Jun 2010, 12:39
by dontmailme
ok, so saves are probably very fragile
But I'll give the info anyway as might be a bug.
Loading fails in KM_Units @ line 2356
- Code:
else fLog.AssertToLog(false, 'Unknown unit type in Savegame')Â [/quote]
and unit type = UT_NONE - So say the debugger.
PostPosted: 29 Jun 2010, 12:45
by Krom
Thats not a bug. This happens because somewhere else new data was added and binary stream in a file doesn't matches it any more. Hence unit type read from file brings garbage or ut_None.
Thats why we have SAVE_VERSION string written in any save. If it doesn't matches - show a message and don't load anything. We didn't care updating it to current r863 for 2 reasons:
1. we update it only for public release
2. savegame format is always changing, so it's worth assuming that it is working well only in currently running build.
PostPosted: 30 Jun 2010, 09:46
by Krom
While checking savegames functionality before new demo release I've had the same error. That happened to be a bug after all - I forgot to move Recruit to a new class
Thanks for report, bug fixed in r864
PostPosted: 23 Jul 2010, 07:04
by Krom
I'm bugfixing KaM Remake fighting demo currently. There are still few nasty bugs remaining in unit interaction during fights.
For the last few weeks I've been trying to remake army interaction code written by Lewin, but it came too complicated and ill-written, so I've returned to Lewin's old code and it appeared quite better now )
So now I'm replaying TSK6 fight all over again and fixing number of bugs happening there.This is one more advantage of pseudo-random number generation - each time random numbers are the same, meaning that each time the battle (without player input) is exactly the same.
PostPosted: 23 Jul 2010, 10:11
by Sebrav
Sounds REALLY good:D
I hope i can try that mission soon in the remake
I tried to beat my enemy in one of those single missions,
but after some time, i got this:
http://img291.imageshack.us/img291/1988/kamremakebug2.png
and the other thing, is that the bowmen didn't attack.
I know this is from the Economy demo BUT, i think you should know that the game crashed.
After that, i think you should know that the AI didn't even build an Inn.
The serfs starved to death. See:
http://img806.imageshack.us/img806/7808/kamremakebug.png
So, hope that helps.
Sincerely, Sebrav
PostPosted: 23 Jul 2010, 13:58
by Krom
Two more nsaty bugs are fixed in TSK6 fight and now it's bugfree )))
Also I've improved house attacks, now units properly walk away if ordered.
@Sebrav: We didn't implemented archers attack yet. As for the bugs you've noted - there's a lot changed in interaction code by now and I'm hoping these bugs you saw are fixed too.
AI building isn't implemented either.
PostPosted: 23 Jul 2010, 14:49
by Sebrav
Sounds like you have made good progress
Keep it up
So when can i expect it released? ( Hope this won't get you pressure )
And when will those archers attack? ( I could imagine how difficult it would be to program it ) Simple answer = hard.
Sebrav
PostPosted: 26 Jul 2010, 13:30
by Krom
I plan to make a release in a week or two, as usually
Honestly, I don't know when, but I need to have that feeling "I'm confident that there are no major bugs and we can show this to public".
Archers attack may be postponed, it's not that important for upcoming demo. There are bigger issues with fights that I want to resolve first.
Also before release I want to implement a game recording feature, so that bugreports were 100% re-viewable. I've been working on it and it does works already, but needs some cleanup and bugtesting itself
The feature works like so: It creates a ground-zero savegame right on game start and then logs all player commands (well, not all yet) and time these commands were issued. Then on replay this module issues all the commands at precise times and thus the game is exactly the same as it was. Thus, having ground-zero savegame and commands log - all bugs become re-producible for bugfixing.
Same idea can be used in multi-player, but thats later...
