Test Ursus DLC

[Dhalj]

Are the bales converted to MR? and is that even possible, I know that we can set the linear and angular damping to 0, but can we change the othere parameters in the i3d of the bale to make it MR?

Quote from Dural on FS-UK: Regarding bales, either you use the default "mr" bales (look at the path in the converted bales xml), and if you want to use the mod bales (because of the different size or whatever you think is important) : you have to edit the i3d of the bale to :

• remove the linear and angular damping
• set the friction (static and dynamic) to 0.6
• add/modify thes user attributes : isRealistic (boolean) = true baleValueScale (to be transform to float) = 1.6 for roundbale, 1.4 for big square bale

(private MR) trailer without bales = total weight=6295 (weight on trailer wheels = 3450kg)

(private MR) trailer with 14 bales = total weight=5532kg (weight on trailer wheels = 2700kg)

[JakobTischler]

Yes, the bales are MRized. See the setBaleMrData() function. Damping is set; friction isn't, because we can't; baleValueScale is set to 1.6; isRealistic is set to true.

Concerning the weight: this is extremely weird. Even if the weight was incorrect, it should in no way be negative. Ever. Also, I've tested this with the Ursus bale loader, and the weight seemed t be okay, IIRC. Maybe @quadural could give some insight here. Have you actually pressed those bales ingame with the Ursus baler, or created them via the vehicles.xml file? Also, what is their fillType and fillLevel?

[Dhalj]

I just made them with the Ursus bales

fill type is straw, fill liters (3884L, 104%)

I think straw is also another bale i3d then grass or straw

this is the baler emptied, I can only see a minor weight difference on one of the wheels

[JakobTischler]

Hm, seems like the bales do indeed not have the correct weight. Shouldn't isRealistic take care of that, though?

[Dhalj]

I saw that the grass bales do have some weight, but they do not have weight when they are inside the baler. emptying the baler gave the same result

[quadural]

for the trailer test : actually, you have to move to measure the bale weight. Indeed, the bale correction force is not applied at still for performance reason. (and when object are interacting each other, the resulting force can be negative.) Make sure the "dynamicMounting" stuff is not at work too.

for the baler weight : everything seems normal to me : 9.799 T empty 9.939 T with a full straw bale => 140 kgs for a 1.2m diameter straw bale = ok

[JakobTischler]

for the baler weight : everything seems normal to me : 9.799 T empty 9.939 T with a full straw bale => 140 kgs for a 1.2m diameter straw bale = ok

True, I must have read the numbers wrong.

@Dhalj: can you test your bale trailer again while moving and check the weights?

[Dhalj]

Here are the test results

Empty trailer: 3460kg on the wheels Loaded trailer: 4690kg 14bales: 1230kg 1 bale: 88kg

did not know that the "sleep" function of the MR engine work so quickly

[quadural]

ok, so it seems this is "normal" (as normal as possible with the physx collision) => just make the same test with the default mr lizard bale trailer and the default mr krone round bales to see by yourself => as soon as 2 objects interact each other (collide), it seems there is some weight lost. This is the same when you take only one bale with a frontloader (some weight dissapear, it can also be negative)

[Dhalj]

I am busy making MR bales with the krone comprima, for testing the Marshal bale trailer, so I will also test them on the Lizard bale trailer.

Other isssue: are there any filling sounds on the ursus baler, and if not, can we add something? it is very difficult to drive the baler from the cab view now. while playing with the krone comprima is very easy from cab view.

Bale tests on blue trailers Empty trailer: 2940kg on the wheels Loaded trailer: 4550kg 14bales: 1610kg 1 bale: 115kg

[JakobTischler]

it is very difficult to drive the baler from the cab view now. while playing with the krone comprima is very easy from cab view.

Nothing really we can do about that. The camera settings are of course always in the tractor, not in the attachable.

---

are there any filling sounds on the ursus baler, and if not, can we add something?

There already is a baler sound active. In total there are 4 sounds: balerSound, balerAlarm, balerBaleEject and balerDoor.

[JakobTischler]

@quadural: Concerning the weight of the baler when it's filled up 100%: shouldn't this already be handled by realisticVehicle or realisticBaler/realisticEnhancedRoundBaler? I don't think that I would need to specifically specify an additional weight based on fillLevel, would I?

[quadural]

@JakobTischler : regarding Dhalj comment on the baler, I think he is talking of the "realEnhancedBaler" settings of the "mr" krone comprima. Just make one bale with this baler (cab view => just with sound, no need to look back. real sounds from the IRL comprima) and you will understand what he meant.

@JakobTischler : baler weight = we already answer this question a while back and it seems fine for the ursus one. for the baler weight : everything seems normal to me : 9.799 T empty 9.939 T with a full straw bale => 140 kgs for a 1.2m diameter straw bale = ok

[JakobTischler]

Right, I probably should have checked the numbers before asking :)

Concerning the sound... I assume we have no access to better/original sounds, so we're gonna have to keep it at status quo.

[JakobTischler]

I tried increasing the volume of baler sounds, until I realized I can't even hear the fill level alarm in the original state (w/o MR), although it is definitely in the XML. Very weird...

[quadural]

Max sound volume possible = 3 (if I remember well) And so, if the sound file is not enough loud, even when playing, we can't hear it (covered by other sounds ?)

[Satissis]

Is it me or is the bale loader animations really slow ? it feels like the bale is going to fall off the grabber way before it reaches it potential bale roll off effect. I know this mod have nothing to do with cp, but I was using it with cp and I had harvested, raked (19m), bales the starting field on the titanium map and the bales is so close, that even that I set it to the lowest speed when using the bale loader (3-4mph) it could not finish the animation until it had reached the next bale, so it skipped that bale.

I think I saw that the animation speed had been adjusted, but is this not too much ?

[JakobTischler]

The original length of that animation was 0.6 seconds, which seemed way too fast for me. I slowed it down to 25%, meaning 2.4 seconds. And yes, I tested it with CP, of course, and using bales created by the Ursus bale loader, the distance between them was still big enough so that the bale loader could finish it's lifting/lowering animation when going ca. 11 kph. You can try setting the animation speed scale to 50% (1.2 seconds) instead and see if that fits better.

[quadural]

Well : first problem = you should not use the "ursus baler" to bale a "19m raked up" straw windrow. This is pretty unrealistic, you will have to drive the ursus baler at less than 1kph IRL not to "block" it... How much distance do you get between 2 bales by doing so ?

[Satissis]

@quadural The distance is around 20-30m I think. This was on an unfertilized field, if that have something to say on how much straw is produced when harvesting.

@JakobTischler With the distance as above, and going as slow as possible with cp, it do take the first 2 bales, but then there is the push animation from bale 2 to 3, so that's an extra 5-10 sec, where it can't pickup bales, causing it to skip at least 1 bale (Somehow cp do not stop when the push animation is playing, which it do on the standard one, but that is cp related) Another thing I also noticed, was that when cp takes the last bale and it moving to transport position, the bale grabber stays down, but don't do so when using the original animation speed.

[quadural]

ok, unfertilized field = about 3T per Ha of straw. One straw bale = about 140kgs => one bale = 466m2 of field. 466/19 = 24.5m, so everything is normal (except the fact making a bale in only 25m = driving very very slowly IRL not to "block" the baler)

[Satissis]

So I have been playing with the animation speeds and it's true that the normal speed scale 1 for the grabber arm, is a bit to fast to my taste as well, I think I found an median speed scale, that we all maybe could agree on. This is my settings with testing: animationSpeedScale="baleGrabberTransportToWork:0.8,baleGrabberWorkToDrop:0.65" In my opinion, these settings is more like the real one. The grabber is not to fast or slow. The baleGrabberTransportToWork is still a bit slower that the other animation, but it prevents cp from leaving the grabber down when transporting from the field to the unloading spot.

I know that I did rake it with an 19m rake and the bales is really close but this is also a stress test + every tools used needed to be driven really slow for this to work in cp, like the bale loader needs to be set to an max speed around 4-5 mph.

What's your thoughts on this ?

[JakobTischler]

I can live with those values. Also saves me from having to find those ;)

The baleGrabberTransportToWork is still a bit slower that the other animation

In reality, of course, this animation should even be a bit faster than the other one. It's basically doing the same thing (lifting the grabber), only that it doesn't have the weight of the bale on it.

[Satissis]

Yeah, I currently have no more bales to test with, but I'm pretty sure the we actually could set the baleGrabberTransportToWork to 1 in speed and it would be around the same speed as the other one, but still a tiny bit slower, so it would not stay down in cp when going to transport mode. Would have to test that just to be sure, but as I have no more bales, either one of you could test it or wait until I get some bales pressed again :)

[JakobTischler]

@quadural: probably has nothing to do with Ursus, but I did change the animation scale on the bale loader, then entered my savegame again. Once I started to drive the tractor with the bale loader, the game crashed with the following error:

PhysX invalid parameter: NxRay direction not valid: must be unit vector.
(D:\sw\physx\PhysXSDK\2.8.4\trunk\SDKs\Core\Common\src\SceneRaycast.cpp:418
*** 7.3421369552612 MoreRealistic - ERROR - RealisticVehicle.updateVehiclePosition - Betongewicht - getLinearVelocity - impossible result returned. velx/vely/velz=1.#QNAN/1.#QNAN/1.#QNAN
*** 7.3421369552612 MoreRealistic - ERROR - RealisticVehicle.updateVehiclePosition - Ursus T-127 - getLinearVelocity - impossible result returned. velx/vely/velz=1.#QNAN/1.#QNAN/1.#QNAN

The first one is the tractor's front weight, the second one the bale loader. Any idea/solution?

[quadural]

you are right, this has nothing to do with "MR". Here, you can see a "security" I set because I encountered this message a few time while "making" the "mr". (and in such case, the "mr engine" was "crashed" too, causing various problems.) But the real error is the **"PhysX invalid parameter: NxRay direction not valid: must be unit vector." Surely a problem with the "animated" specialization that used a divide by 0 or something like that because of the change in time of the animation (maybe the "saved" animation time is not "possible" with your new settings) Anyway, you get to crash the "physx" engine, and so, at my level, I can't get a "normal" value with the "getLinearVelocity" function. I don't think this is a real problem if this only happens when you modify the animation scale of a vehicle and load a savegame => it seems you have to buy the vehicle again or start a new game if you can't reset the animation.

[JakobTischler]

So, here's where it's getting very weird: I just can't get rid of the error/crash.

• Trying to reset the baleLoader in the savegame: crash
• Selling it and buying it anew: crash
• New savegame (default map) with the current online MoreRealisticDLCs version: crash
• New savegame (default map) with the MoreRealisticDLCs version before my latest commit: crash
• With only moreRealistic, moreRealisticGenuineMap, moreRealisticVehicles and MoreRealisticDLCs in the mod folder: crash
• Without MoreRealisticDLCs: no crash

I don't always get the PhysX error, but always the MR error print. I honestly don't have a single fucking clue what the hell is going on...

[quadural]

do you get the crash only with the bale loader (or the bale loader bought) ? or does the crash occur as soon as you start a new game ?

In my case, I didn't get all the time the "physx error" too. This is why I set the "security" piece of code to check if everything was notmal before trying to update a vehicle. Of course, it should never happen with "correct" mods.

Did you commit your change to github ? if so, I can check if I get the problem too (I don't have the ursus DLC by the moment)

[JakobTischler]

If the savegame is saved with the bale loader, then game crashes as soon as the loaded savegame is started. If it's not in the savegame, the game crashes when I buy the bale loader (after loadFinished()).

The version I'm using is the one that's online at GitHub. Satis already told me he doesn't get the error with that very same version. But please check on your end.

[quadural]

are you playing with the 64bits mode of the game EXE ?

[JakobTischler]

Nope, 32-bit on an x64 system. But that never caused an error before.

Edit: if I use the x64 version of the game, it doesn't crash anymore when I buy the bale loader, but your error is printed every loop. This time with INF instead of NAN though.

*** 10.822924316406 MoreRealistic - ERROR - RealisticVehicle.updateVehiclePosition - Ursus T-127 - getLinearVelocity - impossible result returned. velx/vely/velz=-1.#INF/-1.#IND/1.#INF

[quadural]

welcome to the "FS nightmare underground" (mac users do know a lot about this. BJR tractors for example with the animated pedals => no problem on windows version of the game, weird behavior on mac version)

Anyway, this is always a "bad" script / animation setting that can cause this kind of problem. And since you were working on the bale loader animation, I suspect this has something to do with one of its animation.

[JakobTischler]

And since you were working on the bale loader animation, I suspect this has something to do with one of its animation.

Yes, I thought so as well. But even if I remove all references to the animations, the game keeps crashing. Also, I use the animation speed scale on other tools, for example the baler or the bale wrapper. And they both don't cause any problems. And as I mentioned, Satis uses the exact same settings (the current online version), without any errors. This is so extremely weird.

[JakobTischler]

Uhm, you wanna hear a funny thing?! I found the reason. It's all YOUR FAULT, Michel! ;)

I should have remembered earlier, but the problem started when I downloaded and installed MR 1.3.47. And so, I just tested 1.3.46, and the problem is gone... just like that :) So you should probably look into that one.

[quadural]

ok, I get the problem on my side too anyway. I will check that then.

Edit : problem "found". The only thing I did with the V1.3.47 is activate the stabilizer bar again. Then, I saw you set a "0" susptravel for the ursus bale loader. This is the problem : the stabilizer bar doesn't seem to be able to handle "0" cm susptravel (logical) Now, I will modify the "mr engine" to support that then.

[quadural]

ok, new version available (v1.3.48) to handle that : https://drive.google.com/folderview?id=0B_iAIcwiFq-bNzVScHpkb1dkSTg&usp=sharing

PS : explanation of the "problem" = since the susptravel ==0, and we have to compare the difference between the left and right susptravel compression to simulate a stabilizer bar, there was a 0 division and then the result was used to compute a new "force" to be applied to the vehicle main component. => #inf or #nand value used when calling the "addForce" function = either a crash, either a "unresponding" vehicle (physically speaking) either a "flying" vehicle ;)

[JakobTischler]

Yup, no error or crash anymore. Thank you.

[quadural]

since you "forced" me to get the ursus DLC, I will have a look at it too, and I will get ride of all these "pesky" 0 susptravel I see ;)

[quadural]

The ursus N270 manure spreader has an "insane" working width.... it seems closer than 16m rather than the advertized 10m of the shop. This is not "realistic". Such a "spreading system" should not exceed 7-8m IRL. We can add new nodes for that, but then, we would have to be able to "override" the "cutting area" of the spreader

[Satissis]

Okay about the N270, I did ask if we had a way to reduce the cutting areas, since CP said it was 16m working width (which fits well, then using cp to spray with) and from the Ursus website: http://en.ursus.com.pl/Spreading-and-fertilising/Manure-spreaders#URSUS-N-270 It says that it only have a working width on 5-6 meters. I think our concern the last time, is that the spreading particle system is made so width as well, so we would need a way to change that as well or else it will look like it's spreading 16m but in reality only spreading 6m.

BTW: I don't know why I didn't set it to 16m in the shop.

EDIT: It also have that extra hp, that it should not have, since of my mistake on believing that the power requirement on the website was what it needs to run it with out pulling power.

[quadural]

The particle system is not really a problem in my mind. How to explain this ? Well, IRL, the manure spreader does spread wider than 5-6m, but, there is not enough "manure" spread after the first 2m on each side. And so, when doing the second pass, you "fill the gap" by applying another "thin layer" of manure on the same place.

Easier to understand = the farther from the spreading unit, the less manure you got on the ground. So : effective spreading width per pass = 6m, but "particle with" should be closer than 9-10m IRL => in our case, we can set the spreading width to something like 8-9m and do not modify the particle system.

[JakobTischler]

I've noticed this with the Ursus baleLoader, but this may as well apply to all other tools. With your ( @quadural ) recent MR changes concerning capacity and fillVolume, do we need to set the realBaseCapacity in the xmls? For example, the baleLoader always shows a fill level of 0 (even though the fill level bar is being filled up). I had the same problem with another mod which didn't have realBaseCapacity set.

[quadural]

Acknowledge. In such case, this is a fix on my side to take into account "autostackers". Please get the V1.3.58 "mrEngine" to fix this. => https://drive.google.com/folderview?id=0B_iAIcwiFq-bNzVScHpkb1dkSTg&usp=sharing

[Dhalj]

I checked the Ursus vehicles today, to make sure that they work.

Jacob will adjust the powerconsumtion when using the cylinders of the wrapper. the wrapper and the cyl both used 22kW, this will be changed into 22kW for the wrapper and 11kW for using the cylinders.

edit, this is done: 0a8fdd170fbf65ebe5aaa73452467e9f949cea5d