FreeOrion

I'm always against adding unnecessary code. As long as we only use priority numbers defined by macros, the benefit to coding in a milestone system explicitly is somewhat underwhelming. Shuffling a few numbers around in a small list of macros is vastly less work than trying to do the whole thing with...

Here are my initial thoughts on implementation: 1. Create a PriorityGroupParser to parse the list of priority groups. The definition should be almost trivially simple in this case. 2. Add a PriorityGroupManager in common/universe which uses the PriorityGroupParser to get its priority groups, and has...

I was reminded of the "milestone" idea for ordering effects from this thread . Rather than merging the solution with priority numbers immediately, I'd like to propose a specific solution using milestones instead of priority numbers. We will need a new file: "priority_groups.txt"....

I've been growing fonder of the idea of making detection parts vastly more expensive than they are now. Having only a few very valuable and expensive scouts to allocate sounds like it will reduce the micromanagement of whichever stealth mechanics we use. I also think this works well in concert with ...

I took a stab at implementing effects group priority. Pull request here.

Maybe my assumption was false and it is a good idea to merge release branches back into master after tagging the actual release. I need to think about that. In my experience, it is a bad idea to merge the release branch back into master. It's best to just make the call for each new branch whether t...

Honestly, I wish there was a better way of doing this "stealth an empire" stuff. Suggestion: Differentiate between the stealth of a planet itself and the colony existing on its surface. If the stealth of the planet itself defeats your detection strength, you just don't see the planet at a...

Vezzra wrote:

Add .gitignore

Ah yes, of course! During my tests I've already compiled a .gitignore, I've a few more adjustments I want to do, then I can post it and have you take a look at it.

This repo contains a number of standard .gitignores, which we could probably use as a reference for our own.

When it comes to the whole effects execution stuff I have to admit major ignorance, so forgive me if I got that completely wrong, BUT: Won't the order in which all the effects get executed completely changed by that rewrite? And considering how much the end results especially for meter affecting ef...

So my last question is, what should be done in the case where non-stacking effects modify different meters? 'UseMax' basically assumes that all the effects group in that stacking group only have one effect, and they all modify the same meter, but that's not guaranteed to be the case. What would be ...

I'll just have to add a Priority_token, and then update the effects_group rule (Parse.cpp:75) to take optional type and priority. I'm a bit stuck on thinking of priorities along the lines of the priority groups that Cami had begin implementation of; although that didn't get fully finished off yet I...

Finally got around to looking at this. Seems like there will be two main alterations to existing code, which will be tied together by a new StackingGroup struct. First, the parser, which is relatively straightforward. I'll just have to add a Priority_token, and then update the effects_group rule (Pa...

I think part of the purpose of the auto upgrade was to ensure you didn't wind up with multiple different specials on the same planet, although that could be more specifically handled. This is already handled in the definitions of the specials. They remove any previous stealth specials on the planet...

Aren't 0-stealth objects still visible to the entire galaxy?

Look at the effects for SP_ASH and SP_DIM - these ship parts have effects groups like the following: Part name = "SP_ASH" ... EffectsGroup scope = HasSpecial "CLOUD_COVER_MASTER_SPECIAL" activation = Source effects = [ RemoveSpecial "CLOUD_COVER_MASTER_SPECIAL" AddSpeci...