Excruciating FOCS doubts

Creation, discussion, and balancing of game content such as techs, buildings, ship parts.

Moderators: Oberlus, Committer

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

Re: Excruciating FOCS doubts

#196 Post by Oberlus »

Daybreak wrote: Tue Aug 09, 2022 1:30 am Can you publish what you do have now, and update as you go?
Sure, during August I hope.
Right now I only have a table of all the policies with data and and an abstract index for how fast it can be adopted, so not really interesting to publish.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Excruciating FOCS doubts

#197 Post by Geoff the Medio »

wobbly wrote: Mon Aug 01, 2022 8:53 amThe pedia is full of these values. Some are correct for 4 round combat and weapon/shield scaling. Some are the old values from before 4 round combat and weapon/shield scaling. Some are namedvalues and auto-update if values are changed. Some are not namedvalues and don't update if values change. The ones with named values show correct values when you change the starting options. The ones without named values don't show correct values when you change starting options.

I would like to update these entries and I'm looking for the best way to handle it. Ideally I'd like to change 5 to 5 * Game Rule so that the pedia shows correct value for current game settings.
wobbly wrote: Mon Aug 01, 2022 9:19 amSimplest solution is I make sure that every value is correct for default settings, before release, and the bigger issue is sorted out later.
Having things be named values that auto-update would be best. Next better would be correct for default settings hard-coded. I guess just do as best as as you have time and motivation for...

Daybreak
Vacuum Dragon
Posts: 641
Joined: Mon Aug 13, 2018 10:14 pm

Re: Excruciating FOCS doubts

#198 Post by Daybreak »

Oberlus wrote: Tue Aug 09, 2022 8:29 am
Daybreak wrote: Tue Aug 09, 2022 1:30 am Can you publish what you do have now, and update as you go?
Sure, during August I hope.
Right now I only have a table of all the policies with data and and an abstract index for how fast it can be adopted, so not really interesting to publish.
Minimum to you may not be minimum to us.

If you publish as soon as possible, others may contribute, which will help you finish it quicker.

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

Re: Excruciating FOCS doubts

#199 Post by Ophiuchus »

Geoff the Medio wrote: Tue Aug 09, 2022 1:42 pm
wobbly wrote: Mon Aug 01, 2022 8:53 amThe pedia is full of these values. Some are correct for 4 round combat and weapon/shield scaling. Some are the old values from before 4 round combat and weapon/shield scaling. Some are namedvalues and auto-update if values are changed. Some are not namedvalues and don't update if values change. The ones with named values show correct values when you change the starting options. The ones without named values don't show correct values when you change starting options.

I would like to update these entries and I'm looking for the best way to handle it. Ideally I'd like to change 5 to 5 * Game Rule so that the pedia shows correct value for current game settings.
wobbly wrote: Mon Aug 01, 2022 9:19 amSimplest solution is I make sure that every value is correct for default settings, before release, and the bigger issue is sorted out later.
Having things be named values that auto-update would be best. Next better would be correct for default settings hard-coded. I guess just do as best as as you have time and motivation for...
One thing which could work with medium effort is introducing a value ref for querying properties of specifications (e.g. "Capacity" for a "ShipPart" specification) and using a macro for applying adjustments if necessary (e.g. scaling).

edit1: Actually in order to not have to define myriads of named values there needs to be a way to pass parameters to it e.g. the current ship part name. So the previous suggestion probably does not work. Instead the pedia page for ship parts could add a ship part object to the context as source. then one could use a named value like "Capacity" which simply returns the Source.Capacity; for structure maybe that would be "Structure" which returns the scaled structure (to simulate the default effects without actually applying them).
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
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Excruciating FOCS doubts

#200 Post by Geoff the Medio »

Ophiuchus wrote: Wed Aug 10, 2022 10:53 ama value ref for querying properties of specifications (e.g. "Capacity" for a "ShipPart" specification)
Like https://github.com/freeorion/freeorion/ ... .cpp#L2267 ?
there needs to be a way to pass parameters to it e.g. the current ship part name.
That's what ComplexVariable is for.

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

Re: Excruciating FOCS doubts

#201 Post by Ophiuchus »

Geoff the Medio wrote: Wed Aug 10, 2022 12:13 pm
Ophiuchus wrote: Wed Aug 10, 2022 10:53 ama value ref for querying properties of specifications (e.g. "Capacity" for a "ShipPart" specification)
Like https://github.com/freeorion/freeorion/ ... .cpp#L2267 ?
there needs to be a way to pass parameters to it e.g. the current ship part name.
That's what ComplexVariable is for.
the problem is that i do not want to do a named value ref per part*property, I want/need to set the parameter from pedia/stringtables.
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
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Excruciating FOCS doubts

#202 Post by Geoff the Medio »

When generating pedia descriptions for parts and most other content, several values are substited into the stringtable entry to replace %1%, %2%, etc. For direct weapons, in RefreshDetailPanelShipPartTag(...), those are the capacity and secondary stat. The capacity is determined by the part's capacity stat and then scaled by the ship structure factor rule in ShipPart::Capacity. If there's some non-standard calculation done for a part's capacity, then that won't necessarily give the right values, though.

User avatar
LienRag
Cosmic Dragon
Posts: 2146
Joined: Fri May 17, 2019 5:03 pm

Re: Excruciating FOCS doubts

#203 Post by LienRag »

Ophiuchus wrote: Mon Dec 27, 2021 10:47 am
you can point the game to a "default" folder somewhere. So, you could get the game via snap and manage the FOCS files in parallel using git

(...)

git will merge the changes, you simply have to pull in the latest master. learn git, its good (and a great skill to have)
I'm learning the basics of git, thanks for the advice.
But I still don't really understand the suggested workflow : just Git init on a random folder in my /home and then git import from the snap folder and letting git merge files ?
But it won't be able to modify the files inside the snap folder ?
Or do I use my folder as the reference for the game ?
Then how do I merge the files when I get a new snap version ?
I copy the new snap version FOCS file in the "buffer" folder and just merge the files from the buffer into my working branch, and if I get "conflict" I solve it manually ?

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

Re: Excruciating FOCS doubts

#204 Post by Ophiuchus »

LienRag wrote: Sun Aug 21, 2022 11:06 pm
Ophiuchus wrote: Mon Dec 27, 2021 10:47 am
you can point the game to a "default" folder somewhere. So, you could get the game via snap and manage the FOCS files in parallel using git

(...)

git will merge the changes, you simply have to pull in the latest master. learn git, its good (and a great skill to have)
I'm learning the basics of git, thanks for the advice.
But I still don't really understand the suggested workflow : just Git init on a random folder in my /home and then git import from the snap folder and letting git merge files ?
But it won't be able to modify the files inside the snap folder ?
Or do I use my folder as the reference for the game ?
Then how do I merge the files when I get a new snap version ?
I copy the new snap version FOCS file in the "buffer" folder and just merge the files from the buffer into my working branch, and if I get "conflict" I solve it manually ?
i see a lot of confusion. i try to clear that up if i can.

you do somewhere a

Code: Select all

git clone https://github.com/freeorion/freeorion.git
to set up a local git workspace. There is also the default folder in there. Start your freeorion via snap and you should be able to set the default folder in the workspace for ressources - if you cant see it in the file dialog this is because of the snap container. If this is so, please write, I will help further. You do your changes in your workspace default folder, if you set up your snap freeorion correctly running a game will load the content, stringtables etc from there and you should be able to see your changes (without having to build freeorion locally).

In order to bring the changes back you need an account on github. First you should add and commit your changes (in your local git workspace). You also need fork to the https://github.com/freeorion/freeorion repository (on github). Then you need to configure a remote to point to that fork (in your local git workspace). Then you can push your commits your repository on github (git push in your local git workspace). If you are happy with your commits, you can start a PR (on github). And then it goes to the feedback loop until someone merges your changes.

If master has changes you can

Code: Select all

git rebase -i origin/master
to get those changes (which pulls the changes into your workspace AND rewrites git history). If you are unsure in the beginning though, you probably should do

Code: Select all

git pull
instead (which does not rewrite git history). If you start with git rebase, I advise you to do a local backup of your default folder first. There are ways to handle complications with rebase, but those need some experience.
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
Oberlus
Cosmic Dragon
Posts: 5713
Joined: Mon Apr 10, 2017 4:25 pm

Re: Excruciating FOCS doubts

#205 Post by Oberlus »

Addendum:

Assuming you configured upstream to be freeorion's github, and origin to be your freeorion repository in your personal github account.

Before making changes in your workspace:

Code: Select all

git checkout upstream master
git pull upstream master
Now you are at freeorion's master, up to date.

Code: Select all

git checkout -b <new_branch_for_your_changes>
Now you are in that new branch, that is also a copy of up to date freeorion's master.
Edit files, test stuff, refine changes, until you are satisfied.
If you created new files, do:

Code: Select all

git add <path_to_new_file>
Then commit all the changes:

Code: Select all

git commit -a -m "<commit message>"
The "-a" means committing all uncommitted, modified files. You can specify each changed file independently for detailed commit messages.

To publish your changes in your github account and also allowing freeorion to get a PR with your changes:

Code: Select all

git push origin <new_branch_for_your_changes>
It will ask user name and password of your github account.

User avatar
LienRag
Cosmic Dragon
Posts: 2146
Joined: Fri May 17, 2019 5:03 pm

Re: Excruciating FOCS doubts

#206 Post by LienRag »

Ophiuchus wrote: Mon Aug 22, 2022 11:12 amStart your freeorion via snap and you should be able to set the default folder in the workspace for ressources - if you cant see it in the file dialog this is because of the snap container. If this is so, please write, I will help further.
I used to be able to, but now I am not.
When I move up the filesystem, once I reach /snap/freeorion_slowgame, trying to move up one level closes the filesystem window and brings back the default location for the resources.


Oberlus wrote: Mon Aug 22, 2022 12:11 pm Assuming you configured upstream to be freeorion's github, and origin to be your freeorion repository in your personal github account.
Since I am in favor of free software, I do not use Github.
Per your recommendation, I copied the Github repo to Codeberg (on my personal account there).

Do you advise to keep the Codeberg repo a pure copy of the Github one (so, to create a second and personal repository on the same Codeberg account) or to directly use the Codeberg repo as my own private repository for my modifications ?

Also, in both yours and Ophiuchus commands, I don't really understand which ones are going to erase the modifications I made and which ones are safe to use ?

Or should I indeed keep my repository's master synchronized to the Github repository and make my modifications only to the "lienrag" branch ?
In that case, how do I direct the default folder for resources specifically to my "lienrag" branch ?

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

Re: Excruciating FOCS doubts

#207 Post by Ophiuchus »

LienRag wrote: Tue Aug 23, 2022 10:19 pm When I move up the filesystem, once I reach /snap/freeorion_slowgame, trying to move up one level closes the filesystem window and brings back the default location for the resources.
put your default folder in your home directory somewhere, the snap has access to unhidden stuff (i.e. name not starting with .*) in the home folder by default. if it is not listed in your home directory, please give the output of

Code: Select all

snap connections freeorion_slowgame
LienRag wrote: Tue Aug 23, 2022 10:19 pm Also, in both yours and Ophiuchus commands, I don't really understand which ones are going to erase the modifications I made and which ones are safe to use ?
if you do use add and commit and not rebase, all your changes should be recoverable if they "vanish". (even with rebase it is possible, just a bit more involved).
as long as you do not run into conflicts (i.e. somebody changed the same line of code like you in master) updating is smooth sailing.

LienRag wrote: Tue Aug 23, 2022 10:19 pm In that case, how do I direct the default folder for resources specifically to my "lienrag" branch ?
it does not matter what your local branch is called. in a workspace, only one branch is checked out at a time. that one has to be the right one.
LienRag wrote: Tue Aug 23, 2022 10:19 pm Do you advise to keep the Codeberg repo ...<stuff i did not understand>...
using github is necessary for doing a pull request AFAIK and the review loop as well. using another online git service gives you the usual benefits (backup copy, internet hosting), but is not essentially necessary (your local git workspace works as well).
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
Oberlus
Cosmic Dragon
Posts: 5713
Joined: Mon Apr 10, 2017 4:25 pm

Re: Excruciating FOCS doubts

#208 Post by Oberlus »

As per FOCS documentation, an effect applies to Target, which is defined as the set of objects defined by scope's condition that fulfill the activation condition.

When we find this attached to an species:

Code: Select all

scope = Source
activation = Planet
effects = ...
the scope gathers all objects in the galaxy with the species that had the effect attached, and the activation filter out anything that is not a planet (so ships with that species are filtered out).
This type of scripting is everywhere in the FOCS files: scope is Source, and activation is the actual filtering of valid targets, with the effect always triggering for those targets.

I wonder if it is OK to script it so that scope directly selects the valid targets, and activation is always:

Code: Select all

scope = And [
    Source
    Planet
]
effects = ...

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

Re: Excruciating FOCS doubts

#209 Post by Oberlus »

Related to the above doubt, I'm trying to do something with the Xenophobic trait, and I am wondering...

If it's better to have scope = Source when the Targets are going to be (part of) Source, the XENOPHOBIC_OTHER effect (the malus to non-xenophobic species that are nearby xenophobic species) applies to targets that are not Source. This effect could be attached to all species and then use scope = Source as well for it.

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

Re: Excruciating FOCS doubts

#210 Post by Ophiuchus »

Oberlus wrote: Wed Aug 31, 2022 7:55 am I wonder if it is OK to script it so that scope directly selects the valid targets, and activation is always:

Code: Select all

scope = And [
    Source
    Planet
]
effects = ...
i guess technically this would work and have the same game effect - i very guess that this even does not change computation cost (although geoff better comment on that)

buuut.. conceptionally.. and maybe logging-wise.... putting the filtering in the activation means the effect is not triggered. putting the filtering in the scope means the effect is triggered and then finds out it there is actually no object in the universe eligible for the effect.

I prefer to filter in activation and do the trivial object picking in the Scope.

What is the purpose of your suggestion? Getting rid of the activation condition?
Oberlus wrote: Wed Aug 31, 2022 8:30 am Related to the above doubt, I'm trying to do something with the Xenophobic trait, and I am wondering...

If it's better to have scope = Source when the Targets are going to be (part of) Source, the XENOPHOBIC_OTHER effect (the malus to non-xenophobic species that are nearby xenophobic species) applies to targets that are not Source. This effect could be attached to all species and then use scope = Source as well for it.
Conceptually it depends if the trait is part of the xenophobic species or if it is part of the other species. I think about the xenophobic effect on others coming from the xenophobic species (because basically all species are the object and only the xenophobic ones are the subject), so I would expect the effect to be defined on the xenophobic side.
If there were multiple types of harassment and xenophobic only of those, and there were differences how those are applied to species (e.g. GOOD_HARASSMENT_RESILIENCE), i would expect code in the other species for that.

So the objectively true answer for what is better is the usual one in programming: it depends

In this case having both the xenophobic and xenophobic_other effects in the definition of the xenophobic species is fine (and the other option does not seem to be better in a meaningful 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!

Post Reply