PieceOfMind's Advanced Combat Odds

[PieceOfMind]

Ok, I don't know what a makefile does, and I'm not sure how to add anything to linkobjs definitions.

I did manage to get a successful compilation yesterday, but now as soon as I try to begin a custom game it crashes to desktop. I haven't yet had a chance to look at the dump file. I had to add about 8 or 9 .cpp files to the project in codeblocks before the compile errors went away.

Like I've said before, I'm a bit of a hack with this sort of thing - I really don't know what I'm doing.

 

[phungus420]

You should use the MSV2005 method in the thread I linked to with glider's post which contains the makefile you need. Just follow that tut, and use the makefile in glider's post I linked to and it should come out alright.

 

[PieceOfMind]

Is there a way I can do it with Codeblocks or will I need to install Microsoft Visual C++ 2005 as a matter of course?

To date, all I've needed is Kael's guide http://forums.civfanatics.com/showthread.php?t=166933.

 

[EmperorFool]

I don't know any reason why continuing to use Code::Block should not work, but I never tried to get that method to work in the first place. Add all the new .cpp files to the project except one (CvScreenWindow.cpp or something like that). All the other new files need to be in there.

 

[PieceOfMind]

I don't know any reason why continuing to use Code::Block should not work, but I never tried to get that method to work in the first place. Add all the new .cpp files to the project except one (CvScreenWindow.cpp or something like that). All the other new files need to be in there.

Ok I'll see if I missed any files I was meant to add to the project. Out of interest, should the DLL be able to compile in the first place if something was not added to the project? I made an assumption that because it compiled successfully that all the files were there, but I'm not actually sure about this.

 

[EmperorFool]

It's theoretically possible for the project to compile yet be missing files if there were some stand-alone functions exposed to the EXE from the DLL in those missing files. Most all of the files reference each other in a graph, but some could be entirely separate and used only by the EXE. Unlikely, but possible.

 

[PieceOfMind]

Actually, I'm not even convinced I have all the source files I'm meant to have. Is there somewhere I can see the full list of all the source files? Or even download the entire source?

 

[EmperorFool]

The only way I know of to get the files normally is to patch to 3.19 and pull them from the CvGameCoreDLL folder.

 

[PieceOfMind]

Ok I have a working DLL now.

I'm working on the actual features now. I'm wondering, would anyone think it a problem if I ignore the option of not using ACO? This might only be relevant in mods that incorporate this modcomp as a feature which can be disabled.

I'd prefer to just completely replace the old odds display.

 

[phungus420]

I'd be fine with that. But I dont' think it's a good idea, as it'll take more work to incorporate for other modders. For instance I know BULL offshoots from BUG so they like to allow for diableing new features per the user's taste. And also I think glider, who incorporates it through RevDCM prefers to allow it to be toggled off.

Like I said, for me personally that'd be fine. But you'll probably save other modders work if you include a disableing ability.

 

[muxec]

Marble, ACO and BUG are the only mods I'm going to use so I do not care.



....Oromo warriors, however, do care

 

[PieceOfMind]

I'd be fine with that. But I dont' think it's a good idea, as it'll take more work to incorporate for other modders. For instance I know BULL offshoots from BUG so they like to allow for diableing new features per the user's taste. And also I think glider, who incorporates it through RevDCM prefers to allow it to be toggled off.

Like I said, for me personally that'd be fine. But you'll probably save other modders work if you include a disableing ability.

Sounds sensible. At the moment, what I've done is left ACO as disablable, but where I have re-ordered how the combat modifiers are shown at the bottom, I have left them the same whether ACO is enabled or not. It would be a bit tedious to have if statements that determine the order of these parts.
Also, moving the hitpoints to the line with the modified strength values is done whether ACO enabled or not.

illustration:

 

[Ninja2]

Please remind me again - why are they ordered the way they are? It's green-green-red-red-red-green-green-red, which honestly looks a little messy. 3.19 pure looks nicer, but I'm sure there's a good reason why you've rearranged them.

 

[PieceOfMind]

The first two green values are the only ones that modify the attacker's attributes directly. Since the other combat modifiers are all things that affect the defender, that is why I moved the other green bonuses lower and made them negative. At the moment, I'm trying out some different colours for these attacker's modifiers.

 

[PieceOfMind]

A preview (update) of the features in v1.1 so far:

Changelog: v1.1

Spoiler :

(7/7/2009)
-Fixed typo in name of header file AdvancedCombatOdds.h
-Added unit help line, for defender, and attacker if enabled
-Re-arranged some of the combat modifiers. Attacker bonuses that are subtracted from defender are now shown in with defender bonuses, but before the defender first strikes.
-Put damaged unit hitpoints in with combat_strength line - this saves some space
-Made attacker modifiers show as negative, to more accurately show they are subtracted from the defender bonuses
-New! Total defense modifier shown underneath modifiers that affect defender.

-Removed the old Detail settings and implemented a 2-view system (View B is the one that is accessed by pressing SHIFT), where most ACO lines can be customised to be shown with View A, View B, both or neither.
These include: (defaults are in parentheses)

Text "Press SHIFT for more detail" (View A)
Defender unit help (View A and B)
Attacker unit help (Neither)
ACO_Option_XPRangeDisplay (View B)
Unharmed Odds (View B)
Survival Odds (View A and B)
Unrounded XP (Neither)
Average HP (View B)
Attacker HP bars (View B)
Defender HP bars (View B)
Basic Info (the line with HP per hit, and odds per hit etc.) (View A and B)
Total Defense Modifier (View B)
Individual Defense Modifiers (View A and B)​

For each of the above options, assign the XML value of 0,1,2 or 3 for:
0 = Neither A nor B
1 = A only
2 = B only
3 = A and B


-Low detail speficic settings (i.e. 1 decimal place) removed.

-bar condensing is now an XML option. It is either enabled or disabled - not changeable by view selection.

Below is an example of a very detailed setup vs. a minimalist setup. As noted in the changelog, most of these individual lines can be customised now, based on EF's suggestion earlier in the thread. Now it is just two views: A and B. The detail settings have been removed.

 

[muxec]

Looks great!

 

[PieceOfMind]

Version 1.1 has been uploaded!

Please keep the feedback coming!

Fully updated for BtS 3.19

 

[EmperorFool]

Looks great. It'll be a little while before I can update ACO in BULL as I'm pretty busy this week. I'll also have to wrestle with getting both versions of the modifiers in there since I'll probably make that an option as well.

 

[PieceOfMind]

Looks great. It'll be a little while before I can update ACO in BULL as I'm pretty busy this week. I'll also have to wrestle with getting both versions of the modifiers in there since I'll probably make that an option as well.

I'm sure I could still work that into the next version and release it in short time. If it's really deemed to be necessary, that is.

I mean, if space is not a problem I could just copy paste the old code and put it in a big if function

if(aco disabled)
. .. .. .. .. .old code
else
. .. .. .. .. .new code
end if

It's just that this will add possibly another couple hundred lines of code for little gain.

 

[EmperorFool]

For your release it makes no sense to do that. People will either want ACO or not. But for BULL, I want to maintain the option to have every feature configurable in its entirety. Some people may not want to see the green and red lines mixed together.

A few hundred lines of code is nothing in a DLL this big. I can think of two additional ways to handle the options.

1. Put the code for each modifier in two places: its original place and (if needed) its ACO place:

// normal place
if (aco is off)
    add option as +

...

if (aco is on)
    add option as -

2. Build up two buffers and append them at the end
CvWString attacker;
CvWString defender;

if (has bonus vs. melee)
if (aco is on)
add option as - to defender buffer
else
add option as + to attacker buffer

...

append attacker buffer
append defender buffer
[/code]

Method 2 results in the least amount of duplicated code but is a more radical change and more likely to have bugs. Having one giant if/else block duplicates the most code but has the least likelihood of bugs.