Inconsistent harvester working width and overlap

[SylentXtinction]

I recently performed a test of header operating width and overlap. None of the headers or harvesters tested, were capable of producing consistent results. These tests were performed on flat terrain, with new equipment, without obstructions or obstacles within 300m.

Headers tested:

-AGCO DynaFlex 9255 (12m)
-AGCO PowerFlow (12m)
-New Holland Varifeed 41FT (12.5m)
-CLASS CONVIO 1230 (12.3m)

Harvesters tested:

-CASE Axial-Flow 9240
-CLAAS LEXION 8900

Platform - Console (PS4)

Field pattern:

"Flag"/"Pennant"/"Flanged" - 24m 'y' axis, with 24m 'x' axis flag lanes at 48m intervals [72m on-center interval] (see diagram below)

X = 24m squared

XXXXXXXXX
X
X
XXXXXXXXX
X
X
XXXXXXXXX
(pattern continues)

Field overall dimensions:

Length - 672m
Width - 216m

Goal:

To establish a field pattern which could be painted by the player with available landscape tools, which would direct an AI worker to operate a harvester continuously. This was to be accomplished by positioning auger bins along the route, permitting automated unloading in motion, without the need for player control. Additionally, the pattern would facilitate an interface to it's mirror image... to enhance productivity, field density efficiency, and effectiveness of the equipment.


Test method:

When comparing paint tool limitations and header sizes, I found only 12m headers were evenly/closely matched to paint tool sizes and allowed intervals. After testing both 12m headers, it was found that overlap consumed part of the working width of neighboring swaths. On the next test, I used a 12.3m header. The results were slightly better, but it was found that overlap consumed more than 0.3m and I changed to the 12.5m header. The 12.5m header performed better, but still came up short over the course... with a deviation of nearly 4 meters at the end of the pattern. The test was repeated with the next available size header of 13.7 meters. As expected, the header was too wide to complete the pattern.

I have tested multiple headers, harvesters, pattern configuration intervals since this test, with equipment not listed. In conclusion, I have determined there is no way to accomplish the goal listed above without remediation of the code itself (or possibly a 12.6m header?) Suggested fixes are as follows:

#1- HIGHER RESOLUTION LANDSCAPE PAINT TOOLS

The current brush application resolution is 2m intervals in a locked grid. I suggest allowing smaller intervals, down to the minimum effective change (which appears to be 0.5m or 0.1m).

#2- HIGHER RESOLUTION GPS COORDINATES ON THE MAP

The given minimum resolution of header size is 0.1 meter. The observed resolution of visual change in field texture is approximately 1/3rd of 1m... although lack of full or accurate crop rendering is not withstanding, nor is it consistent with soil texture... so any minimum deviation should be reflected. The observed resolution of field texture change was tested by linear progression of a cultivator through 2m brush blot, throughout 9 lines of progression. The results are as follows:

-1st line: mixed texture base/cultivated
-2nd line: engaged painted area, base/painted/cultivated colors evident
-3rd line: mixed texture paint/cultivated, fully cultivated previous
-4th line: mixed texture paint/cultivated, fully cultivated previous
-5th line: mixed texture paint/cultivated, fully cultivated previous
-6th line: mixed texture paint/cultivated, fully cultivated previous
-7th line: mixed texture paint/cultivated/base, fully cultivated previous
-8th line: fully cultivated all painted area, mixed texture base/cultivated, fully cultivated previous


#3- MENU SELECTABLE AI CONTROL FOR MINIMUM SWATH THRESHOLD

In the gameplay menu, have a selectable option for harvester workers to "ignore swath less than ___ meters". The blank should allow the user to select from 0.5m to 3m in 0.5m increments. When this option selected the AI should not recognize a swath width less than the selected threshold. For example, if a harvester begins a swath cutting 12m and it narrows to 0.4m, the harvester should disengage or turn as if the 0.4m swath does not exist. Also, if the harvester ends a swath and only 0.4m is left beside of it, it should not progress or turn around for it.

#4- 100% VISIBLE CROP

I noticed on several occasions, the harvester would harvest crop on the edges of a field, which did not appear to have any crop remaining. However, the header would intermittently display crop being processed, and would also show fruit being lifted to the bin and straw being discharged, along with an increase in the number of contained liters. This should not be the case. The crop should have rendered and been visible in the field, or the harvester should not have continued on to harvest it.

#5- CONSISTENT OVERLAP

I routinely witnessed the harvester overlap being inconsistent. Most modern harvesters in this game offer both GPS and Tx/Rx guidance. Granted, there is always a given amount of deviation, it should not be so significant as to affect gameplay when hiring workers. I also witnessed the harvester not beginning a swath straight... even with maximum clearance on level terrain to enter correctly. This should not be an issue.

#6- COURSE PLOTTING WITH TARGET AND COMMAND POINTS

The in game menu should allow course plotting to be made visible, with target and command points. It should also allow target and command points more than 20m away to be moved and saved for that field and the corresponding equipment. This would allow players to adjust AI worker patterns to suit their needs much better... increasing overall efficiency and creating a much deeper level of involvement and gameplay.

I understand this may seem like a tall order... but most of the recommended changes are all based on data that is already being processed in the game as-is. For instance, the game already renders textures at a minimum of 0.5m as changed via equipment, so adapting brush grid to reflect the same should not be an issue... same goes for GPS coordinates. The game already produces the data, a visual representation shouldn't be too much to ask. Fully visible crop rendering should be no different... as the game is already processing the presence and location, it should render the graphic as well. Course plotting with target points would be yet another example of simply rendering a graphic for existing data... and would not require much to add commands.

As a matter of fact, only two of the above recommendations would require any significant measure of added code... those being minimum swath threshold, and consistent overlap. Minimum swath threshold was included as part of AI logic in FS15. I'm simply suggesting its return with an adjustable value. Consistent overlap shouldn't be an issue either, as the texture data SHOULD directly correlate to crop existence (which it doesn't, for some reason). Given the texture overlays are linked to the same plot points... I still don't understand why these aren't consistent, AND contegious.