deckermmiv / fs13_soilmanagement Goto Github PK

I experienced a very high yield when using SoilMod together with moreRealistic.
My test scenario was wheat on a field with organic fertilization, 100% synthetic and optimal soil pH.
I got 28472 liter per ha!
With only mr it should be 18750 liter per ha (calculated)
It´s almost exactly 1.5 times more with SoilMod. Is it possible this comes from OverrideCutterAreaEvent.lua in mr?

local volume, area, spraySum = Utils.cutFruitArea(fruitType, x, z, x1, z1, x2, z2, true, true);
if volume > 0 then
--DURAL -> less difference between no fertilized and fertilized fields  
  local multi = 1.5;
  if spraySum > 0 then                                    
        multi = 2;                  
  end;
  volumeSum = volumeSum + volume*multi;
  areaSum = areaSum + area;
  end;
end;
return volumeSum, areaSum;

If so, how could this be solved? Change SoilMod or MR?

Edit:
A side effect of this high volume is that combines can drive only very slow while harvesting.

First off, I'm very much looking forward to trying this out. It seems like you thought it through as much as I can think possible, and I expect a new level of realism, and - even more - difficulty, which I always appreciate.

Now concerning the map:

1. You state that withering is activated. How does this correlate with the "settings" in the map i3d's foliages? If the foliage layer doesn't have an attribute for withering, how will this work together?
2. Just to clarify, concerning map instructions, part 5: I assume you're talking about the "GülleMistMod" (slurry/manure mod), or GMM, correct?
3. (Not map related): in the credits, I'd appreciate the k in my name :)
4. Bit of an amateur question, but given the levels of organic fertilizers, would I - in order to achieve a max level - be able to fertilize the same field with slurry three times? Or will the second and third runs have no effect?

Cheers,
-- Jakob

User 'mngrazy' send the following bug-report:

a small "bug" found on the github version ,,, i´m not sure wich one (pda plugin or the SoilMod)
i use this mod from Jakob T http://www.modhoster.de/mods/filltypeoverlays
but the soilMod or the pdaPlugin disable the colored Huds
maybe you can take a look

User 'Katze5' from FS-UK wrote the following suggestion:

In real life there is a difference whether you remove the straw from your fields, or is chopping an spreading it on the soil .. There is a gain by not removing it, and a loss by doing it ... But at the same time, you need to add a bit more nitrate to soil where you are chopping the straw, because the process of releasing the nutrients from the straw, demands a bit nitrate in order to happen... And furthermore you need to add more Lime, in order degrade the straw (the process makes the pH sink)

There may be a tiny "overlap" from one square to the next, when doing the growth cycle, which shows itself as a "thin line of crops" that grows at double speed.

User 'Michalob' from FS-UK asked:

I take it all crops react to the ph in the same way, could this be modified so it was slightly different. i.e. potatoes don't like acidic soils so yields would be reduced lower than say wheat?

User 'mngrazy' on FS-UK has a map with 7 extra fruits in.
Unfortunately the 'Fruit Effects' screen is not set to be scrolling, so it will not reveal all the additional fruits.

User 'Katze5' writes:

I use a lot to go see how far my crops are in their growth stages (pressing ESC, and using the large screen)

Here it could be very useful to have and additional screen or two, that shows the PH level, the fertilization level and the weed pressure in a sort of colour, like the Growth stages ..

In the current 'Fruit Effects' screen, it is not obvious what information it states.

It should more clearly illustrate what the crops can take of synthetic fertilizer, and what type of herbicide that would cause it to "pause growth" or wither.

User 'Katze5' wrote the following on FS-UK:

I can see (from PM's I've got) that there are some people who has some trouble, understanding the instructions on how to install the Soil-Mod ..

The main problem seems to be this system with the numbers (highest number + 10 - 1, or something like that)

I've had never used this system, as I bypassed this part quickly, and used my own ...

Here I use numbers in the thousand group, starting with 3000 for fileID's (3000 for the first fileID, 4000 for the second fileID, 5000 for the third fileID .... And so on ..)

And to keep track of where they belong, I am reusing the numbers for the materialID's, just adding one number - 3001 for the first materialID, 4001 for the second materialID, 5001 for the third materialID.. And so on....

This should be easier to use (I believe) than the system in the instruction sheet..

It should be safe to use, because it's very unlikely, that any map got ID's that high .. You should of course go see, if you for any reason got a number that high - and should this happen, just go one thousand up in number (or whatever you need to..)

Now - I considered for some time, to make a sort of "copy/paste" instruction set for this wonderful mod (thinking that nobody should miss it on their map, and that their modding skills shouldn't prevent them for having this mod installed) but apart from the time that I haven't got enough of, it really isn't up to me, to rework the instructions ..

But the author(s) should perhaps consider doing it themselves, as it isn't always the reader of the instructions that are wrong, when they don't understand ...

It is very hard to write an instruction that covers all areas, and still is easy to understand ... But when a large number of the intended users don't get it, something could be wrong with the instructions ..

I've installed a vast number of these kind of mods the last couple of years, and I must admit, that I've had to study the instructions hard, to understand how it was ment to be used ...

This should be read as positive critique, and an appeal to consider if the instructions maybe are to difficult to understand for new modders ...

Need to include at least the following languages:
de - German
fr - French
pl - Polish

Players are finding that other mods, which also tries to control/overwrite the Utils. functions for foliage-layer manipulation, are conflicting or not working together with SoilMod.

This problem of "conflicting mods" was anticipated, but could there be a future solution for it?

Should (can?) there be some kind of "plugin" ability for SoilMod, so features like green-fertilizing, multi-moving, green-direct-cut and similar, can be added when the players so chooses?

Or should such extra features just be build into SoilMod's scripts, to keep it within "one package"?

With LS15 on the horizon I think this is the perfect time to consider some changes that would make new versions incompatible. If introduced in the first Version for LS15 however, I think this could be acceptable.

What I personally mostly have in mind is the file structure for fertilizers.

At the very least it would be enormously helpful if the number of stages could be increased. At the moment the smallest unit (one level of organic fertilizer) is equal to the nutrient demand of one harvest. Unfortunately this is way to coarse for "small but measurable effects". The straw mod has no other options than doing nothing (no mod needed) or setting fertilizing to 100% of demand. So if you handle your straw right you will never need to fertilize again. The real effect should be maybe 10-15% of total demand.

Dont get me wrong: I dont want to handle fertilization on the %-scale. But 0,1,2,3 is too coarse. If you could maybe squeeze two more bits of the grle for fertilizing one could handle things much more delicately.

That would make me very happy already. Nevertheless, some further thoughts:

I perfectly understand that you designed gameplay mechanics, not real life simulation when you implemented the distinction between organic&artificial fertilizers.

Here is a different idea, which I think achieves the same ends but is more plausible:
Just have one layer for fertilizer. It probably helps if you think of it mostly as N and forget about P,K etc. Doesnt matter that much if you put that in as manure or straight from the chemical factory.

Keep the pH layer. Thats fine. Maybe introduce some effects where organic fertilizer adds some pH buffering capacity (raising/lowering by a small amount if too low/high. Your simple sin-function should work just fine there!). Maybe also add a pH raising effect to one type of inorganic fertilizer (not uncommon). But these are minor things. pH is fine.

And now with artificial fertilizer scrapped you suddenly have one layer free. And that you can use for humus. Which is a very important soil quality parameter. And it allows you to push players in exactly the direction you want to (use more organic fertilizers), but with much more plausible arguments.

What I have in mind should work something like that:

• organic fertilizers improve humus. artificial ones dont.
• harvesting decreases humus
• plowing/cultivating straw increases it slightly
• different plants and harvesting methods have different impact. Maize is a mid-range catastrophy on soil quality, especially if you harvest it completely for silage and not only the corn.
• green fertilizing both increases N (fertilizer) and humus. So it might be a very good idea to put something to regenerate the soil after maize into the ground.

If you like we can have a chat about these ideas, but I put them up here for general discussion as well.

Commit @13885d720bb99b29a765509546eb188f0fcb6d22 contains "some" support for URF-seeders.

The requirement is that the URF-seeder script must send an augmented fill-type to SprayerAreaEvent.

The augment is to add +128 to the fill-type value, as then a different SoilMod spray-sub-function (of the 3 fertilizer-types) will be used, which does not check for crop's first-growth-state.

Example, where using hardcoded fill-type "fertilizer":

SprayerAreaEvent.runLocally(sprayingAreasSend, Fillable.FILLTYPE_FERTILIZER + 128);
g_server:broadcastEvent(SprayerAreaEvent:new(sprayingAreasSend, Fillable.FILLTYPE_FERTILIZER + 128));

Just a suggestion, but I think it would help a lot.

Can you make the gameplay parameters of your mod dependend on a table in g_currentMission?

To illustrate what I mean, lets call it g_currentMission.fmcSoilModParameters = {}

Now I can optionally set fields within the loadMap01Finished()-function of my map.
If they are ~=nil they are taken with priority. This way a mapper could e.g. set fmcGrowthControl.disableWithering without touching your code and without influencing other maps - even if they are loaded after the first one.

besides things like fmcGrowthControl.disableWithering; fmcGrowthControl.reduceWindrows etc I am also thinking of two important parameters that are hardcoded at the moment:

Lets say you define g_currentMission.fmcSoilModParameters.growthDays for the current map and also change the fmcGrowthControl:hourChanged function something like this:

function fmcGrowthControl:hourChanged()
     if  not fmcGrowthControl.active -- Must not already be running
     and g_currentMission.environment.currentHour == 0 -- midnight hour
     and (g_currentMission.environment.currentDay + 1) ~= fmcGrowthControl.lastUpdateDay 
     and (g_currentMission.environment.currentDay + 1) > (fmcGrowthControl.lastUpdateDay + Utils.getNoNil(g_currentMission.fmcSoilModParameters.growthDays,0))
    then
        fmcGrowthControl.canActivate = true
    end
end

and maybe a similar change to accomodate for the slowdown in weed growth:

function fmcGrowthControl:minuteChanged()
     if fmcGrowthControl.weedCounter == nil then
        fmcGrowthControl.weedCounter = 0;
    end;
    fmcGrowthControl.weedCounter = fmcGrowthControl.weedCounter + 1;
    if fmcGrowthControl.weedCounter > Utils.getNoNil(g_currentMission.fmcSoilModParameters.growthDays,0) then
        fmcGrowthControl.weedCounter = 0;
        fmcGrowthControl.weedPropagation = true;                
    end;
end

Just an idea, but I think a lot of folks&mapper would appreciate a feature like this.

This "bug" I was aware of in http://fs-uk.com/forum/index.php?topic=160839.msg1079254#msg1079254 , but now user 'Skw247' on FS-UK has a point that it should be fixed so it will be usable with Courseplay:

is it possible for the fertilizer spreaders and sprayers to remember what was just used rather than what you first filled up with? Say i am using the granular fertilizer spreader and i filled up with fertilizer a to start off with and put that down on a field and had some left over so started to spread fertilizer b on a different field, then the spreader ends up being empty i go back to fill up the spreader and it immediately fills it with fertilizer a again.. So for anyone is using courseplay it can be a problem.

In multiplayer, the server's Cutter.updateTick() will only send a CutterAreaEvent to clients, if the Utils.cutFruitArea() returned a value greater than zero.

That poses a problem, as SoilMod's plugins for cutFruitArea could return zero due to low soil pH levels or other things, but the area was still cut (removed the foliage.)

An attempt at fixing this by returning a very small volume (0.0000001), just caused other and worse problems: http://fs-uk.com/forum/index.php?topic=163694.msg1096855#msg1096855

User 'Baler Boy' on FS-UK, found a problem:

When using the Amazone TF1001 front tank with the UF1801 sprayer I cannot change the fertiliser type of the TF1001 from default type A.

User 'BlackFox403' from FS-UK suggested the following:

The supplied "ReadMe" text file contains some good valuable info to keep on hand (such as the section outlining soil pH percentage values and the tasks to best prepare manure/slurry). Is it possible to somehow incorporate that small niggle of info into the "PDAModPlugin_SoilCondition" so that it could display on a third/fourth page of the plugin (similar to how the vehicle specs info scroll on your "PDAModPlugin_VehicleSpecs" plugin? This way, that important info is available since we always use the PDA, and this allows us to see the pH current and refer to the reference that was provided in the text file.