Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

Describe your experience with the latest version of FreeOrion to help us improve it.

Moderator: Oberlus

Forum rules
Always mention the exact version of FreeOrion you are testing.

When reporting an issue regarding the AI, if possible provide the relevant AI log file and a save game file that demonstrates the issue.
Message
Author
Ophiuchus
Programmer
Posts: 1808
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#16 Post by Ophiuchus »

I'd like to correct the code, but I don't understand where to get the ship's name ?
For the ship name to be known, the sitrep effect needs to reference the created ship.
In order to do that it needs to be one of Target/Source/*Candidate. The content where the macro is used is actually a planet special, so the Source is the planet.
I suggest to go for Target. In order for that you need to move the sitrep to an additional effects group. Something similar to

Code: Select all

EffectsGroup
            scope = AND [
                Ship
                RootCandidate.Age = 1
                OwnedBy affiliation = AnyEmpire
            ]
            activation = AND [
                Planet
                OwnedBy affiliation = AnyEmpire
            ]
            effects = [
                GenerateSitRepMessage
                    message = "EFFECT_TAME_MONSTER_HATCHED"
                    label = "EFFECT_TAME_MONSTER_HATCHED_LABEL"
                    icon = "icons/monsters/@[email protected]"
                    parameters = [
                        tag = "ship" data = Source.ID
                        tag = "predefinedshipdesign" data = "[email protected]@_1"
                    ]
                    empire = Target.Owner
            ]
Then you can use %ship% in the sitrep (NB: Age = 1 is probably not correct.)
I thought the Academy added a flat bonus to research bound to focus ?
Adds also pop-based stockpile-focus bonus
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
LienRag
Space Dragon
Posts: 300
Joined: Fri May 17, 2019 5:03 pm

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#17 Post by LienRag »

Ophiuchus wrote: Thu Oct 15, 2020 11:05 am
I'd like to correct the code, but I don't understand where to get the ship's name ?
For the ship name to be known, the sitrep effect needs to reference the created ship.
In order to do that it needs to be one of Target/Source/*Candidate. The content where the macro is used is actually a planet special, so the Source is the planet.
I suggest to go for Target. In order for that you need to move the sitrep to an additional effects group. Something similar to

Code: Select all

EffectsGroup
            scope = AND [
                Ship
                RootCandidate.Age = 1
                OwnedBy affiliation = AnyEmpire
            ]
            activation = AND [
                Planet
                OwnedBy affiliation = AnyEmpire
            ]
            effects = [
                GenerateSitRepMessage
                    message = "EFFECT_TAME_MONSTER_HATCHED"
                    label = "EFFECT_TAME_MONSTER_HATCHED_LABEL"
                    icon = "icons/monsters/@[email protected]"
                    parameters = [
                        tag = "ship" data = Source.ID
                        tag = "predefinedshipdesign" data = "[email protected]@_1"
                    ]
                    empire = Target.Owner
            ]
Then you can use %ship% in the sitrep (NB: Age = 1 is probably not correct.)

Thanks.
Alas, I dabbled a little bit into FOCS, but not enough to understand the implications of what you're writing here.

I mean, after a lot of efforts I finally understand what you're suggesting, but I don't get every piece of code.
The FOCS Scripting details page is not easy to understand...
For the Monster Nest macro, where you suggest adding the EffectGroup, the Source.ID would be the ship because the ship is in the scope ?
But I thought the Source.ID would be the ship's internal ID, while we want its name ? Shouldn't it be Source.Name then (I checked that the variable name is supposed to exist) ?

Also, I absolutely do not understand what happens when EffectsGroups are put one after another : do they happen independantly ?
We want the sitrep generated only if the random activation of the hatching occured : I don't get how this conditionality happens if you put one EffectGroup after another ?
In the MonsterNest macro, there are two separate EffectGroups, each with it probability, one for the unowned Nests and the other for the the tamed ones. I don't see a dependancy between the two ? By the way, the random number for the unowned monsters is hardcoded but passed as a parameter for tamed monsters, is that on purpose ? That means that unowned monsters have a general probability of 0,12 to spawn while tamed monsters have varied (but always lower) probabilities to spaw, respectively 0,5 0,6 and 0,8 for Krakens, Juggernauts and Snowflakes.

In your example the EffectGroup would be triggered by the existence of a newly born ship ? But what if the outpost is settled and has a shipyard ?
The ship is the RootCandidate because its existence is the first condition tested in the scope ? Wouldn't that mean that any ship produced in a shipyard in the same planet would trigger this sitrep ?

The Monster Body FOCS file calls the Sitrep effect with

Code: Select all

[
                        tag = "system" data = Source.SystemID
                        tag = "predefinedshipdesign" data = "SM_SNOWFLAKE_2"
                    ] 	
but not with the ship name: should I just add this name as another tag (and then call it as the third parameter in the Sitrep effect)? Where to get it ? It doesn't appear in the file. Is it something like Source.ID ?
But the Source is the former monster, which is destroyed before a new one is created, if I understand the code correctly.

The designame after CreateShip is the name of the ship design, not the name of the ship ?


Also, I noticed that the code for generation of Monster Nests after the first turn is

Code: Select all

activation = Not Turn low = 1
            stackinggroup = "GAME_START_MOD_STACK"
            accountinglabel = "ADD_NEST_SPECIAL_EFFECT_1"
            effects = AddSpecial name = "SNOWFLAKE_NEST_SPECIAL"
for Snowflakes,

Code: Select all

activation = Not Turn low = 1
            stackinggroup = "GAME_START_MOD_STACK"
            effects = AddSpecial name = "JUGGERNAUT_NEST_SPECIAL"
for Juggernauts
and

Code: Select all

activation = Turn high = 2
            stackinggroup = "GAME_START_MOD_STACK"
            effects = AddSpecial name = "KRAKEN_NEST_SPECIAL"
for Krakens.
I'm not sure to understand the syntax of "turn high" and "not turn low", but I guess that they have the same meaning (not generating Nests on the first turn through this code) ?
Looking at the stacking group, I guess it's only to prevent the planet to be later turned into a barren one by Philosopher or Honeycomb special ? But why, if this Nest creation is happening after turn 1 ?
And is there a reason for only Snowflake nests to have the "ADD_NEST_SPECIAL_EFFECT_1" ? It seems to not be in any other FOCS file, is grep told me the truth.



Oberlus wrote: Wed Oct 14, 2020 1:59 pm Feel free to make any modification of your choice, playtest it and eventually make a PR to integrate your contributions into the game.

You're definitely right, but slightly modifying random numbers brings very difficult to isolate variations : when I'll get a Monster (tamed or not), how will I know that it spawned specifically in the range I modified rather than outside (i.e, that it would not have spawned if not for my modifications) ?
It would require a lot of comparative playtesting to get any meaningful info from it...

Ophiuchus
Programmer
Posts: 1808
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#18 Post by Ophiuchus »

LienRag wrote: Thu Oct 22, 2020 11:28 pm For the Monster Nest macro, where you suggest adding the EffectGroup, the Source.ID would be the ship because the ship is in the scope ?
Sorry, I meant Target.ID (targets are what gets selected in the scope). The Source is the planet for a planet special. I did not test that code - there might be more errors.
LienRag wrote: Thu Oct 22, 2020 11:28 pm But I thought the Source.ID would be the ship's internal ID, while we want its name ? Shouldn't it be Source.Name then (I checked that the variable name is supposed to exist) ?
AFAICR The %ship% tag uses the id to find the right ship, writes the ship's name and provides a link to the pedia entry for that ship (or its design).
LienRag wrote: Thu Oct 22, 2020 11:28 pm Also, I absolutely do not understand what happens when EffectsGroups are put one after another : do they happen independantly ?
If they have the same priority, they are executed one after the other. One can stop effects from being happening by using stackinggroups. So in those cases you have to get priority/order right.
LienRag wrote: Thu Oct 22, 2020 11:28 pmWe want the sitrep generated only if the random activation of the hatching occured : I don't get how this conditionality happens if you put one EffectGroup after another ?
use the same stacking group. if an effect is applied to an object, the stacking group gets added to that object. if an effect is about to be applied to an object it checks first if the object has the same stacking group. If so, the effect is NOT applied.
LienRag wrote: Thu Oct 22, 2020 11:28 pmIn the MonsterNest macro, there are two separate EffectGroups, each with it probability, one for the unowned Nests and the other for the the tamed ones. I don't see a dependancy between the two ?
without looking, sounds right.
LienRag wrote: Thu Oct 22, 2020 11:28 pmBy the way, the random number for the unowned monsters is hardcoded but passed as a parameter for tamed monsters, is that on purpose ?
I would guess that is accidential.
LienRag wrote: Thu Oct 22, 2020 11:28 pm In your example the EffectGroup would be triggered by the existence of a newly born ship ? But what if the outpost is settled and has a shipyard ?
The ship is the RootCandidate because its existence is the first condition tested in the scope ? Wouldn't that mean that any ship produced in a shipyard in the same planet would trigger this sitrep ?
The EffectGroup gets triggered by the special on the planet (planet special definition, activation condition).
It applies to all newly build ships in any empire - this is wrong, there should be a "ContainedBy id = Source.SystemID" condition (scope condition). Also it should only apply to monsters (AFAICR there is a convenient "Monster" condition), you might even check for the design name.
If you got multiple monster nests in that system, the scope will still be wrong.
LienRag wrote: Thu Oct 22, 2020 11:28 pm The Monster Body FOCS file calls the Sitrep effect... ...but not with the ship name... ...But the Source is the former monster, which is destroyed before a new one is created, if I understand the code correctly....
you could try

Code: Select all

[
                        tag = "system" data = Source.SystemID
                        tag = "predefinedshipdesign" data = "SM_SNOWFLAKE_2"
                        tag = "ship" data = Source.ID
                    ] 	
If the effect is on the former monster, you could move the sitrep to a freshly hatched higher monster. Or you request a feature for a value ref which gives access to the last created ship/add a (sitrep)effect field to CreateShip.
LienRag wrote: Thu Oct 22, 2020 11:28 pm The designame after CreateShip is the name of the ship design, not the name of the ship ?
See scripting details page "CreateShip" effect.
LienRag wrote: Thu Oct 22, 2020 11:28 pm I'm not sure to understand the syntax of "turn high" and "not turn low", but I guess that they have the same meaning (not generating Nests on the first turn through this code) ?
The other way round. Only generating nests in turn 1. See scripting details page "Turn" condition.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
drkosy
Space Squid
Posts: 86
Joined: Sat Jul 11, 2020 9:41 am

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#19 Post by drkosy »

Between that programming details I like to report another monster related bug:
I just realized, that the siterep reporting about bombardement is wrong. As you see in the screenshots (1st is system before arrival, 2nd after) the colony "nacre beta II" was bombed and depleted but siterep reports of colony nacre beta III has been bombed.
Actually even the pop meter shows depletion of colonist although there was non.
There are even sitereps produced if no bombardement took place because planetary shield was still up. This is indeed confusing and would be great to be solved :)
Attachments
Bomardement2.png
Bomardement2.png (911.87 KiB) Viewed 173 times
Bomardement1.png
Bomardement1.png (1.19 MiB) Viewed 173 times

User avatar
Oberlus
Cosmic Dragon
Posts: 3168
Joined: Mon Apr 10, 2017 4:25 pm

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#20 Post by Oberlus »

So, in turn 119 pop is 0.15, and after being bombarded it gets pop 35.4 in turn 120?
Save files for turn 118 and 119 would come handy.

Ophiuchus
Programmer
Posts: 1808
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#21 Post by Ophiuchus »

Oberlus wrote: Wed Oct 28, 2020 1:16 am So, in turn 119 pop is 0.15, and after being bombarded it gets pop 35.4 in turn 120?
Save files for turn 118 and 119 would come handy.
0.15 is Nacre beta II

35.4 is Nacre beta III
drkosy wrote: Tue Oct 27, 2020 9:19 pm I just realized, that the siterep reporting about bombardement is wrong. As you see in the screenshots (1st is system before arrival, 2nd after) the colony "nacre beta II" was bombed and depleted but siterep reports of colony nacre beta III has been bombed.
Actually even the pop meter shows depletion of colonist although there was non.
Nacre beta II may be unrelated, maybe they just died because the planet cant sustain the george (although very unlikely).

Probably the kraken is expected to cut off supply(?) so that the planets in the system would be cut off from growth specials. As you can see the target population on nacre beta III is lower than the current population.

Looking at the script code the reported behavior is not possible. We really need the save-games for this.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
drkosy
Space Squid
Posts: 86
Joined: Sat Jul 11, 2020 9:41 am

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#22 Post by drkosy »

You find the save attached to the post.

As I quickly replayed, it went more strange than before. Aktually no siterep is produced but the pop of Nacre beta III is reduced by 1 even there are shields left on the planet...

It's a game to test my new translation of german stringtable (UI is nearly done :D ) so that could be the reason for siterep produced. (but I just translated the en.txt into german, leaving all %entry% as they were)

Pop on nacre beta II is low due to bombardment a few turns ago. The colony can survive and growth. Supply isn't cut down because there are battleships present in the system that survive battle.
Attachments
Direktor_PTMC_0119.zip
(1.08 MiB) Downloaded 3 times

User avatar
Oberlus
Cosmic Dragon
Posts: 3168
Joined: Mon Apr 10, 2017 4:25 pm

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#23 Post by Oberlus »

Bombardment works through the shields, maybe?

Code: Select all

        EffectsGroup    // monsters use graviton pulse on player planets
            scope = NumberOf number = 1 condition = And [
                InSystem id = Source.SystemID
                Planet
                OwnedBy affiliation = AnyEmpire
                Stealth high = Source.Detection
                /// @content_tag{LITHIC} Each part owned by Unowned in system will reduce population on one visible populated empire Planet with tag
                HasTag name = "LITHIC"
            ]
            activation = And [
                Unowned
                InSystem
            ]
            priority = [[EARLY_POPULATION_PRIORITY]]
            effects = [
                SetPopulation value = Value - 1
                GenerateSitRepMessage
                    message = "EFFECT_BIOWEAPON"
                    label = "EFFECT_BIOWEAPON_LABEL"
                    icon = "icons/sitrep/bio_weapon_2.png"
                    parameters = [
                        tag = "planet" data = Target.ID
                        tag = "rawtext" data = "1"
                        tag = "shippart" data = "SP_GRV"
                    ]
                    empire = Target.Owner
            ]
It will not trigger if the player's planet isn't visible by the monster, but there is no condition about shields or defense of the target planet.
Maybe that is managed in the backend?

In any case the SitRep is erroneous as drkosy points out because there was no population loss at Nacre beta II.

Ophiuchus
Programmer
Posts: 1808
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#24 Post by Ophiuchus »

drkosy wrote: Wed Oct 28, 2020 3:58 pm You find the save attached to the post.
thanks, helpful. i can recreate the issue. just the other way round. III looses one pop and the sitrep sais II should loose it.
drkosy wrote: Wed Oct 28, 2020 3:58 pm Aktually no siterep is produced
when working on stringtables you should enable the UI setting to show sitrep errors (scroll down to the end of that tab). You got an error in your sitrep (actually the german one in master is also broken) and the game just does not show anything.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
drkosy
Space Squid
Posts: 86
Joined: Sat Jul 11, 2020 9:41 am

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#25 Post by drkosy »

there is no condition about shields or defense of the target planet.
Maybe that is managed in the backend?
Hopefully there is something. Otherwise it's extremely hard to prohibit monsters from bombing you planets because they bomb at arrival. You have to kill them the turn they arrive which is hard to manage for a big kraken at early to mid game...
when working on stringtables you should enable the UI setting to show sitrep errors
Thanks for that hint :) I'll try it, maybe I can work out what's wrong.

User avatar
drkosy
Space Squid
Posts: 86
Joined: Sat Jul 11, 2020 9:41 am

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#26 Post by drkosy »

Update: The siterep is produced correctly, if there is only one planet in the system. Maybe there is just something confused by "planetary selection" (don't know how siterep production is managed).
Attachments
Bomardement3.png
Bomardement3.png (1.31 MiB) Viewed 71 times

User avatar
Oberlus
Cosmic Dragon
Posts: 3168
Joined: Mon Apr 10, 2017 4:25 pm

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#27 Post by Oberlus »

drkosy wrote: Sat Oct 31, 2020 12:52 pm Update: The siterep is produced correctly, if there is only one planet in the system. Maybe there is just something confused by "planetary selection" (don't know how siterep production is managed).
Yes, it seems it takes the first populated planet in the system, instead of the one actually bombarded.

Could you open an issue in Github with this?

Ophiuchus
Programmer
Posts: 1808
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#28 Post by Ophiuchus »

drkosy wrote: Sat Oct 31, 2020 12:52 pm Update: The siterep is produced correctly, if there is only one planet in the system. Maybe there is just something confused by "planetary selection" (don't know how siterep production is managed).
In the erroneus case both planets are valid targets for the effect. One of those should be chosen and both effects should be applied to the chosen one.
But it seems the sitrep uses the other target

edit1: possible explanation, there is a second pass for meter updates - Universe::ApplyMeterEffectsAndUpdateMeters. There the targets are recalculated calling Universe::GetEffectsAndTargets. As the NumberBla condition is choosing its target randomly, these can result in different choices.

Mitigation - use the same randomness in both passes (this can still result in different results, if the target set changed because of creating e.g. new ships)
Fix1 - dont mix meter changes with randomness
Fix2 - get rid of the second pass and solve initialisation of newly created objects/ships in a better way
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

User avatar
drkosy
Space Squid
Posts: 86
Joined: Sat Jul 11, 2020 9:41 am

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#29 Post by drkosy »

Could you open an issue in Github with this?
Recently done :) Hope there is an easy solution for this.

Edit:
edit1: possible explanation, there is a second pass for meter updates - Universe::ApplyMeterEffectsAndUpdateMeters. There the targets are recalculated calling Universe::GetEffectsAndTargets. As the NumberBla condition is choosing its target randomly, these can result in different choices.
Don't know, randomly means it should hit the affected colony by 50% chance (2 colonies availible for effect). But I never seen it be right :?: On the other side, I've seen it maybe 3 - 4 times so that's nothing if dealing with random numbers...

Ophiuchus
Programmer
Posts: 1808
Joined: Tue Sep 30, 2014 10:01 am
Location: Wall IV

Re: Some bugs and other issues (4.10+ 2020-08-17.2240ab3)

#30 Post by Ophiuchus »

drkosy wrote: Sun Nov 01, 2020 9:20 pm But I never seen it be right :?:
I saw it right
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Look, ma... four combat bouts!

Post Reply