Empire Meters Not Being Reset Every Turn

Bigjoe5 · **Posted:** Sun Apr 29, 2012 11:41 pm

While I was experimentally giving empires a Neutronium meter, I realized that empire meters aren't being reset to 0 every turn, so effects which modify them just keep building up over time. It doesn't seem to be doing any harm at the moment, since the only techs that affect empire detection set it to a fixed value. However, in the future if there's some tech or building that increases empire detection by some fixed amount (in other words, setting it to Value + something), then it's going to be a problem. What I ended up doing was adding the following function:

Code:

void Empire::ResetTargetMaxUnpairedMeters() {
    const AlignmentManager& alignment_manager = AlignmentManager::GetAlignmentManager();
    const std::vector<Alignment>& alignments = alignment_manager.Alignments();
    for (std::vector<Alignment>::const_iterator it = alignments.begin(); it != alignments.end(); ++it) {
        const Alignment& alignment = *it;
        this->GetMeter(alignment.Name())->ResetCurrent();
    }
    this->GetMeter("METER_DETECTION")->ResetCurrent();
    this->GetMeter("METER_NEUTRONIUM")->ResetCurrent();
}

...which is called from Universe::ApplyAllEffectsAndUpdateMeters():

Code:

         it->second->ResetPairedActiveMeters();
     }
 
+    for (EmpireManager::iterator it = Empires().begin(); it != Empires().end(); ++it) {
+        Empire *empire = it->second;
+        empire->ResetTargetMaxUnpairedMeters();
+    }
+
     ExecuteEffects(targets_causes, true);
 

Is it OK if I retain these changes and commit them (sans "METER_NEUTRONIUM")?

Geoff the Medio · **Posted:** Sun Apr 29, 2012 11:57 pm

Bigjoe5 wrote:

ResetTargetMaxUnpairedMeters

Are there any paired (or target or max) empire meters? If not, this function could / should be just "ResetMeters". As long as that's the case, you could / should also just iterate over all empire meters and reset them all, rather than hard coding individual meter names. If some empire meters need to be handled differently, then something fancier to specify how each meter should be handled seems necessary...

Bigjoe5 · **Posted:** Mon Apr 30, 2012 12:19 am

Geoff the Medio wrote:

Bigjoe5 wrote:

ResetTargetMaxUnpairedMeters

Are there any paired (or target or max) empire meters?

Well no, but should there be paired meters added (or target or max), which isn't totally unthinkable, the types of meters that would be reset by this function would be target, max and unpaired, and it would be annoying to have to go back and change the name of the function when that happens.

Geoff the Medio wrote:

As long as that's the case, you could / should also just iterate over all empire meters and reset them all, rather than hard coding individual meter names.

I hadn't realized that was possible, but at a second look, there does seem to be an m_meters I could iterate over. This does also defeat the purpose of leaving the name of the function as-is, so I might as well just change it, I suppose.

Geoff the Medio wrote:

If some empire meters need to be handled differently, then something fancier to specify how each meter should be handled seems necessary...

I feel the same way about regular meters too, but as it stands there seems to typically be just a lot of repeated calls to the same function on different, hard-coded meters.

A relatively easy way to handle it might be to have an enumerated type (MeterRole, or some such) representing whether the meter is target, max, unpaired or current, and then have m_meters map from a string (or for planet meters, the enum MeterType) to a pair<Meter, MeterRole>, instead of just a meter. That way it would be easy to iterate over the whole set of meters and just act on meters of a particular role or roles.

Or we could define some new classes derived from Meter, but that just sounds painful and way too complicated.

edit: How's this?

Code:

void Empire::ResetMeters() {
    for (std::map<std::string, Meter>::iterator it = m_meters.begin(); it != m_meters.end(); ++it) {
        it->second.ResetCurrent();
    }
}

Geoff the Medio · **Posted:** Mon Apr 30, 2012 4:18 am

Bigjoe5 wrote:

I feel the same way about regular meters too, but as it stands there seems to typically be just a lot of repeated calls to the same function on different, hard-coded meters.

It's not really justified, but in my mind the empire meters are usually more "user-defined" than the standard object meters, which are all defined as enums in the C++ code, so it's more reasonable to have them have hard-coded. More practically, there are a lot of small variations on how object meters function or are reset or modified, to deal with various special cases that arise, so trying to boil that down to just a few enum values would be tricky...

Quote:

How's this?

ResetMeters looks fine...

eleazar · **Posted:** Tue May 01, 2012 3:44 am

I'm not sure what it is supposed to be doing, but as of SVN 4852 + my few updated scripts,
every cultural archive on the map adds to a ship's stealth value.

Geoff the Medio · **Posted:** Tue May 01, 2012 3:52 am

eleazar wrote:

every cultural archive on the map adds to a ship's stealth value.

Not just ships... From here:

Code:

EffectsGroup
    scope = EmpireMeter empire = LocalCandidate.Owner meter = "METER_DETECTION" low = 5 high = 99999
    effects = SetStealth Value + 100

commit 4851 log wrote:

-Added EmpireMeterValue condition parsing and a demo effectsgroup in Cultural archives.

eleazar · **Posted:** Tue May 01, 2012 5:27 pm

I think that is causing a noticeable speed hit in large galaxies, since i've given the cultural archive to many minor species per this idea.

You understand, each ship, planet, etc gets a +100 from every known cultural archive, right? In one test the tooltip spanned (and i think went past) the 1400 vertical pixels of my screen.

If you want the cumulative effect, can you attach it to something less numerous?

Geoff the Medio · **Posted:** Tue May 01, 2012 5:37 pm

eleazar wrote:

Problems!

It's just a demonstration of the new condition parsing, not intended for long-term use. Change it however you want.

eleazar · **Posted:** Tue May 01, 2012 7:25 pm

Geoff the Medio wrote:

eleazar wrote:

Problems!

It's just a demonstration of the new condition parsing, not intended for long-term use. Change it however you want.

Heh, OK.

revision 4858
"Moved example scripting for empire meters to the much rarer imperial palace."

I assume the first, obvious use for this will be to display the empire-wide detection strength?

Geoff the Medio · **Posted:** Tue May 01, 2012 7:54 pm

eleazar wrote:

...display the empire-wide detection strength?

I don't know what you mean by "display"...

eleazar · **Posted:** Tue May 01, 2012 8:08 pm

Geoff the Medio wrote:

eleazar wrote:

...display the empire-wide detection strength?

I don't know what you mean by "display"...

Did you implement your idea to have an empire-wide detection strength, with empire objects only varying in the distance they can detect?

I thought you had, and if so, i don't see where you can find out what your empire's detection strength is. That IMHO is a number that would be appropriate in the top bar.

Geoff the Medio · **Posted:** Tue May 01, 2012 8:44 pm

eleazar wrote:

Did you implement your idea to have an empire-wide detection strength, with empire objects only varying in the distance they can detect?

Yes.

Quote:

I thought you had, and if so, i don't see where you can find out what your empire's detection strength is. That IMHO is a number that would be appropriate in the top bar.

There's presently nowhere that is shown, but I don't see what that has to do with implementing parsing for the EmpireMeterValue condition...

FreeOrion

Empire Meters Not Being Reset Every Turn

Who is online