[solved] help re one-per-empire enqueue condition

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

Moderator: Committer

Post Reply
Message
Author
Ophiuchus
Vacuum Dragon
Posts: 510
Joined: Tue Sep 30, 2014 10:01 am

[solved] help re one-per-empire enqueue condition

#1 Post by Ophiuchus » Sun Jun 04, 2017 8:20 pm

Geoff the Medio wrote:Yes, but I'd like to see a realistic example that can't be done with existing functionality... Like picking a reference object non-reproducibly, then selecting objects within some distance of the reference object as the scope, then doing something to the scope objects dependent on some property of the reference object. Or some combination of conditions in the scope that require the same other object that must be determined in a non-reproducible way.

Were such to be implemented, I'd probably have a separate reference_object = () line in the script, which is evaluated before the scope, and can be referenced in the scope condition, or within the effect scripts.
I found this thread being relevant to a coding problem I had, namely that CurrentContent was not sufficient and i had to refactor and give more context information than I think is good. The idea to "anchor" to a reference object an to refer to that one in a macro sounds like it would have solved that problem.
I wanted to write a ENQUEUE_BUILD_ONE_PER_EMPIRE which checks that a building is not enqueued somewhere else in the empire.
If there is a working alternative to CurrentContent i couldnt find it.

Check this commit diff, especially enqueue.macros - it shows how i had to add the name as a parameter

Should I open a feature request or something to allow collecting more examples?
Last edited by Ophiuchus on Fri Jun 09, 2017 8:44 am, edited 2 times in total.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4687
Joined: Sat Sep 22, 2012 6:25 pm

Re: another way to prevent stacking of shields & detectors

#2 Post by Dilvish » Sun Jun 04, 2017 9:06 pm

Ophiuchus wrote:Check this commit diff, especially enqueue.macros - it shows how i had to add the name as a parameter
That shows that you did add the name as a parameter, but I don't think it shows that you had to. From that commit it looks to me like you had previously added several new buildings, and at least from that commit it appears to me that the enqueue_macros reference to "name = ThisBuilding" should have still worked just fine for those. Could you explain a bit more about why you think it needed to be changed?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Ophiuchus
Vacuum Dragon
Posts: 510
Joined: Tue Sep 30, 2014 10:01 am

Re: another way to prevent stacking of shields & detectors

#3 Post by Ophiuchus » Sun Jun 04, 2017 10:13 pm

Dilvish wrote:
Ophiuchus wrote:Check this commit diff, especially enqueue.macros - it shows how i had to add the name as a parameter
That shows that you did add the name as a parameter, but I don't think it shows that you had to. From that commit it looks to me like you had previously added several new buildings, and at least from that commit it appears to me that the enqueue_macros reference to "name = ThisBuilding" should have still worked just fine for those. Could you explain a bit more about why you think it needed to be changed?
Well it didnt work with ThisBuilding (or CurrentContent) for the name. It seemed freeorion was ignoring the name and matching any building. So if i enqueued e.g. a shipyard, i couldnt build my ministry building (which was using the macro). I guess there could have been too much 'indirection' and CurrentContent was trying to match the planet?

Code: Select all

ENQUEUE_BUILD_ONE_PER_EMPIRE
'''Number low = 0 high = 0 condition = And [
            Planet
            Enqueued
                type = Building
                name = "@1@"
                empire = Source.Owner
                low = 1
        ]'''
used by

Code: Select all

ENQUEUELOCATION_GOVERNMENT_SEAT
'''And [
        // On one of your planets
        Planet
        OwnedBy empire = Source.Owner

        // must have a non-trivial population
        TargetPopulation low = 1

        // can't enqueue if this building is enqueued anywhere
        [[ENQUEUE_BUILD_ONE_PER_EMPIRE(BLD_IMPERIAL_GOVERNMENT_SEAT_@1@)]]
    ]'''
used by

Code: Select all

BuildingType
    name = "BLD_IMPERIAL_GOVERNMENT_SEAT_NEGOTIATOR"
    description = "BLD_IMPERIAL_GOVERNMENT_SEAT_NEGOTIATOR_DESC"
    captureresult = destroy
    buildcost = 1
    buildtime = 1
    tags = [ "GOVERNMENT_FUNCTION_FOREIGN" ]
    location = And [
        Planet
        OwnedBy empire = Source.Owner
        TargetPopulation low = 1
        [[CONDITION_GOVERNMENT_TYPE_IS(WARLORD)]]
        [[CONDITION_NO_SUCH_GOVERNMENT_SEAT_EXISTS(NEGOTIATOR)]]
    ]
    enqueuelocation = [[ENQUEUELOCATION_GOVERNMENT_SEAT(NEGOTIATOR)]]
    effectsgroups = [
        [[EFFECT_GROUPS_GOVERNMENT_FUNCTION_FOREIGN]]
    ]
    icon = "icons/building/shield.png"
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4687
Joined: Sat Sep 22, 2012 6:25 pm

Re: another way to prevent stacking of shields & detectors

#4 Post by Dilvish » Sun Jun 04, 2017 11:01 pm

Ophiuchus wrote:Well it didnt work with ThisBuilding (or CurrentContent) for the name. It seemed freeorion was ignoring the name and matching any building. So if i enqueued e.g. a shipyard, i couldnt build my ministry building (which was using the macro). I guess there could have been too much 'indirection' and CurrentContent was trying to match the planet?
ThisBuilding is just a synonym for CurrentContent, and both of them should always just match the name of the piece of content being scripted, nothing to do with any LocalCandidates or RootCandadate matches.

To get a readout of what part of your condition is really blocking things, I'd suggest that you put your desired EnqueueCondition in place of the normal "Location" condition. Then you can get an ingame tooltip from the build list (be sure to display Unavailable) that explains which parts of the condition are met or not at the desired planet. If that doesn't make it clear to you, then please post a screenshot of that tooltip.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Ophiuchus
Vacuum Dragon
Posts: 510
Joined: Tue Sep 30, 2014 10:01 am

Re: another way to prevent stacking of shields & detectors

#5 Post by Ophiuchus » Mon Jun 05, 2017 12:04 am

Dilvish wrote:
Ophiuchus wrote:Well it didnt work with ThisBuilding (or CurrentContent) for the name. It seemed freeorion was ignoring the name and matching any building. So if i enqueued e.g. a shipyard, i couldnt build my ministry building (which was using the macro). I guess there could have been too much 'indirection' and CurrentContent was trying to match the planet?
ThisBuilding is just a synonym for CurrentContent, and both of them should always just match the name of the piece of content being scripted, nothing to do with any LocalCandidates or RootCandadate matches.
How is "the piece of content being scripted" defined?
Dilvish wrote:To get a readout of what part of your condition is really blocking things, I'd suggest that you put your desired EnqueueCondition in place of the normal "Location" condition. Then you can get an ingame tooltip from the build list (be sure to display Unavailable) that explains which parts of the condition are met or not at the desired planet. If that doesn't make it clear to you, then please post a screenshot of that tooltip.
I think i got the enqueue tooltip when double clicking on it. Anyway, did as you said. Same behavior as before if anything else is in the productioin queue; Screenshot attached .
Attachments
unnamed_buildings.png
Cant enqueue when any building is enqueued
unnamed_buildings.png (168.8 KiB) Viewed 315 times
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4687
Joined: Sat Sep 22, 2012 6:25 pm

Re: help re one-per-empire enqueue condition

#6 Post by Dilvish » Mon Jun 05, 2017 2:07 am

This is getting to be a fairly involved debugging discussion, rather distinct from the old thread, so I've split these recent posts off.
How is "the piece of content being scripted" defined?
In general it's the name of the tech, building, part, whatever top level piece of content the script is for. It turns out, however, that there was a bug with the Number condition, which was causing it to not propagate this name to its contained condition, and so the subsidiary Enqueued condition in your script wasn't getting that info (it would have appeared between the "2147483647" and "buildings" in that tooltip). I've put in a commit to fix that, will be in the next weekly build on Tuesday or so. Also, to facilitate debugging things like this, I augmented the autogenerated descriptions for BuildingTypes so that if the auto-generated descriptions option is active (accessible via options->UI at bottom) then the Pedia entry will include the Enqueue requirement description (and will also more clearly identify the respective autogenerated descriptions).

With that in place, a form of your script above, using CurrentContent, worked fine for me. That is the preferable approach, so that the ENQUEUE_BUILD_ONE_PER_EMPIRE macro could be used for either buildings or ships.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Ophiuchus
Vacuum Dragon
Posts: 510
Joined: Tue Sep 30, 2014 10:01 am

Re: help re one-per-empire enqueue condition

#7 Post by Ophiuchus » Mon Jun 05, 2017 10:08 am

Dilvish wrote:With that in place, a form of your script above, using CurrentContent, worked fine for me. That is the preferable approach, so that the ENQUEUE_BUILD_ONE_PER_EMPIRE macro could be used for either buildings or ships.
Thank you for the bugfix and the explanations. CurrentContent now works fine :)
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Post Reply