Fix invalid default values for InputBoolean objects in IOP

[Copilot]

All four InputBoolean objects in AOG_TC.iop had a default value of 24 (0x18) instead of a valid boolean 0 or 1. This is likely a font-size attribute that was incorrectly written into the value field by the IOP authoring tool.

Changes

• resources/AOG_TC.iop — patched the value byte at the confirmed binary offset for each of the four affected objects:

ID	Name	Before	After
10001	ConfigHydliftAuxN	24	0
10002	ConfigNmeaRead	24	0
10003	ConfigNmeaSend	24	1
10004	ConfigTecuEnabled	24	1

ConfigNmeaSend and ConfigTecuEnabled default to 1 to match DEFAULT_NMEA_SEND_ENABLED = true and DEFAULT_TECU_ENABLED = true in settings.hpp. The other two default to 0 as they are not yet implemented (inputs are disabled).

[sujandumaru]

Good finding. The .iop is still new and will likely need more changes, so I'd like to put a guard in TC to test the basic properties of the iop objects in TC itself rather than catching this on hardware again.

Worth noting AgIsoStack does report this. It goes to Failed and logs the faulty object ID from the End of Object Pool response. I checked get_is_valid() against the broken pool and it returns 0 failures, since value=24 is structurally valid and only semantically illegal for a boolean.

Let me work on a small CI validator, before approving this, that will range-checks attributes against their ISO limits and some other basic properties that fails with current iop file and passes after merging your change. Would be helpful in future as well if we decide to make some changes on .iop file.

[gunicsba]

Yes ideally there should be a check in CI that would return the validity of the iop files. It's not just for TC but any project that includes iop like ECUs or even the agisostack examples.
So that's why I created a ticket on the library itself as well.