Jester Fool
Emperor
It is based on RevDCM 2.61 which I believe includes BUG 4.2 and BULL 1.0. I do know that it doesn't compile with ximage, which would seem to indicate that it has been modified from the original BULL SDK.
-
Our friends from AlphaCentauri2.info are in need of technical assistance. If you have experience with the LAMP stack and some hours to spare, please help them out and post here.
Bug Reporting
- Thread starter alerum68
- Start date
Fimbulvetr
Emperor
nvm >_<
EmperorFool
Deity
Fixed.
EmperorFool
Deity
Fixed.
Extremely small detail:
When you mouse over an assigned specialist in the city screen it doesn't show the actual value. It does so when you mouse over a specialist you haven't assigned yet, or if you mouse over the + and - buttons.
(This also goes for the specialists in the Domestic Advisor screen when you have "Toggle Specialists" on.)
When you mouse over an assigned specialist in the city screen it doesn't show the actual value. It does so when you mouse over a specialist you haven't assigned yet, or if you mouse over the + and - buttons.
(This also goes for the specialists in the Domestic Advisor screen when you have "Toggle Specialists" on.)
Jester Fool
Emperor
I found out why the debug dll for BULL 1.2 crashes under Vista.
Looking at C:\Users\JF\Documents\My Games\Beyond the Sword\CustomAssets\Python\EntryPoints, there are only 4 files (same goes for BAT 2.3 installation) located there. Comparing BUG 4.4/BAT 2.3 to Removed BUG 4.3 (and BAT 2.2 installation) it seems that the following python files are missing from BUG 4.4...
Now the 'module not found' error is quite obvious (and explains '???' for the disassembly). Can I use the BUG 4.3 version of the missing files or do I need to download them? Thanks in advance.
Spoiler :
Spoiler :
EmperorFool
Deity
BUG 4.4 now uses the "missing" EntryPoints modules from BTS. Try copying CvAppInterface.py from your BTS Assets/Python/EntryPoints folder and see if that solves it. It should not since BTS loads files from both CustomAssets and its own Assets folders.
Jester Fool
Emperor
@EF - You are correct (I should have read the changelog first
). I am totally stumped. I still get a 'module not found' error followed by CTD. I compiled a debug version of RevDCM 2.72 (which includes code from BUG 4.3/BULL 1.1) and it runs fine. Do you have any idea why this would be the case?
@Lemon Merchant - Were you able to get the debug dll to run under Vista?
). I am totally stumped. I still get a 'module not found' error followed by CTD. I compiled a debug version of RevDCM 2.72 (which includes code from BUG 4.3/BULL 1.1) and it runs fine. Do you have any idea why this would be the case?@Lemon Merchant - Were you able to get the debug dll to run under Vista?
EmperorFool
Deity
The module that is missing must be a DLL. A missing Python module would show up as a different error (C++ exception if at all).
Jester Fool
Emperor
@EF - Correct again. It seems the real culprit was 'msvcr71d.dll is missing'. Since 'msvcprtd.lib' is used in the makefile, I originally dismissed this error. 'Msvcrtd.lib' is the import library for 'msvcr71d.dll'. From MSDN : C Run-Time Libraries (CRT) On a hunch, I changed line 51 of the makefile as follows :
I am not going to pretend I understand this, but the debug dll now works perfectly (under Vista/Visual Studio 2008). It never occurred to me that dlls are ALSO modules. Thanks for your help.
Code:
DEBUG_CFLAGS = $(CFLAGS) /MDd /D_DEBUG [B]<-- original code[/B]
DEBUG_CFLAGS = $(CFLAGS) /[COLOR="Red"]MD[/COLOR] /D_DEBUG [COLOR="red"]<-- change in red[/COLOR]Fimbulvetr
Emperor
What about adding those missing libaries to your system32 or whatever the folder is in Vista? The small d in /MDd stands for "debug" so what you have right now isn't a real debug dll.
Here is msvcr71d.dll, msvcr71d.pdb and msvcprtd.lib.
Here is msvcr71d.dll, msvcr71d.pdb and msvcprtd.lib.
I've merged RevDCM 2.721 and CCV last night and found a bug that seems to be caused by BUG/BULL/BUFFY. But I don't know because I never saw BUG as standalone. So the problem may be obsolete, known or even not existing in BUG as standalone.
The problem: The XP calculation called in the SDK
will return wrong values. So the first XP level is 3 instead of 2 as we got it in standard BTS. Didn't check other levels. I fear it is the same if only using BUG and not RevDCM.
And I got also an idea of the problem and a solution. The problem may be the use of long and the returned int from Python. The returned int doesn't seem to be a real int. And so the problem with
is caused.
But if you return int(iExperienceNeeded) instead of iExperienceNeeded from CvGameUtils.py everything is fine!
In CCV it looks now like this:
Yours Thomas
The problem: The XP calculation called in the SDK
PHP:
int CvUnit::experienceNeeded() const
{
// BUG - Unit Experience - start
return calculateExperience(getLevel(), getOwnerINLINE());
// BUG - Unit Experience - end
}will return wrong values. So the first XP level is 3 instead of 2 as we got it in standard BTS. Didn't check other levels. I fear it is the same if only using BUG and not RevDCM.
And I got also an idea of the problem and a solution. The problem may be the use of long and the returned int from Python. The returned int doesn't seem to be a real int. And so the problem with
PHP:
int calculateExperience(int iLevel, PlayerTypes ePlayer)
{
FAssertMsg(ePlayer != NO_PLAYER, "ePlayer must be a valid player");
FAssertMsg(iLevel > 0, "iLevel must be greater than zero");
long lExperienceNeeded = 0;
CyArgsList argsList;
argsList.add(iLevel);
argsList.add(ePlayer);
gDLL->getPythonIFace()->callFunction(PYGameModule, "getExperienceNeeded", argsList.makeFunctionArgs(), &lExperienceNeeded);
return int(lExperienceNeeded);
}is caused.
But if you return int(iExperienceNeeded) instead of iExperienceNeeded from CvGameUtils.py everything is fine!
In CCV it looks now like this:
PHP:
def getExperienceNeeded(self, argsList):
# use this function to set how much experience a unit needs
iLevel, iOwner = argsList
iExperienceNeeded = 0
# regular epic game experience
iExperienceNeeded = iLevel * iLevel + 1
iModifier = gc.getPlayer(iOwner).getLevelExperienceModifier()
if (0 != iModifier):
iExperienceNeeded += (iExperienceNeeded * iModifier + 99) / 100 # ROUND UP
return int(iExperienceNeeded)Yours Thomas
Those dlls are definitely needed for Windows 7. I couldn't even get BTS to start in 64 bit Win 7 without them in the BTS folder, but I have never needed them for Vista.
Yes, it did run. I have the dlls in my system, and I compiled with Visual Studio 2010 (after much fiddling). It ran fine on my Win 7 and Vista systems, but there wasn't a lot of debug activity. I'm assuming that I did something wrong in the compile. I'm still learning my way around C++ and VS 2010.
Jester Fool
Emperor
Lemon Merchant - could you please post your makefile? Thanks.
EmperorFool
Deity
@Thomas - I don't see how BULL could be making a difference. I used existing code from CvUnit for calculateExperience(), and I didn't touch the Python code. When dividing one int by another in Python, division of one int by another uses integer division (floor), so adding int() to that Python function should make no difference. Try it in the Python console to be sure, though.
In any case, I'll try it out at home but I don't recall seeing a problem. Where do you notice the problem? What I mean is, how can I easily see the problem when playing the game?
In any case, I'll try it out at home but I don't recall seeing a problem. Where do you notice the problem? What I mean is, how can I easily see the problem when playing the game?
I'm not clear on your post. Are you saying that you have solved this? Or are you asking a question?Solved.
Spoiler :
There isn't a lot of point to that. I'm using EF's standard BULL makefile with the debug option (finally) enabled.
I did mess up before, and I accidentally built a final release. My debug dll does not crash, and does not throw exceptions (at least I can't find any). I'll try it on my Vista machine tomorrow. I'm sleepy atm...
Jester Fool
Emperor
That is the whole point (having it work under Vista). The BUG/BULL/BAT team has done OUTSTANDING work - make no mistake. The central issue is ONLY whether the SDK can be made to FULLY work (including a working Debug dll) under modern OSs (Vista/7). The code base (VC++ 2003) is a major impediment, as I have found out. It could very well be that compatibility issues preclude compiling a Debug dll under Vista (using VC++ 2008/or 2010). If that is the case, no big deal, but it would be very helpful to know. Thank you for your help.
EmperorFool
Deity
Because BTS itself is linked to the VC++ 2003 Toolkit libraries you cannot get a DLL compiled with VS 2005+ which uses the newer libraries to work. You may get the DLL to build, but it won't work with BTS. This is why even if you use VS 2005+ as your IDE you still must use VS++ 2003 Toolkit to do the compilation and linking.
Similar threads
