Bale loader wheel position under load

[JakobTischler]

I'm having a bit of a problem with the wheel settings for the Ursus bale loader. In default conditions (empty), it's all ok:

---

Wenn it's fully loaded though, the wheels sink too much into the ground. I understand it's supposed to simulate a bit of deflation, but for my taste it's too much:

---

The real problem happens though when unloading: the spikes clear are too far down (in the terrain):

---

The current settings are:

        <weights weight="2.62" maxWeight="4.6" realBrakeMaxMovingMass="5.6" /> <!-- in t -->
        <wheels>
            <wheel driveMode="0" radius="0.43" deltaY="0" damper="20" suspTravel="0.05" spring="138" realMaxMassAllowed="9.2" brakeRatio="1" />
            <wheel driveMode="0" radius="0.43" deltaY="0" damper="20" suspTravel="0.05" spring="138" realMaxMassAllowed="9.2" brakeRatio="1" />
        </wheels>

As you can see, deltaY is already at 0. Any tipps?

[Dhalj]

I think you can make the deltaY value negative

I think you also have to increase the spring settings, how heavy is a fully loaded trailer with silage bales, I think silage bales are the most heavy ones. --> 2nd, you should use the MR 1.3 formula for spring settings (3xload(T))/susptravel I think this will increase the spring value

2nd option you can also make the susp travels smaller, and specifiy the "realMaxMassAllowed" parameter But I think the trailer has some suspension, so that would make it less realistic.

[JakobTischler]

Hm, I didn't even consider the weight of silage bales vs. straw bales. So my max weight is actually a lot higher than first anticipated. But, while I would like to see some suspension, the problem really is that the spikes move until the terrain when unloading. So I really have to make sure that the body at that time is far enough away from the ground.

I played around a little, these seem to be good (albeit not perfect) settings:

        <weights weight="2.62" maxWeight="6.22" realBrakeMaxMovingMass="8" /> <!-- in t -->
        <wheels>
            <wheel driveMode="0" radius="0.43" deltaY="0.05" damper="20" suspTravel="0.10" spring="250" brakeRatio="1" />
            <wheel driveMode="0" radius="0.43" deltaY="0.05" damper="20" suspTravel="0.10" spring="250" brakeRatio="1" />
        </wheels>

[Dhalj]

did you try if a value of deltaY="-0.1" works, then you can also lower the wheels and keep some spring

[JakobTischler]

I did, but it didn't really work, because of the spike situation I described.

[quadural]

in such a situation, the first thing to do is reducing the "suspTravel" (we don' t want the "spikes" to go below the ground) => you can set the "suspTravel" to 0.05 for example (we can even set the "suspTravel" to 0 with Giants patch 2.1 and MR V1.3) => then, apply a "high enough" spring setting so that the "suspension" are only "50%" compressed at standard full load.

Finally, don't forget to activate the debugmode to check the actual mass on the wheels. (in your case, maybe the silage bales are not "100% MR"

A silage bale should not weight more than the grass bale it comes from, like IRL... And so, when "converting" a grass bale to a silage bale, we have to modify by script the "fillLevel" of the bale object by applying a factor = grass density / silage density (0.25 / 0.4 = 0.625 in our case)

[JakobTischler]

A silage bale should not weight more than the grass bale it comes from, like IRL... And so, when "converting" a grass bale to a silage bale, we have to modify by script the "fillLevel" of the bale object by applying a factor = grass density / silage density (0.25 / 0.4 = 0.625 in our case)

Are you saying that we need a script for that, or that MR already does that?

[quadural]

the base FS13 game engine doesn't handle silage bales. So as the "mr egnine". There is obviously a script in the ursus bale wrapper to change the fillType of the bale from grass to silage. The "fillLevel" should be changed at this level. (easy for a mod, more complicated when we are talking of an encryted DLC...) If we can scan the new specializations of the ursus bale wrapper, we should beable to "guess" which one does this job and then, we could create a "append" function to that one to set the correct fill level to the bale.

[JakobTischler]

I'm thinking it doesn't just change the fillType, but rather creates a new bale (from the silage bale i3d). So I'm gonna have to alter the Bale:new() or Bale:load() or some similar function, I think.

[quadural]

problem : when calling "new" or "load", we don't know what is the fillType of the current bale (before being converted to silage)

if the ursus bale wrapper can only handle "grass" bales, this is ok. if the ursus bale wrapper can wrap any kind of bales, this is a problem (a silage bale made of straw has not the same weight than a silage bale made of grass which is also different from a silage bale made of hay)

[Satissis]

as by standard, you can only wrap grass bales. I tried it 2 weeks ago, so I'm pretty sure it don't take straw bales, since it gave me the message that it was the wrong type.

[quadural]

only "grass" or "hay and grass" ?

[Satissis]

these are the default fill types of the baler: wheat_windrow barley_windrow dryGrass_windrow so I'm guessing that there is only hay bales. I think they didn't care about if it was a grass bale or hay bale when wrapping, so they convert the hay bale into and grass silage bale when they are wrapping it.

I haven't tested this thou, but I'm pretty sure about it, since if the baler fill types.

[quadural]

ok. But, regarding the ursus wrapper ? does it accept "grass bales" too ? if so, since the bales can come from another baler, we have to check the "fillType" of the bale before setting the new "fillLevel"

=> maybe we can do that at "grabbing" time or when the bale is "mounted" on the wrapper ?

[JakobTischler]

The wrapper accepts dryGrass_windrow and grass_windrow bales. But, as Satis wrote, the Ursus baler can only bale wheat_windrow, barley_windrow and dryGrass_windrow. So for those two, we wouldn't need to worry about different fillTypes, as only dryGrass_windrow could be wrapped. But I don't know if the wrapper actually accepts bales that come from any other baler than the Ursus one.

[quadural]

the ursus wrapper does accept any bales. the only thing verified is : (as far as I know)

• fillType (grass or hay)
• baleDiameter user property of the bale
• balewidth property of the bale

[JakobTischler]

Yes, I can confirm that. I just checked the John Deere 864 125cm bales, both grass and hay were accepted. Also: the moment the wrapper "grabs" the bale, it's already changed to the base silage bale i3d.

[quadural]

There should be an action before "grabbing" then. the specialization has to "delete" (or modify) the targeted bale object

maybe we can rely on a "getBaleInRange" function as for the autostackers class ("baleLoader") => store the bale fillType if there is a bale object returned

[JakobTischler]

Alright, I'm finally able to get into the getBaleInRange() function. A bit more complicated than usual, as it's apparently not in self, but only in the spec. Anyway, I was able to jump into the function.

Here's the data I'm getting:

getBaleInRange: bale=table: 2236E660
bale = {
    ["realSleepingMode1"] = "true";
    ["supportsWrapping"] = "false";
    ["update"] = "function: 095FAB58, defined in (100-140)C:/Users/JakobTischler/Documents/My Games/FarmingSimulator2013/modsMoreRealistic/moreRealistic/OverrideBale.lua";
    ["fillLevel"] = 4680.5673828125;
    ["nextDirtyFlag"] = 2;
    ["dynamicMountSingleAxisFreeX"] = "false";
    ["baseDirectory"] = "C:/Users/JakobTischler/Documents/My Games/FarmingSimulator2013/pdlc/ursusAddon/";
    ["baleDiameter"] = 1.2000000476837;
    ["i3dFilename"] = "C:/Users/JakobTischler/Documents/My Games/FarmingSimulator2013/pdlc/ursusAddon/roundbales/roundbaleHay120.i3d";
    ["customEnvironment"] = "pdlc_ursusAddon";
    ["physicsObjectDirtyFlag"] = 1;
    ["dirtyMask"] = 0;
    ["dynamicMountForceLimit"] = 0.025999998673797;
    ["isRealistic"] = "true";
    ["wrappingState"] = 0;
    ["baleMesh"] = 139305;
    ["isClient"] = "true";
    ["baleWidth"] = 1.2000000476837;
    ["sendPosZ"] = -1132.1169433594;
    ["isServer"] = "true";
    ["sendPosY"] = 85.862968444824;
    ["realSleepPos"] = {
        ["y"] = 85.862968444824;
        ["x"] = -559.30517578125;
        ["maxDistBeforeAwake"] = 0.05;
        ["z"] = -1132.1169433594;
    };
    ["sendPosX"] = -559.30529785156;
    ["forcedClipDistance"] = 80;
    ["isRegistered"] = "true";
    ["sendRotX"] = 1.6859385967255;
    ["lastMoveTime"] = -100000;
    ["fillType"] = 13;
    ["realCurrentMass"] = 0.23402836914063;
    ["nodeId"] = 139303;
    ["baleValueScale"] = 1.6000000238419;
    ["dynamicMountTriggerId"] = 139304;
    ["dynamicMountSingleAxisFreeY"] = "false";
    ["sendRotY"] = -0.26066532731056;
    ["sendRotZ"] = 1.5430430173874;
    ["id"] = 482;
};

So I'm seeing the fillLevel and fillType, I'll set them as a special variable in self and then handle it.

[JakobTischler]

So, I got good news and bad news... :)

The good news: it's working:

getBaleInRange: bale=table: 1AA68880, silageBaleData=table: 0B4AB8A0
    fillType=13 (dryGrass_windrow), fillLevel=4680.57
    ratio=0.12500 -> set fillLevel to 585.07

The bad news: I tried it with the John Deere 864 grass_windrow bales. To my surprise their fillType is dryGrass_windrow:

getBaleInRange: bale=table: 28826B78, silageBaleData=table: 0B4AB8A0
    fillType=13 (dryGrass_windrow), fillLevel=3142.80
    ratio=0.12500 -> set fillLevel to 392.85

I'm not sure if the grass_windrow -> dryGrass_windrow conversion takes place in the JD 864 or in the wrapper, but I'd think it rather happens in the baler.

[quadural]

everything is normal then. This is just a "bad" john deere 864 baler => look at the jd864 baleType for grass : it should be the same bale i3d than for dry_grass

anyway : this "script" should not be applied to "not mr" bales.

Edit : you can look afor the "isRealistic" flag to see if a bale is a "mr" one or not.

[JakobTischler]

anyway : this "script" should not be applied to "not mr" bales.

Right. I'll add a and bale.isRealistic.

I looked at the JD's grass bales i3d: fillType = dryGrass_windrow, realFillType = grass_windrow. I assume realFillType is something MR specific and I can actually use that?

[quadural]

I don't think so... I will check that, but I don't remember adding a "realFillType" and I don't see the point EDIT : this is not a "mr" parameter. Where did you find this JD864 ?

[Dhalj]

I think it is in the v1.1 version of the JD baler, some information is already added to the lua script to determine if it has to be MR or not. unfortunatly, this script does not work very well, and you still have to change some parameters to get it working correctly.

I think it also was Jacob who posted the correct .lua fixes on vertexdezign.net

[JakobTischler]

I think it also was Jacob who posted the correct .lua fixes on vertexdezign.net

Ha, must have forgotten that :) I have some idea though why they did it that way: so it works with Giants' ursusAllowAllBales.zip script.

Anyway, I've rewritten the script a little, and now everything works as it should. I also take the realFillType into account.

getBaleInRange: bale=table: 0B38ED80, silageBaleData=table: 225AE7C0
    fillType=12 (grass_windrow), fillLevel=3142.80
    ratio=0.62500 -> set fillLevel to 1964.25

getBaleInRange: bale=table: 0B0F3530, silageBaleData=table: 225AE7C0
    fillType=13 (dryGrass_windrow), fillLevel=4722.61
    ratio=0.12500 -> set fillLevel to 590.33