It is my try even if you say no to at least ask you if you want to make a cross compat with IC2C.

I do not mean Crops itself should be compatible to each other.
But what about that you can use Agricraft Seeds on IC2 Crops & IC2 Seeds on Agricraft.
Edit: For 1.9.x in this case

Just tell me what you think about that.

Edit 2: Sry if that comes rude over just a bit tiered.

well @RlonRyan InfinityRaider told me i should now talk to you about this.

I would certainly want to cooperate with this. Right now agricraft is being rewritten for 1.9 so this will have to wait a bit.
I will leave this open and ping you once AgriCraft is in a suitable condition for 1.9.

I certainly want to add compat. I don't think making the seeds plantable on crop sticks will be hard, on the contrary.
The thoughest will be handling the stats and mutation logic. IC2's crop mutation mechanic is a lot different than agricraft's. AgriCraft had the possibility to completely override the mutation logic in 1.7, which will certainly be ported to 1.9.
Another option, instead of overriding mutation mechanics is to have a 1 <-> 1 bijective relation between agricraft and IC2 stats (which is I think not possible/very hard)

1: No that should no longer be hard. Since i was able to push to the api a CropSeedItem so there is no longer a force of the IC2 Item there... (That had to be gone for a while)
2: Mutation only on Crops that do not exist on the other side. Else you just can takeover the mutations from that mod. I personally want to let the free mutation system inside of classic (Nothing against your system). But stats you could be right...
3: well do you want to expand the max growth speed and co to 31?
I had a idea that agricraft stats would go to 1-1 but if you convert back (only on backconverting) you could go higher then 10... Just a idea... To save the balance on your side if someone only uses agricraft that they do not get to high stats so easy (Only a idea)

Also just one thing to point out. Classic has a second fertilizer (also in 1.7.10) which allows you to breed a lot faster. But it has some downsides. The cropstick looses its tickability after you used it and the effect is over and i think in 1.9 i will go even further that you only can get seeds back and not get the actual drops when the effect is applied... Still thinking about that. (Little note when applied the special fertilizer IC2 Crops run 256x faster)

Also just some progress on my side what features are new:
You can detect now what farmland the CropStick is placed on. (So you can register custom Farmlands)
And some other stuff... I think i should push to you soon the API (which is still unreleased)

I think I have an idea for the seed stats. Instead of using the fixed class now, I could abstract it into an interface. Then the handling of calculations for the growth rates etc can be moved to said interface. This would allow to push the maximum number beyond 10, but still have a growth number of 31 on IC2's side correspond with the same growth rate as a 10 on AgriCraft's side.

Interesting. That could work.
The question is: How do we handle Crops that are not on the others side?

I don't think that is an issue, isn't the aim to make your crops which don't work on our side work on our side and vice versa?

Yes That is the idea: That you can switch between mods without losing anything... I would benefit both sides xD

@InfinityRaider IC2 Classic is already in Rewriting for 1.9.x but i am at the point where the crops beeing a thing. So i am asking if you want to make compat so i can make the code ready so we can make a compat.

Ok i checkt your registry:
You have a Item & Meta To CropInstance registry (note: Metadata has a custom function in 1.9 so do not use damage as meta)
IC2 uses ModID + PlantIDName to save the CropCards... There we have the problem...
How do we convert from these systems?

I think we will need a mod talking registry where both sides can register their crops. So that we can switch them over... (Not the stats i mean the types) So if addons of IC2 for example add crops that they can bound themselves without much code to Agricraft and opposite... And that we do not have to write so much extra code...

Agricraft has such a registry, I'm not sure how IC2 handles its crops though.

IC2 has a crop registry two. But both can not convert to each other or am i wrong?
Edit: i mean a registry which can convert between both crop types... or how do you think we should check which type is with which type compatible?

Why is there the need for the String, why can't we have two maps instead:
Map(CropPlant, CropCard)
Map(CropCard, CropPlant)

Ok what i have in mind here is:
This map could work but it is really addon/futureproof incompatible.
The idea behind the extra string maps is simple:
You register a Crop (for example: Wheat) then you register it with the Id wheat. same as IC2.
But what if you have a crop that IC2 does not have but a addon. You could register simply your side
and if the other side does not have it then its not a problem. But you could simply work independent and do not require to know what IC2 has implemented. Simply supporting a guessing game xD

Edit:
Also where do you want to place the class?
I was thinking maybe making a new class called:
CropDictionary or something like that....
Also what package do we want to use?

Well does IC2 have a register method to register crops, or is it just class based (instanceof).
Also it depends, do you want it on your side or on ours.

Yes it has that and i am playing with the idea to add autoregister to the convertion registry. (IC2 has a registry for crops)

I think that it should be maybe a independent thing... ^^"
But i would have nothing against both sides... Just so that only a API is required^^ (No mod core)

I will set down tomorrow (because here is the day already over) and write a basic registry and then we can build on top of that...
Any other ideas for compat that could be added to the compat?

Making the fertilizer work on agricraft crops too I guess.

Well at IC2 the Crop handles the fertilizer. Should i add a call from IC2s side or do you want to have a function in the api that allows you to validate the item of IC2s fertilizer (optional also Overgrowth Fertilizer)?

There is an interface, but if IC2 has an api for it I'll add it from our side.

ok. Only thing i worry about is only how we do the names in the registry (since we kinda have to make them match) so we should make (when i provided you with the source) a list of what is what.

IIRC the IC2 seed bags are one item and the NBT defines what seed they are. Next to a name you could also add an int as id and asign that to the meta. Similarly to GregTech ores.

Yes to the storage. And Yes and no to the second thing....
Simply the problem is: We do not know which seed is for the other the same matching seed.
(I am simply 1 set behind what you told)
Thats why i suggest a convertion registry so we can get quick and easy the matching things...
Example:
Map(String, CropPlant)
Map(String, CropCard)
Map(CropPlant, String)
Map(CropCard, String)

The strings would be the shared ids so with that we could get the easy convetion.
(Only a idea) (also assuming that crop plant has access to meta & item that it has in his registry)

From your side, having to check the seed and build around what the ICropPlant object provides is independent of having Strings or not. If the ICropPlant interface does not provide enough information, I might be able to extend it. Just ask what you need.

Registering from pre-init is possible, we just have to cache all registry entries until both sides have their Builder object registered. The downside is that you have no direct feedback to check if registering was successful, but the Builder interfaces can be extended with a method to notify when a crop has been successfully regsitered.

Ok i am building the compat at the moment and i notice that IAgricraftPlant has nothing todo with the CropSticks right? It should be ICropPlant that should be registered? Or am i wrong?

ICropPlant is the interface which is important here.
Also, as I have said before, the 1.9 port is still in progress and as a result the interface might still change.

Yeah i saw that... I simply added Helpers which have to be added by the mods (allowing to dissable the compat if people do not want to have it) and these provide the important information (converting a stack into a seed for plants) and doing the actuall planting on their side... Just the thing: The Crop Seed is the thing that handles the planting not the crop... Should i keep your reversed way also in mind?
Also how do you store the stats of a crop. I think there is a API part missing...
Yeah found the part where the API is missing... But i think i can handle that with the helper class...

The stats are separate from the Crop.
We ahve one registry which is basicly a Map(Item, meta -> ICropPlant). The ICropPlant defines the base growth rate, tier, fruit drops, rendering, etc. Basicly everything the TileEntity needs to know.

Then there is the ISeedStats, which has to be extended to make this work. This is a second field on the TileEntity to alter the behaviour (speed up growth, increase fruit drops, ...). The stats are stored on the seed ItemStack as an NBT tag.

Yeah.. I just threw a couple helpers in to get the SeedStats...
Only thing is: IC2 Crops have differend tiers of Analyzing and they need to know if they are analyzed or how far they are analyzed...
But i think i have a solution

ok i have that now done... Where should i provide you with the first source?
Its just a proof of concept so far....

Wherever suits for you.

Compat lib.zip

There is still stuff needed to be made...
Edit: But this is just the first idea to what could be added and what needs to be done so it can be implemented to your mod too...

Outline looks okay, but I still do not know why we have to have this intermediate String in the maps.

Strings are simply there so mods can register their sides and if someone has no match that it does not care. Its is simply: Addon & Modpack supporting.

But I can make sure from ourside that if someone registers a new crop, that it automatically registers to this registry. If you do this from your side, I don't see the need for the Strings.

@InfinityRaider how do you want to find a equal thing for your ICropPlant when you do not know which CropCard is equal to it. Also removing the StringIDs forces you to have a equal thing when you register it. That thing makes it easier for you because you do not require a crop card to register something...

I was thinking about something along the lines of this: https://gist.github.com/InfinityRaider/6b17c29e692f3b3fe481169b3d46cd97

This way, we are each responsible for creating our own CropCard/ICropPlant objects for a passed ICropPlant/CropCard. And either side can register an arbitrary crop and the other side will automatically follow. This also removes the need for those Strings.

We could also use Forge's event system, to fire an event when a crop is registered from one side. The other side then creates a listener to pass a matching ICropPlant/CropCard to the event. The dictionary then takes that from the event and registers it. Which allows registering of crops during pre-init.

EDIT: scratch that, we still have to register the event listeners.

Hmmm true problem is how do you define the CropCards what they are? i mean the only way is based on guessing... You still would have to do the String checking for the crop types... and from my side i would have to make a check based on your seed... That would end in more work and not really expanding capacty since you base around that you have to know what you are having on the other side...
The thing is here: We only know what is on our side not on the others... So its a blind system...

Edit: i get what you try to say. Having strings between is maybe not the best solution but it makes the work on either side a lot less...
Edit2: Your registry change has only 1 downside. It forces that you can not register them in Preinit...
The functional has to be inited before. I do not prevent a addition because if the other side is not loaded you still have your side created but you get the info when you ask if it is functional that you can progress in the item usage that we can continue...

Just a question could you join the FTB Ts maybe talking is faster then typeing...
Edit: i am off now... tomorrow then

I am now on the FTB Ts if you want to join i am waiting @InfinityRaider

true but that allows you only to handle the basemod stuff... emmmmm.... also postinit would be the time to register all the things... ModSorting, Addons, Modpacks and co need to be keept in mind...
I think we really should have a direct talk (not a text chat)

I'm sorry, I caught this 6h after you placed it. My agenda is quite, ehm turbulent lately. Besides my mic is broken. I can still come on TS to hear you out but I'll still have to type. Also it might be more useful to ping me on IRC if you are using that.

@InfinityRaider yeah IRC would be better then this delayed chat here...
Edit: i just need your name (i tried already InfinityRaider)

But that is my nickname...

@RlonRyan why did you change that to 1.7.10?
Also @InfinityRaider how is the progress going?

^^" ok. Just wanted to make sure that the project does not loose itself in the sand....

No progress yet, I have other piorities atm

@InfinityRaider just small little changes which should not even effect our things... but it would be great if you could prepair a API...

The mod has undergone significant changes since the 1.7.10 version, making it hard to re-establish an API right off the bat, before an official stable release occurs.

@RlonRyan i know that already but we made already basic stuff so i think he knows what needs to provide and what not...

I don't think you get the degree to which I've changed the code while @InfinityRaider was gone... All I can say is that it will be a bit before we can formally introduce an API... I mean, I'd be happy to help with the API, it's just that there is a lot of work to be done. After all, we're always happy to find people interested in the mod.

@RlonRyan did you see the special api we try to make?

I did, and it looks good, but it will just be a while before we can implement it.

@Speiger there will not be a 1.9 release for agricraft, but you will also move to 1.10 I suppose and I don't think nothing important has changed.

Well i did not expect it so early. IC2C is still under Construction. So that will take a while too... But i plan to do 1.9.4 and 1.10... Simply to have 2 versions...

There are not even plans for a release yet, I'll get back to you once this is the case.

@InfinityRaider ok good to know.
I think i will take at least 2-4 weeks to get to the first test version (that is my hope)

@InfinityRaider @RlonRyan ping.
Now almost a month is over after we talked about the compat...
IC2 Classic is getting close to its Development, I tried to get some fixes through to the API (the part i have no control over) but was not able to get all that through... and i wanted to know how far your progress is so that we could start making it work...

https://github.com/TinyModularThings/IC2Classic/milestone/4
My todolist to reach the first test version....

I am closing this as we are moving to 1.16.