Éa III, Sword & Sorcery: Developer's Thread

Oh, in that case just use the OutputDebugString() macro (or check the output window to see what DLLs are being loaded). EA_DEBUG is if you want to have integer values from various variables in your output, like saying for instance "This unit now has 3 Strength". It uses sprintf internally (so C-style output formatting), and then adds on stuff like the newline and which class the message is for.
Your posts make me think we are not understanding each other. I don't see any output of any kind, anywhere. I'm not asking about formatting details (yet). I'm not seeing any communication from the dll at all. The VS2010 output window has never shown me anything like that. It only prints anything while I'm compiling a dll.

Also, if you are getting random(ish) CTDs you can find the CvMinidump file in the base Civilization 5 folder. If you place that dump in the same folder as the PDB for the DLL you can then open the dump in Visual Studio and view the state of the program when it crashed.
Hmmm... I haven't looked in that folder for a long time. Last mdmp files are from >2 weeks ago. I had two CTDs, one last night and one the night before. These were overnight runs that stopped sometime after turn 200 (from the Lua.logs). Well, it's possible a gremlin is turning my games off in the middle of the night.


Edit: OK, saw your last post. Let me know when you find something.
 
Your posts make me think we are not understanding each other. I don't see any output of any kind, anywhere. I'm not asking about formatting details (yet). I'm not seeing any communication from the dll at all. The VS2010 output window has never shown me anything like that. It only prints anything while I'm compiling a dll.

Oh, you actually need to attach the Visual Studio debugger to the Civ 5 process. I wrote a guide on how to do this here.
 
I just got this error while testing something else (I have not modified anything related to lua).
 

Attachments

  • 8930_2014-03-29_00003.jpg
    8930_2014-03-29_00003.jpg
    134.1 KB · Views: 90
Assuming that line is (not sure because I've modded this file):
Code:
g_animalsTeam = Players[ANIMALS_PLAYER_INDEX]:GetTeam()
...then I'm worried about your dll.

In EaDefines.lua:
Code:
ANIMALS_PLAYER_INDEX = GameDefines.ANIMAL_PLAYER

You should be able to type GameDefines.ANIMAL_PLAYER in Fire Tuner and get 62. Otherwise, definitely something wrong in your dll build.


ANIMAL_PLAYER and ANIMAL_TEAM are defined in CvDLLUtilDefines.h, and added to GameDefines in CvDllDatabaseUtility.cpp.


Oh No! CvDLLUtilDefines.h has been detached from the solution somehow?! It's there and correctly modded in my repository (click here). But I can't find it in my project solution anymore. It was definitely there a while back.


Edit: OK, I peeked in your repository here and you have the correct modded CvDLLUtilDefines.h. You have an old CvEnums.h though (although that change was only 3 days ago and wouldn't explain the error above).
 
Assuming that line is (not sure because I've modded this file):
Code:
g_animalsTeam = Players[ANIMALS_PLAYER_INDEX]:GetTeam()
...then I'm worried about your dll.

In EaDefines.lua:
Code:
ANIMALS_PLAYER_INDEX = GameDefines.ANIMAL_PLAYER

You should be able to type GameDefines.ANIMAL_PLAYER in Fire Tuner and get 62. Otherwise, definitely something wrong in your dll build.


ANIMAL_PLAYER and ANIMAL_TEAM are defined in CvDLLUtilDefines.h, and added to GameDefines in CvDllDatabaseUtility.cpp.


Oh No! CvDLLUtilDefines.h has been detached from the solution somehow?! It's there and correctly modded in my repository (click here). But I can't find it in my project solution anymore. It was definitely there a while back.


Edit: OK, I peeked in your repository here and you have the correct modded CvDLLUtilDefines.h. You have an old CvEnums.h though (although that change was only 3 days ago and wouldn't explain the error above).

Hm, I just attempted to update my repo with the latest changes from yours and got some merge conflicts. Have you fixed your solution to include the CvDLLUtilDefines by any chance?
 
Hm, I just attempted to update my repo with the latest changes from yours and got some merge conflicts. Have you fixed your solution to include the CvDLLUtilDefines by any chance?
No I haven't done that yet. Not sure how actually.

I've had merge conflict with the last couple of your pull requests, and it is always in EaModding.h. I usually deal with this by matching your EaModding.h, merging the pull, then committing after with my EaModding.h (manually adding any defines you added). But I think you're modding from several commits ago.
 
No I haven't done that yet. Not sure how actually.

I've had merge conflict with the last couple of your pull requests, and it is always in EaModding.h. I usually deal with this by matching your EaModding.h, merging the pull, then committing after with my EaModding.h (manually adding any defines you added). But I think you're modding from several commits ago.

Potentially. I'll sort these issues out and see if the problem remains.
 
One thing that is very confusing to me about the VS2010 project (solution?) is that the folder structure is so different than the actual directory structure on the computer. In the actual directory you have CvGameCoreDLL_Expansion2 and multiple other directories (two more of which are modded). In the project browser all of these files are found inside CvGameCoreDLL_Expansion2. (But I guess that's the name of the project so they have to be in there...)

But even though I can't navigate to CvDLLUtilDefines.h anymore in my VS browser, it is still used in the build. If it wasn't, we'd see a boatload of compilation errors due to missing defines.

OK, looking closer at project/solution files themselves, there is this line in CvGameCoreDLL_Expansion2.vcproj:
Code:
AdditionalLibraryDirectories=""$(SolutionDir)\CvWorldBuilderMap\lib\";"$(SolutionDir)\CvGameCoreDLLUtil\lib\";"$(SolutionDir)\CvLocalization\lib\";"$(SolutionDir)\CvGameDatabase\lib\";"$(SolutionDir)FirePlace\lib\";"$(SolutionDir)ThirdPartyLibs\Lua51\lib\""
I assume that line is why things are working. I.e., "$(SolutionDir)\CvGameCoreDLLUtil\lib\";"" finds the file and lets the compiler use it for the build.

But looking through CvGameCoreDLL_Expansion2.vs2010.vcxproj I don't see CvDLLUtilDefines.h in any include lines (I can see the two .h files that we have added).

I have no clue what the difference between .vcproj and .vcxproj are. Does the first control what's compiled and the second what's navigable in the VS browser? Is the fix just simply adding the following line to the .vcxproj file?
Code:
<ClInclude Include="CvDLLUtilDefines.h" />
 
One thing that is very confusing to me about the VS2010 project (solution?) is that the folder structure is so different than the actual directory structure on the computer. In the actual directory you have CvGameCoreDLL_Expansion2 and multiple other directories (two more of which are modded). In the project browser all of these files are found inside CvGameCoreDLL_Expansion2. (But I guess that's the name of the project so they have to be in there...)

But even though I can't navigate to CvDLLUtilDefines.h anymore in my VS browser, it is still used in the build. If it wasn't, we'd see a boatload of compilation errors due to missing defines.

OK, looking closer at project/solution files themselves, there is this line in CvGameCoreDLL_Expansion2.vcproj:
Code:
AdditionalLibraryDirectories="&quot;$(SolutionDir)\CvWorldBuilderMap\lib\&quot;;&quot;$(SolutionDir)\CvGameCoreDLLUtil\lib\&quot;;&quot;$(SolutionDir)\CvLocalization\lib\&quot;;&quot;$(SolutionDir)\CvGameDatabase\lib\&quot;;&quot;$(SolutionDir)FirePlace\lib\&quot;;&quot;$(SolutionDir)ThirdPartyLibs\Lua51\lib\&quot;"
I assume that line is why things are working. I.e., "$(SolutionDir)\CvGameCoreDLLUtil\lib\&quot;;&quot;" finds the file and lets the compiler use it for the build.

But looking through CvGameCoreDLL_Expansion2.vs2010.vcxproj I don't see CvDLLUtilDefines.h in any include lines (I can see the two .h files that we have added).

I have no clue what the difference between .vcproj and .vcxproj are. Does the first control what's compiled and the second what's navigable in the VS browser? Is the fix just simply adding the following line to the .vcxproj file?
Code:
<ClInclude Include="CvDLLUtilDefines.h" />

If that include is not in the vanilla project we don't need it. I'd suggest using the Visual Studio interface to add the missing header file to the project if it isn't there for you.
 
If that include is not in the vanilla project we don't need it. I'd suggest using the Visual Studio interface to add the missing header file to the project if it isn't there for you.
I'll try this later today or tomorrow.

I'm still concerned whether you have a functional build or not. I always test in autoplay before I commit, so at any time the repositories should represent a build that at least "works". Of course there are always new bugs, and bugs that autoplay specifically misses. But I'm not able to get a sense from your posts if the game is generally working at alpha level or if it is totally fubar. (And for alpha level I am not at all concerned about help texts...)

One problem I suspect you might be having is from using dll and non-dll builds that are far apart in commits. I suggest you synchronize these two repositories at the same time, and then proceed to testing/modding. When you do post errors, start posting Lua.log (I can tell from your screenshot above that this wasn't the first error ... and there is no reason to test beyond the first error).

On other finishing topics: I'm going to complete the list of Favored Techs and Enabled Policies for each of the civs (I'll post an updated Manual when I do). But I'll still need help filling in effects for all the new Policies (most but not all of which are already there in the list).
 
I'll try this later today or tomorrow.

I'm still concerned whether you have a functional build or not. I always test in autoplay before I commit, so at any time the repositories should represent a build that at least "works". Of course there are always new bugs, and bugs that autoplay specifically misses. But I'm not able to get a sense from your posts if the game is generally working at alpha level or if it is totally fubar. (And for alpha level I am not at all concerned about help texts...)

One problem I suspect you might be having is from using dll and non-dll builds that are far apart in commits. I suggest you synchronize these two repositories at the same time, and then proceed to testing/modding. When you do post errors, start posting Lua.log (I can tell from your screenshot above that this wasn't the first error ... and there is no reason to test beyond the first error).

On other finishing topics: I'm going to complete the list of Favored Techs and Enabled Policies for each of the civs (I'll post an updated Manual when I do). But I'll still need help filling in effects for all the new Policies (most but not all of which are already there in the list).

Nah, it is working when I use 'clean' source (i.e. I haven't made changes). That build as I said was several commits old and I haven't been able to figure out where the merge conflict is beyond the fact that it is in CvUnit.cpp (did you change something there?) I do autoplay to find anything major amiss, but since I have only worked on Ea for a couple weeks I still am not familiar sometimes with what is intended and what isn't, so I may miss things.
 
... where the merge conflict is beyond the fact that it is in CvUnit.cpp (did you change something there?)
Yes, I modified your code in this commit. That was after merging your last pull request. Maybe we both tried to fix this code but did it in different ways?
 
I finally had to solve the issue by deleting my old repository and forking your current EaDLL repo again. I didn't lose anything, but this whole fiasco has delayed the IsWorker tag by a few days.
 
@ls612, do you want to do the dll-side fix for "UNIT_WORKER" hard-coding?

Mostly these can be fixed by a new Units tag "IsWorker" and then adding isWorker() method in dll. I'll go ahead and prep for a solution by adding IsWorker tag and setting it for the 6 worker units.

There are at least two methods where you need to know the proper worker type for a given Minor player. I'll code this information into the MinorCivilizations table with a new column: "WorkerUnitType". Note that some Minor civs are "gods" (not even on the map) and this tag will be NULL. I'm not sure whether the relevant methods ever get called for these. But it may be best to figure out a safe way to deal with this. (NULL in table becomes eUnitType == NO_UNIT on the dll side.)

Sorry for the extra posts, but how do you want me to determine what the 'best' worker is for a situation? The DLL expects in many places to be given an eUnitType which is a worker, and I need to write a helper method to determine what that unitType will be.
 
I finally had to solve the issue by deleting my old repository and forking your current EaDLL repo again. I didn't lose anything, but this whole fiasco has delayed the IsWorker tag by a few days.
I had similar problems early on. Now I'm much more careful to bring in your pulls quickly, and try to stay away from stuff you're doing (or post here if not).


Sorry for the extra posts, but how do you want me to determine what the 'best' worker is for a situation? The DLL expects in many places to be given an eUnitType which is a worker, and I need to write a helper method to determine what that unitType will be.

When I did a superficial look for these, I thought all the cases where you needed the specific type were only for Minor players. In other cases you had the unit and needed to know if it was a worker. These two tags are already in the current non-dll build:
Mostly these can be fixed by a new Units tag "IsWorker" and then adding isWorker() method in dll. I'll go ahead and prep for a solution by adding IsWorker tag and setting it for the 6 worker units.

There are at least two methods where you need to know the proper worker type for a given Minor player. I'll code this information into the MinorCivilizations table with a new column: "WorkerUnitType". Note that some Minor civs are "gods" (not even on the map) and this tag will be NULL. I'm not sure whether the relevant methods ever get called for these. But it may be best to figure out a safe way to deal with this. (NULL in table becomes eUnitType == NO_UNIT on the dll side.)
Are there any places were you need to determine worker type and the player is not a minor?

If you do, it's a bit more complicated but doable. The 6 units are:
UNIT_WORKERS_MAN
UNIT_WORKERS_SIDHE
UNIT_WORKERS_ORC
UNIT_SLAVES_MAN
UNIT_SLAVES_SIDHE
UNIT_SLAVES_ORC
Those with Slavery have slaves; all others have workers. Race can be determined from the EaRace column in the Civilizations table. full civs are all one of these: EARACE_MAN, EARACE_SIDHE, EARACE_HELDEOFOL (the last one matches units ..._ORC).
 
When I did a superficial look for these, I thought all the cases where you needed the specific type were only for Minor players. In other cases you had the unit and needed to know if it was a worker. These two tags are already in the current non-dll build:
Are there any places were you need to determine worker type and the player is not a minor?

If you do, it's a bit more complicated but doable. The 6 units are:
UNIT_WORKERS_MAN
UNIT_WORKERS_SIDHE
UNIT_WORKERS_ORC
UNIT_SLAVES_MAN
UNIT_SLAVES_SIDHE
UNIT_SLAVES_ORC
Those with Slavery have slaves; all others have workers. Race can be determined from the EaRace column in the Civilizations table. full civs are all one of these: EARACE_MAN, EARACE_SIDHE, EARACE_HELDEOFOL (the last one matches units ..._ORC).

Yes, there are many instances where the worker needs to be determined not regarding a minor civ (the AI in particular needs instruction on this).

How do I determine if someone has slavery?
 
How do I determine if someone has slavery?
They have POLICY_SLAVERY.


Edit: On the race, it's actually more complicated than I said above. It's possible for a civ to have another race's workers, since unit race is maintained through capture. In fact, unit race is determined by city (not civ) so it's possible for a Sidhe civilization to make units of another race Man (specifically, in a captured city).

Can you point me to code that needs to know major civ worker type? I may need to figure these out case-by-case.
 
Something I've added to the DLL/DB that may be of interest - naming of units based on a promotion, eg, name the Kris Swordsmen depending on which "blade" they have

Code:
<Table name="UnitPromotions_UnitName">
    <Column name="PromotionType" type="text" reference="UnitPromotions(Type)"/>
    <Column name="UnitType" type="text" reference="Units(Type)"/>
    <Column name="Name" type="text" reference="Language_en_US(Tag)"/>
</Table>

<UnitPromotions_UnitName>
    <Row>
        <PromotionType>PROMOTION_INVULNERABIILITY</PromotionType>
        <UnitType>UNIT_KRIS_SWORDSMAN</UnitType>
        <Name>TXT_KEY_UNIT_INDONESIAN_KRIS_SWORDSMAN_INVULNERABIILITY</Name>
    </Row>
    <Row>
        <PromotionType>PROMOTION_SNEAK_ATTACK</PromotionType>
        <UnitType>UNIT_KRIS_SWORDSMAN</UnitType>
        <Name>TXT_KEY_UNIT_INDONESIAN_KRIS_SWORDSMAN_SNEAK_ATTACK</Name>
    </Row>
    ...
<UnitPromotions_UnitName>
 
Back
Top Bottom