Field Fertility Factor Exploit/Bug

Can’t imagine this is intended, (and I was sure to get my Speedrun in before it’s changed :joy:), but you can bypass weed levels and rockiness by extending a 5x5 field into a 10x5 field.

The initial field completes and I start field extension at around the 23:30 mark, and I select the extended field at 26:00 (magically 0% weed level and rockiness).

I imagine this applies to larger fields as well, but I’ve only experimented with 5x5 each time. I have tested it multiple times on multiple maps, and only on already fairly fertile land.

This was fixed in v0.7.6, are you running an older version of the game for your speed run?

I kinda felt it had been mentioned/fixed somewhere, but I ran probably 8+ runs and as far as I’m aware it’s the latest update…I’ll double check,

I was wandering if it’s because I made the extensions soon after the initial field had completed (before anything had actually been grown in the field - although I had scheduled the 3 year rotations)?

I’ll check version in the next 20mins and let you know, sorry if I’ve wasted your time with this (if it’s an older version somehow).

Yeah they have all been while running Ver.7.6

I was rerolling/restarting the same map/settings over and over, but the initial map was only created 2 days ago, and has been V7.6 since it was released (as far as I am aware)

Also while I have your attention…
I have had this field bug again but during my timelapse series

2:30 I draw the extensions, at 7:50 you can see the sizes the fields display…

I’ve reported/submitted multiple times for this but as I received no real feedback, I’m not sure if it has been acknowledged as a bug and you would like further reports/submissions, or its some weird anomaly that I am alone in experiencing?

I realize you guys are swamped with numerous reports etc, just not sure whether to continue reporting the same “bug” over and over or not :+1:

Thanks

Maybe the Known Issues List could be updated?

Things like the music volume bug…should I also report this or has it already been identified and being worked on?

Maybe links on the Known Issues thread to the various issues that have been acknowledged? To streamline the reporting a little…because currently I would have to search to see if an issue had already been posted, and then there’s no real gauge of whether the issue requires more reporting/submissions or not.

Hoping I don’t come across as whining!
I only want to help make the game even better where possible.

We don’t have a repro for that issue yet.

Not sure what you’re picturing. Our internal bug tracker is, uh…considerably larger than what players have found, haha. We only list the most common/prominent issues in there.


We tested that scenario, and tried to repeat it now to no success, including copying your exact field setup and crop rotations. What you are observing is exactly the bug we fixed.

Perhaps you need to verify game files. Are you running any mods?

Sorry if I am being blonde…do you mean reproduction? I have experienced (and submitted) multiple instances and with the recent one shown in the video, does that mean that when you guys loaded my save files the fields displayed correctly for you?

I will try verifying today :+1: No I don’t use any mods.

I’m sure! :sweat_smile: I guess maybe because there is no feedback following submission of save data, as a player/tester, I don’t know whether the bug has been categorized as (for example)

  • Unable to reproduce (low priority/fringe case)

  • Unable to reproduce (medium priority/need more submissions)

  • Bug Reproduced/Acknowledged (no more submissions/recreations required)

  • Bug Reproduced/Acknowledged (need more submissions/recreations)

I doubt it is as easy as that, but for instance the music/menu bug that I also linked, is that not something that can be easily tested/recreated without any submission? If it is easily reproduced by anyone with the game open, then the thread could be linked in the Known Issues thread under

  • Bug Reproduced/Acknowledged (no more submissions/recreations required)

If it isn’t quickly reproduced and has a very low report rate then either add it to Known Issues as

  • Unable to reproduce (low priority/fringe case)

Or if that would be far too much work, considering the volume of threads/reports, then maybe a way of marking threads quickly so we know whether or not to continue supplying reports/save data for recurring bugs?

At the moment its hard to know whether its helpful or not to keep submitting a recurring bug, or an instance of a bug that has already got a thread? Like the music volume thread - should I be creating a separate thread? Has this already been reported multiple times? Do the Devs need more because its not easily reproduced?

Maybe there is already a system in place and the current Known Issues thread does already cover the majority/all of the most reported outstanding bugs, in which case my apologies, but if there are already multiple reports of for example the music volume issue and its already something acknowledged and currently being fixed, there is no obvious way of knowing that from the bug reporting area of the forum.

I guess in summary it just feels a little unresolved after submitting save data, and hard to know whether to keep reporting recurring issues.

Sorry if this hasn’t been very helpful!

I will try the file verification soon, thanks for responding

Yes, a repro means to reproduce a bug. :slight_smile:

And that is correct, we would load your saves and be unable to reproduce the issue.

For the most part, the average reporter is not going to check any other threads, including ours, for whether an issue has been reported or not.

That is fine. It’s not their job. We’d rather get dupe reports than no reports at all cause people are frozen wondering if devs already know.

In fact, it’s a common issue that people often do not report bugs at all because they assume A) it must be happening to everyone so surely the devs know or B) surely someone else reported it by now.


Generally, the only reason to comment on an existing bug report is if you have new information that can contribute to reproducing and addressing it. Bumping a bug report just to say “I’m also having this issue”, or “still not fixed” does not provide us with anything new to work with. If we didn’t list something as fixed in the patch notes, we know it’s not fixed, haha.

We only comment on bug reports if we need more information or if it’s a common enough issue that we want anyone else stopping by to know it’s already fixed in a future update.

1 Like

This was sort of applying to me…not submitting bugs because I didn’t get any feedback from previous submissions, saw a duplicate report, or didn’t want to be continually pestering you guys with repeat entries :joy: guess I am not the average reporter!
That’s ok though I will probably start reporting a little more frequently and try and stay up to date with the patch notes etc :+1:
Thanks for your responses,

I verified my steam files (“All 58 files validated”) and quickly tested the field exploit…same result :

I included the New Settlement/Loading Time/Construction Time etc at 4X Speed just to show the process.

Soooo…is there any value in continuing to report this? Or do you want any technical information about my PC? Or is it just ghosts in my machine? :wink: :grinning_face_with_smiling_eyes:

Thanks again!

Any value in me trying a fresh install instead?

No need. I rolled back to the live version and retested, and it appears the fix simply was not committed for the release build.

Try to reproduce it in the v0.8.0 playtest, I suspect you will not be able to.

1 Like

And stop pestering you with my weird field size issue? :man_shrugging: Or report any future issues on the existing thread I made? Promise I’ll leave you be after this!!

Thanks so much for clearing stuff up :+1:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.