New `global` agent - [merged]

[benloh]

Merges dev-bl/global -> dev-next

In trying to implement support for global properties in the wizard UI, it quickly became clear that the most efficient way to support global properties was to make the global agent a blueprint that can be edited like any other blueprint. Any other solutions involved torturous workarounds.

What this involves:

• There is now a global blueprint that is automatically added to every project. If a project is missing the global blueprint, it will be added when it is opened and saved.
  • By default, the global agent has no properties beyond a normal agent properties. For the most part agent properties will be ignored. However, the visible property is set to false to so that the global agent does not appear on the screen.
  • By default, the global agent has a Population feature enabled. (We can revisit this to see if it's necessary).
• By default, a single global agent instance is created just before the project instances are instantiated. e.g. if you have a single Fish instance, the global agent is created, then the single Fish instance is created when the project loads or is reset.
  • Although I'm not sure why you would want to, when the global agent is instantiated, it will run the initScript for the global agent (though currently there is no UI for you to access that).
• The Global feature has now been removed. It is no longer necessary to use it to create and access global properties.
• To add a new global property, just edit the global blueprint as you would any other blueprint, and add an addProp line.
• As before, global properties can be accessed by any blueprint using global as the blueprint name, e.g. inside Fish, you can use prop global.energyReleasedAsHeat add 5
• You can also access global features using featProp global.Population... and featCall global.Population...
• You can always ignore the global agent if you do not need it. You do not need to do anything with it.

Conversion

In general, here's what you need to do for any project that is currently using the Global feature.

1. Open the project and a new global agent will be added.
2. Remove addFeature Global
3. Convert any featCall Global.addGlobalProp xxx calls to a new addProp xxx in the global agent.
4. Convert any featCall Global.globalProp xxx calls to a prop global.xxx in the current agent.
5. Convert any featCall Global.getGlobalProp xxx calls to a prop global.xxx in the current agent.

Example from decomposition_energy

See art-assets repo, branch global-fix, file decomposition_energy.gemprj for an example of how to do the conversion from use of the Global Feature to using the global agent.

# BLUEPRINT global
addFeature Population
addProp energyReleasedAsHeat number 0

# BLUEPRINT EnergyRepresentation
...
when EnergyRepresentation centerFirstTouches Plant [[
  ...
  // if you have energy from the sun, then give some energy to the plant, but not all of it because some is released into the environment
  // as heat or lost in other ways
  ifExpr {{ EnergyRepresentation.getProp('energyType').value == 'source' }} [[
    ...
    prop Plant.energyLevel add 50
    // we are losing 50 of the hundred, so note that in the global
    // GLOBAL FIX -- ORIG LINE: featCall Global globalProp energyReleasedAsHeat add 50
    prop global.energyReleasedAsHeat add 50
    ...

[benloh]

requested review from @jdanish

[benloh]

marked this merge request as ready

[benloh]

@jdanish I don't think anyone's using this at the moment, but if for some reason a blueprint needs to access the Round's roundTime property, we can implement the round REFEREE_AGENT the same way that we're implementing global. (roundTime used to be in the global agent, but has been moved to a separate REFEREE_AGENT that manages rounds)

[benloh]

added 1 commit

• 475af654 - global: Use `global.visible` so UI displays visibility as valid.

Compare with previous version

[benloh]

In GitLab by @jdanish on Sep 11, 2022, 06:14

I don't actually recall what roundTime was - is that just the count within the round? In which case we can fake it with a global property of some sort? In which case I think we are fine.

[benloh]

In GitLab by @jdanish on Sep 11, 2022, 06:14

This appears to work, by the way - so I am OK with a merge if you are.

[benloh]

mentioned in commit ec608916fb8d53040db10e52086b4b4956edf7cd