migrate all caravan data into mod-data

[FreezingSnail]

Dirty but working atm

Example of 3rd party mod code to add caravan:
user would need to create a prototype def according to how it is in AL
(need the item, recipe entity also )

for k,v in pairs(prototypes) do
    data.raw["mod-data"]["pyanadons"].data["caravan_prototypes"][k] = v
end
table.merge(data.raw["mod-data"]["pyanadons"].data["caravan_data"].foods, food)

Still need to deal with the fluidvan name regex matches for the gui builders

[PennyJim]

Because ModData felt simple enough to judge the merits of, I decided to take a glance at it.

Besides side notes I have about how things are done that I can't be confident in with my lack of experience with pY code. I mostly think there NEEDS to be data validation on what mods try and pass through the ModData.

People will make mistakes in their code. You want to catch it as early as you can so it can't lie in wait until the worst moment to cause a crash or god forbid silently corrupt the contents of storage until its too late.

[PennyJim]

prototypes is available in "main chunk" of runtime
This means instead of replacing every instance of the object caravan_prototypes with a function call
You can just instead have the old file that returns caravan_prototypes do this

return prototypes.mod_data["pyanadons"].data["caravan_prototypes"]

But rather than passing it directly, I'd dedicate that file to data integrity checking
You can trust internal stuff to be right, and it's your fault if you're wrong
But you CANNOT trust outside sources.

[PennyJim]

Based on the removed section over here:
https://github.com/pyanodon/pyalienlife/pull/597/changes#diff-0e0ac10ae6e1c14e8d1978c87135ef30db3fe5a90b485d8a9a35c20a3c871eb6L385-L394

This seems like not your fault. Regardless, this looks incredibly wrong to me

Tables are passed by reference, so when you're modifying caravan_prototypes["caravan-turd"] you should also be modifying caravan_prototypes["caravan"]
You'll want to wrap the initial assignments with something like util.copy

caravan_prototypes["caravan-turd"]   = util.copy(caravan_prototypes["caravan"])
caravan_prototypes["fluidavan-turd"] = util.copy(caravan_prototypes["fluidavan"])
caravan_prototypes["flyavan-turd"]   = util.copy(caravan_prototypes["flyavan"])
caravan_prototypes["nukavan-turd"]   = util.copy(caravan_prototypes["nukavan"])
caravan_prototypes["fluidflyavan-turd"]   = util.copy(caravan_prototypes["fluidflyavan"])

[PennyJim]

Take this comment as someone who hasn't seen any of the actual functional code.
But this looks like it should be static to me. Something listed as all_actions looks like a source of truth, rather than something meant to be modified.

I mean this as in it probably shouldn't be within the ModData, and instead just next to where the mod data is fetched in runtime.
Someone more knowledgeable about this system can confirm or deny this

[PennyJim]

This looks like debug code to me. While I don't know the consensus of the community on debug code making it into the repository, I'd personally always wrap it in a debugger check to prevent it from ever accidentally spamming users.

if debugadapter then
	-- Debug code
end

But what really caught my eye about this, is the fact that you do

local prototype = Utils.Get_caravan_prototypes()[entity.name]
local protos = Utils.Get_caravan_prototypes()

Seeing a local of protos made right after the same thing was fetch made me sweat before I realized it part of the debug code and likely to be ripped out anyways.

[PennyJim]

Why is the function capitalized? The other functions in utils aren't.

[protocol-1903]

I'll be writing up a mod-data package to the standards and specifications of the rest of the codebase. Thank you for your efforts, but please wait for an official implementation.