New crop type bug

Your forum for all discussions around Modding.
onlybr
Posts: 20
Joined: Mon Oct 02, 2023 6:06 am

New crop type bug

Post by onlybr »

I'm racking my brains to understand why after I add a new culture to the game, some parts of my map that are grass (decoration) become areas with cultures, could this be some "id" conflict? or something else? I've already tried everything I can to change the "foliageXmlId" (prints below), I've inverted the positions of the other added cultures and it's kind of a surprise with each map creation, because every time it's a different culture when I change the order.

Image
Image
Image
Image

I don't know what I did wrong, I always edited and never had this problem, I tried several ways without success. Could anyone help me solve this mystery? I didn't post the log, as I didn't find any errors related to the map, it opened without errors even after editing.
User avatar
LS-Lara
Posts: 396
Joined: Sun Aug 04, 2019 4:57 pm

Re: New crop type bug

Post by LS-Lara »

It is completely logical that something like that happens, when you change the order of the fruits in the "map.i3d". When you do this, you change the "translation sheet" for the "densityMap_fruits.gdm". There will be no error, because it is no error - you told the game what to do and it did it for you. You just gave some bad orders :biggrin2: .

I guess you are aware that you are beyond the default 32 foliages limit, as the map was upgraded to 6 channels for fruit types. Was this already present in the map or did you do this on your own later? Is there any good reason why you use 6 compressionChannels and was the transfer of "densityMap_fruits.gdm" to 6 channels done when foliages were already present or before (or was a separate re-indexing of the gdm applied)?

Could you give an exact chronological breakdown of what the map properties were at the start and what steps you performed then?
Der Sinn des Lebens ist:
29.61%

Mein Traktor:
Base:
HP Pavilion 690-03xx
Core i7-8700 @ 3.2GHz
NVIDIA GeForce GTX 1060 6GB
2x Benq GL2450H
Windows 10 Home 64bit
Custom:
2 x 16GB Corsair Vengeance LPX DDR4 C16 XMP 2.0
Samsung NVMe M.2 970 EVO Plus 500GB
Samsung SSD 860 EVO 1TB
Logitech G203 Prodigy
Logitech Wireless F710
onlybr
Posts: 20
Joined: Mon Oct 02, 2023 6:06 am

Re: New crop type bug

Post by onlybr »

LS-Lara wrote: Mon Mar 25, 2024 8:02 am It is completely logical that something like that happens, when you change the order of the fruits in the "map.i3d". When you do this, you change the "translation sheet" for the "densityMap_fruits.gdm". There will be no error, because it is no error - you told the game what to do and it did it for you. You just gave some bad orders :biggrin2: .

I guess you are aware that you are beyond the default 32 foliages limit, as the map was upgraded to 6 channels for fruit types. Was this already present in the map or did you do this on your own later? Is there any good reason why you use 6 compressionChannels and was the transfer of "densityMap_fruits.gdm" to 6 channels done when foliages were already present or before (or was a separate re-indexing of the gdm applied)?

Could you give an exact chronological breakdown of what the map properties were at the start and what steps you performed then?
The map comes with the normal densityMap, I changed the channels to suit the greater number of crops, I remember that I converted the densityHeigh and densityFruits with Giants' own GRLE converter, according to a Farmers BOB video on how to increase this limit to 64 .
User avatar
LS-Lara
Posts: 396
Joined: Sun Aug 04, 2019 4:57 pm

Re: New crop type bug

Post by LS-Lara »

Probably the tutorial you watched showed you how to increase the CAPACITY of your GDM file for the purpose of creating foliages on a blank map. But did it also show you how to convert the DATA CONTENT of your existing 32-foliages GDM to the new 64-foliages structure? I don't think so.

If you have a look at how the data is generally organized inside the GDM and then think a step ahead of how it will look like after the upgrade to 64, you will come to the conclusion that what you experience now was inevitable. And the damage was already done at the very moment you converted the GDM. You probably just didn't notice it at that point.

You have to either rework your GDM (on PNG-Level, either manually or with some smart script) or start over and re-paint all the relevant foliages with their new indexes in GE.
Der Sinn des Lebens ist:
29.61%

Mein Traktor:
Base:
HP Pavilion 690-03xx
Core i7-8700 @ 3.2GHz
NVIDIA GeForce GTX 1060 6GB
2x Benq GL2450H
Windows 10 Home 64bit
Custom:
2 x 16GB Corsair Vengeance LPX DDR4 C16 XMP 2.0
Samsung NVMe M.2 970 EVO Plus 500GB
Samsung SSD 860 EVO 1TB
Logitech G203 Prodigy
Logitech Wireless F710
onlybr
Posts: 20
Joined: Mon Oct 02, 2023 6:06 am

Re: New crop type bug

Post by onlybr »

LS-Lara wrote: Mon Mar 25, 2024 5:10 pm Probably the tutorial you watched showed you how to increase the CAPACITY of your GDM file for the purpose of creating foliages on a blank map. But did it also show you how to convert the DATA CONTENT of your existing 32-foliages GDM to the new 64-foliages structure? I don't think so.

If you have a look at how the data is generally organized inside the GDM and then think a step ahead of how it will look like after the upgrade to 64, you will come to the conclusion that what you experience now was inevitable. And the damage was already done at the very moment you converted the GDM. You probably just didn't notice it at that point.

You have to either rework your GDM (on PNG-Level, either manually or with some smart script) or start over and re-paint all the relevant foliages with their new indexes in GE.
I have no idea how to paint the densityMap_fruits.png as I said to correct the problem, I opened it here and the points that are changed are actually shown in this image, but it would be an extensive job. I'll try to edit through GE.Regarding the video I saw, he teaches by showing a map of it, but I don't know why this problem didn't occur, maybe it's because he increased the limit to 64, but didn't add any new culture, not generating the problem.

Furthermore, I'm going to look at your topic to try to understand a little more about gdm, I was completely new to these farming matters, little by little I'm learning from people, I'm very grateful for the help Lara!
User avatar
LS-Lara
Posts: 396
Joined: Sun Aug 04, 2019 4:57 pm

Re: New crop type bug

Post by LS-Lara »

onlybr wrote: Mon Mar 25, 2024 9:36 pm but I don't know why this problem didn't occur, maybe it's because he increased the limit to 64, but didn't add any new culture, not generating the problem.
No - as I said before, this has nothing to do with adding new fruits in the first place.

When you convert from 32 to 64, you only change the structure. The data inside will remain identical, but it is now interpreted differently.

For example, on a converted 64-system a foliage that was previously saved as stage 4 in the 32-system will now be considered as stage 2 in the 64-system. Especially on decoFoliage, this will have crazy impacts.

Also, there are not necessarily all equivalents for all values between the two systems filled with valid fruit stages, so this will lead to blank spots. This effect will become visible instantly after you have converted to 64 - if you know what you have to look for. If you then add new fruits later and fill those data gaps, suddenly your new fruits will pop up on places that were previously blank.
Der Sinn des Lebens ist:
29.61%

Mein Traktor:
Base:
HP Pavilion 690-03xx
Core i7-8700 @ 3.2GHz
NVIDIA GeForce GTX 1060 6GB
2x Benq GL2450H
Windows 10 Home 64bit
Custom:
2 x 16GB Corsair Vengeance LPX DDR4 C16 XMP 2.0
Samsung NVMe M.2 970 EVO Plus 500GB
Samsung SSD 860 EVO 1TB
Logitech G203 Prodigy
Logitech Wireless F710
Post Reply