RulesAttachment vs TriggerAttachment

redrum

So it appears rules and trigger attachments share a lot of properties and functionality. POS2 XML specifies that objectives should use RulesAttachment and the name should start with "objectiveAttachment". But it appears that in many cases objectives actually use TriggerAttachment and that objectives.properties can reference these. An example I noticed is in the Global 40 XML where it has this for some German objectives:

    <attachment name="triggerAttachment_Germans_4_Presence_In_Egypt" attachTo="Germans" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
      <option name="trigger" value="conditionAttachment_Germans_4_unit_presence"/>
      <option name="resource" value="PUs"/>
      <option name="resourceCount" value="5"/>
    </attachment>
    <attachment name="triggerAttachment_Germans_5_Swedish_Iron_Ore" attachTo="Germans" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
      <option name="trigger" value="conditionAttachment_Germans_5_Control_Norway_And_Denmark:conditionAttachment_Germans_5_Sweden_Not_Enemy"/>
      <option name="conditionType" value="AND"/>
      <option name="resource" value="PUs"/>
      <option name="resourceCount" value="5"/>
    </attachment>

Any idea why this is? Couldn't these be done with objectiveAttachment?

Cernel

@redrum Anything that can be done with objectives can be done with triggers, but not vice versa. So, yes, those could be done with objectives, but then they would depend on the property that can switch objectives on or off, so I think doing all with triggers is preferable, if they are more core to the game, since objectives support only a few things (if you use triggers to give units, as objectives cannot, then it makes the only sense to still use triggers to give resources).
You can also notice the obsolete option name "trigger"; that is actually a "conditions"; backward compatibility relic there.
Personally, I would use triggers, instead of objectives, in all cases, except if the objectives are something of an add on to be switched on or off, like v3. I see objectives only as something marginal with very limited functionality, adding nothing to what you can do with triggers and conditions.

redrum

@cernel Yeah, that's my understanding as well. Though I would think since those particular triggers deal with objectives and the rest of the objectives in the map use objectiveAttachments that they should as well. That way if you did want to switch objectives on/off you could. Otherwise I would agree that just using all trigger attachments would make more sense.

Cernel

@redrum Only Veqryn could really tell, but, to be clear, I think that objectives are like the simple support options and triggers are like the complete support attachments.