Page 1 of 1
Problems and inconsistences in lua api docs
Posted: Tue Oct 29, 2024 2:49 am
by GlassBricks
Hi Bilka & co, it's me again!
This has now evolved into a random list of things I've noticed are inconsistent or problematic in the lua-api docs.
Title has been updated to latest version where all these issues are still confirmed.
The following concepts don't seem to be referenced anywhere else:
- VirtualSignalId
- LogisticSections, LogisticSection, BlueprintLogisticFilter
- BurnerUsageID
- CircuitNetworkSelection Currently an completely empty table??
- RaiseEventParameters
Yes, I do have a thing doing DFS/floodfill shenanigans over things in the api docs json. The above are some unconnected components.
Re: [2.0.12] Unused (?) concepts in runtime docs
Posted: Tue Oct 29, 2024 2:57 am
by GlassBricks
More:
defines.default_icon_size is empty and unused
In SoundPath's description, the last 2 "notes" have been removed. Compare with docs for v1.1.110
In FluidIdentification, ForceIdentification, TechnologyIdentification, "Identification" has been shortened to "ID", but not for SurfaceIdentification and PlayerIdentification.
In LuaGuiElement::elem_value, ItemIdAndQualityPair can replace the generic "table" type.
Re: [2.0.12] Unused (?) concepts in runtime docs, and other inconsistencies
Posted: Wed Oct 30, 2024 1:18 am
by GlassBricks
LuaPostEntityDiedEventFilter::type is specified to only be "ghost", but the variant parameter imply that type can also be `"type"`.
Re: [2.0.12] Unused (?) concepts in runtime docs, and other inconsistencies
Posted: Wed Nov 06, 2024 12:42 am
by GlassBricks
[2.0.15] PipeConnectionDefinition::linked_connection_id has type uint32. But uint32 doesn't exist, it should be just uint
Re: [2.0.12] Unused (?) concepts in runtime docs, and other inconsistencies
Posted: Thu Nov 14, 2024 1:23 am
by GlassBricks
[2.0.17] LuaControl set_driving takes parameters of type "bool", they should be "boolean"?
There's also a typo in that method's description. Spell checker?
Re: [2.0.12] Unused (?) concepts in runtime docs, and other inconsistencies
Posted: Fri Nov 22, 2024 5:33 am
by GlassBricks
`SpacingItem` has fields with types `uint32_t` `int32_t`... did you mean uint/int?
Re: [2.0.12] Unused (?) concepts in runtime docs, and other inconsistencies
Posted: Fri Nov 22, 2024 5:34 am
by GlassBricks
TechnologySlotStyleSpecification::drag_handle_style references EmptyWidgetStyle, which does not exist.
Re: [2.0.21] Problems and inconsistences in lua api docs
Posted: Sat Dec 07, 2024 5:23 pm
by GlassBricks
[2.0.24]
TriggerEffect has "DamageEntityTriggerEffectItem" as a union member, but that type no longer exists (did you mean "DamagerTriggerEffectItem")?
Re: [2.0.21] Problems and inconsistences in lua api docs
Posted: Thu Mar 06, 2025 12:16 am
by GlassBricks
[2.0.39] the newly LuaSchedule::get_records, set_records, and clear_records have parameters of type "uint: interrupt_index" instead of "interrupt_index: uint".
...have you considered making a compiler to check for type errors? I guess I accidentally have
Re: Problems and inconsistences in lua api docs
Posted: Thu Mar 06, 2025 4:08 pm
by Bilka
GlassBricks wrote: Thu Mar 06, 2025 12:16 am
...have you considered making a compiler to check for type errors? I guess I accidentally have
It errors, that's how a bunch of things you mentioned here got found and fixed independently.
Re: Problems and inconsistences in lua api docs
Posted: Tue May 06, 2025 9:12 am
by Therenas
Had a look at all these and they should be fixed for the next release, with these notes for you:
GlassBricks wrote:defines.default_icon_size is empty and unused
-> 'defines.default_icon_size' is weirdly defined and breaks the docs format currently. Looking at a fix at some point.
GlassBricks wrote:In FluidIdentification, ForceIdentification, TechnologyIdentification, "Identification" has been shortened to "ID", but not for SurfaceIdentification and PlayerIdentification.
-> This just mirrors the internal names, so not an inconsistency per se.
GlassBricks wrote:LuaPostEntityDiedEventFilter::type is specified to only be "ghost", but the variant parameter imply that type can also be `"type"`.
-> Wrote this one down to have a look at.
Thanks a lot for the detailed notes and findings btw! Let me know if you run into any others after the next release.
(I'll be moving this to resolved since the remaining issues have been noted on our internal tracking board, no need to have it in two places.)