-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fieldwork mode - interrupt forager #53
Comments
So just to make it get that right: the basic underlying problem is that when starting the course manually from a waypoint within the field course, the implement's work function (in your case the pickup's lowering and activating) is not activated? I think I've seen that myself before, hadn't even tried the method you've described above. But for now, all (or at least most) things concerning implements and their correct functioning will have to be relegated until the script documentation is online. Until then all we can do is only guesswork. And keeping the motive of guesswork, the thing with activating the pickup is the following: if workArea and fill_level ~= 100 and (self.abortWork == nil and last_recordnumber == self.startWork or self.abortWork ~= nil and last_recordnumber == self.abortWork - 4) then
---it's go time, baby!
elseif not workArea or fill_level == 100 or self.abortWork ~= nil or last_recordnumber == self.stopWork then
--- no can do, kiddo!
end Meaning:
We might have to rewrite those regulations in the future, but for now, I'm sorry to say that no, there's no quicker/better method for you to have the pickup activated - short of not removing the driver and its trailer from the course. |
Yes that is it, and if I press the B key (during CP Fieldwork mode) there is no effect so I cannot override CP control. Thanks for your analysis of the problem. |
@abehnke, with the current version (10 Feb), could you please test this again? You still shouldn't be able to override CP's pickup down/activated control, but it should be activated when starting the course from within the field. |
Test results - no change. Details: Downloaded ZIP Feb. 10, 2013, FS13 1.4. Course is for grass on fields 26+27, 592 waypoints, 3 waits and 2 crossings (START and STOP). First waypoint #1 is a CROSSING and a WAIT (#1), at waypoint #310 is WAIT (#2) in the field, a 3rd WAIT is outside the field at the sheep trough, the last waypoint is a CROSSING (STOP) and ends on the field. Wagon is the Krone 550. Procedure: starting just outside the field at the start waypoint #1 with an empty wagon, press Ctrl+7 - result: normal operation Krone is turned on and grass is foraged at field speed. I waited until about 10% full then pressed Ctrl+7 to stop drive, then pressed Ctrl+7 to resume drive (I expected it to resume foraging at that point) but instead it drives at street speed to waypoint #310 - WAIT #2. I can still used the reset procedure that I outlined in my initial post to cause a forage to start anywhere I want on the field. I also did some random tests just driving around the field and pressing Ctrl+7 to see what would happen but I never got it to start a forage operation by doing this. |
Field courses can only have 2 wait points, otherwise we wouldn't know where the field starts and where it ends. Please try again without the sheep trough wait point. |
I changed the course so it now has just 2 WAIT points on field. WAIT #2 is at waypoint #312. Result: no change. A few more details though. As before, I let it get to 10% full: 1 before START, press Ctrl+7 About the three WAIT points, 1 extra then recommended, I have used this course a couple of times in the past with no problem of the extra WAIT point. I believe the program is only interested in the first two WAIT points it sees on the course. These two define the field. The forager quite reliably runs the unload loop when full and returns to forage. My original loop takes grass to the sheep, waits for me to unloaded it then goes to the tip point on the farm then back to fields 26+27. So I top off the sheep and sell the remaining grass. |
@abehnke, you shall not be forgotten. I've found the reason for the problem, just don't have a 100% viable solution yet. Here's something for you to test. I've tested it successfully with a cultivator in mode 6, but haven't had the setup to test it with an unloading tool/course (i.e. forage wagon) yet. With the latest version, In if workArea and fill_level ~= 100 and ((self.abortWork == nil and last_recordnumber == self.startWork) or (self.abortWork ~= nil and last_recordnumber == self.abortWork) or (self.runOnceStartCourse)) then to if workArea and fill_level ~= 100 and (self.abortWork == nil or self.runOnceStartCourse) then The problem was/is that I included a conditional so the tool won't lower or activate while folding. That conditional basically always thought it would be folding, even if it wasn't. And even with forage wagons. The conditional is still there (as it should be), but ... bla bla, you get the gist. Let me know if you have any results. |
I am sorry to report that I don't see any change in behavior. Using ZIP file Feb. 25, 2013 2:56pm - with the modification to line 119 of mode6.lua as you specified. My course of 416 waypoints is: waypoint #1 - START and WAIT #1 Using a Deutz M620 + Krone 550: I repeated the above at waypoint #80 with similar results - forage resumed at waypoint #69 after running the unload loop So in summary, if the forage is interrupted then CP wants to run the unload loop before it will resume the forage operation. On another test, after step 4, I would STOP drive then drive the wagon to various points in the field and attempt the ctrl+7 with the result that CP drives the field course (starting at the nearest waypoint) at street speed but won't turn on the forage operation and I cannot override it. If I turn the forage on then it turns it off. I supposed actually it is doing what you said in an earlier post: "If there is no point where it'll resume work (self.abortWork), you will have to start at waypoint 1. It is just that CP is taking a long path to get there :-) I am happy to test any other aspects of this. Thank you for looking into this issue. |
Okay so we're dealing with two different problems here, which I'd prefer to keep seperate for the sake of sanity (mine, that is).
Concerning 1.: honestly, if you start the driver (him wanting to go to the second waiting point), stop hiim, and then start him again, it should reset his need to head to waiting point number 2. Try this with the hud open to see each time which waypoint is the currently active one for him. Yes, it might be a bug, but it's the same one as in combi mode when you start the driver in the middle of the course and he then wants to drive to his second waypoint. I stop him and start him again, and bam, he's on track. In conclusion, I honestly think this is too small a bug to search for and provide an elaborate solution. Especially if it's possible to solve the problem by clicking three times instead of only once. Now, concerning 2. This is a whole other animal, one that's driving me crazy for a while now: the automatic reactivation of tools upon returning to the field (their last point in the field, let's call it Like I mentioned earlier, I've tested it with a cultivator and it unfolded and lowered correctly when starting it midfield. But I couldn't test it with an actualy unloading and returning course yet. |
Yes that is true. The first time I stop CP, the destination waypoint is WAIT #2 minus 4. Then if I start and stop CP again, the result is CP resumes the field course at the nearest waypoint but at street speed and forager off.
Yes - all my prior tests have shown that the forager will work properly if I let it return to the field under CP control by passing the last waypoint (STOP). The Krone 550 reactivates properly and starts eating up grass/straw. This works with or without the change at line 119 you recommended. I also tested the Pott. 1252 windrower that comes with the game using the change at line 119. Using the same forage course as for the wagon, if I reset the course and start before waypoint #1 then the windrower fails to unfold and turn on. Instead it wants to go straight for WAIT #2 minus 4 (waypoint #306). I can get it to turn on by driving it manually to just before the last waypoint - STOP - then it will go to waypoint #6, unfold and operate normally. Below is an image of my course, waypoint #1 (START and WAIT #1) is in the lower left, WAIT #2 is the other blue circle, and STOP is a red circle. |
I was getting a little confused about all this, so I reviewed the prior posts on the issue. I thought about your reference to problem #40 "failure to turn on after unload". I have never had this problem!. In all the past weeks and numerous ZIP files, my forager runs fine (abort, unload, return) so long as I don't interrupt it while it is doing its field forage activity. This might be because of the my field layout. I always attach the unload loop to the end of the ZIGZAG field course and then I have the last waypoint - STOP - somewhere on the field edge but usually some distance away from waypoint #1 - (START + WAIT #1). This configuration allows the forager to return to the abort waypoint without having to visit the waypoint #1 - START - thus saving some time. |
In a prior post, I mentioned that the windrower failed to start. I was curious as to why. So, I started a fresh game session, making sure that abortWork was nil in the vehicles.xml. This time the windrower approached waypoint #1, unfolded and ran normally. In my prior test, I had dropped the forage wagon and picked up the windrow in the same session, I guess something was left over from the forage operation? But I did find that the windrower suffers the same problems as the forage wagon, if I interrupt it. I added more "print"s to the mode6.lua. Here is something that may be causing difficulties. In the following, all the statements are from mode6.lua. When I stop drive then start drive during the windrow operation, self.loaded gets set to true which caused this "if"
to become true. The next lines after this set self.abortWork to be not nil. Since self.abortWork is now no longer nil then this "if" (the line #119 replacement)
cannot be true. Program flow does not enter the code to activate the windrow. Also, runOnceStartCourse stays true until the windrow gets to waypoint #1 then stays mostly false. Apparently, it gets set true for each drive start then false each time it gets through #119 "if". |
All appears fine now. I tested the following: Krone 1290 baler, Krone 550 wagon, Kuhn 17002 tedder, Pott. 1252 windrower, and the Arcusin Autostacker. All tools unfolded and started. I could start and stop all tools while on the field course, and they would resume at the nearest waypoint. Also, the 550 wagon could be started and stopped while on the unload loop, and it too remembered its field abort point and continued normally upon reaching the field. Just a small note, the existing issue with the Arcusin Autostack remains. Thanks for all the fine work. |
Sometimes a like to stop drive on a forger when in Fieldwork mode so I can take the product somewhere manually. The difficulty lies in re-starting at the abort point. After doing my manual task with the forager, I do the following steps:
1 Reset the course
2 Load the forager course
3 Drive the forager manually to the point in the field course where I want it to continue foraging
4 Press drive (Ctrl 7) four times - details:
4.1 1st press wants to send the forager somewhere on the course I don't really want
4.2 2nd press stops that
4.3 3rd press causes CP to remember the current position - I can see that because the waypoint display changes to my current position. The forager starts moving but it does not do the B function. Pressing it manually has no effect.
4.4 4th press stops CP
5 I manually drive to a waypoint near the STOP sign so that I am at "course end" minus one or two
6 I press start drive
7 CP waypoint display indicates it is at the end of the course (the STOP sign) but it then immediately updates itself to the waypoint remember in 4.3.
8 Forager under CP control arrives at the restart point, turns on, and resumes normal operation
Is there a simpler method?
The text was updated successfully, but these errors were encountered: