[1.1] Giddy-up!

[Trentennisfigati]

you're great! thanks!!!

[Roolo]

I found a bug in Giddy-up! Ride and Roll.
-> Using Giddy-up! Ride and Roll v.1.1.1 (Jan 22, 2019) and Giddy-up! Core v.1.1.4 (Mar 2, 2019).

I give you two examples to make it clear:
[...]

Sorry for responding a bit late, the notification system on the forum doesn't always work. Anyhow, thanks for you write-up. I'll respond to both issues:

1. Fixing machines with components:

This problem used to be present with a lot of jobs, and I had to manually fix it for different jobs. But I never noticed it happens when machines are fixed with components, so thanks for reporting. Why this happens is a bit more technical than you might expect. In Rimworld,  Jobs can have three targets: TargetA, TargetB, and TargetC (jobs can actually have more targets using some other construct, but lets keep things simple). Most of the times, jobs use TargetA as a first target, however this principle is certainly not applied consistently in the game's code. Giddy-up assumes TargetA is the first target by default, and issues a "ride to job" job to let the pawn go to TargetA. However, not all jobs use TargetA as first target, and this results in Giddy-up sending the pawn to the wrong target. There's no way to automatically detect which target is the first target, so I have to manually make exceptions of each job that doesn't have TargetA as first target, which I didn't do yet for the "repair machine" job.

2. Hunting:

Sure this isn't just vanilla behaviour? I've seen this happen in vanilla as well since B19.

[henk]

1. Fixing machines with components:
This results in Giddy-up sending the pawn to the wrong target.
This problem used to be present with a lot of jobs, and I had to manually fix it for different jobs. There's no way to automatically detect which target is the first target, so I have to manually make exceptions of each job that doesn't have TargetA as first target, which I didn't do yet for the "repair machine" job.

Damn that sucks. Is there no way to take over the job target order of Vanilla?

2. Hunting:
Sure this isn't just vanilla behaviour? I've seen this happen in vanilla as well since B19.

hm good question. I'm not sure about this anymore. But to be honest I never (or rarely) saw that happen before applying Ride and Roll.

Case 1 (Vanilla):
When a hunter is on foot he sets his target to the location where he can hit the anmial. In case of a long range weapon this target will be far away to the actual prey he is hunting.
When he arrives at this location he is shooting the prey (or if the animal wandered off he will walk towards it and then shoot but still with a certain minimal distance).
Case 2 (Ride and Roll):
Now with Ride and Roll it's different. The hunters target A isn't the spot far away anymore. The Ride and Roll mod tells him to go (or better: ride) to target A which in this case is the prey itself instead of the spot far away.
But please consider: this is the case when pets are not allowed for hunting. I really think this will be different if I set this option to enabled but I haven't tried that yet.

Of course it could have happend in both cases that the hunter went to the correct target but only the prey has moved to this same exact target in the meantime and therefore the animal was in range and he immediately shot at it (although too close).

But I don't want to lie to you so I will check this out again to be sure .

EDIT:
Ok I tested it again and now have the results. In a nutshell: unfortunately it is the fault of your mod

Hunting:
-> Case 1 (with Ride and Roll, pets not allowed to be hunted with):
https://www.directupload.net/file/d/5390/a4nhq5ok_png.htm
As you can see the target indeed is the prey itself (and the hunter is equipped with a long range weapon).
The prey only walked off a little before I took that screenshot so don't mind the offset to the turtle/tortoise whatever ^^.
EDIT: Even if the prey moves before the hunter arrives the target will automatically switch to the prey again. So wherever the prey goes, the target will always! be the prey itself. I took the screenshot above (and the one below) right before the target could adjust to the new position of the prey. It scans its position every few seconds.

-> Case 2 (with Ride and Roll, pets allowed to be hunted with):
https://www.directupload.net/file/d/5390/np7gbc85_png.htm
Exact same thing happens when pets are allowed to be hunted with. I thought this could be different, but no it isn't.
Same statement of case above applies here.

-> Result (in both cases):
https://www.directupload.net/file/d/5390/5u5bhrx6_png.htm
When the hunter arrived he himself noticed that he is too close now (because he rode directly to the prey). But instead of walking far away to shoot he only took like 3 steps back or something (but this actually could be the fault of Vanilla, I don't know ^^').

Now to make clear the difference:

-> Vanilla, Ride and Roll mod disabled:
https://www.directupload.net/file/d/5390/t8po2r2v_png.htm
When I select a target to be hunted it at first looks like this (not a lot different to your target setting).

BUT!: This is what it looks one second later:
https://www.directupload.net/file/d/5390/8yyp7ybq_png.htm
The hunter rearranged the distance to his target according to his weapon type.
Notice how the hunter only walks up to a certain distance (at the bottom right hand corner) while the prey is far away (at the top left hand corner).

This is what doesn't happen with your mod enabled.
So you might wanna look into this.

PS: If you need me to test other cases / scenarios / settings I'm willing to help you out in order to find the exact problem.

[Roolo]

Thanks again for your clear report. I took a look at the code and I understand what is happening now. Again, it's a bit technical. What the hunting job does first is calling the GotoCastPosition function. This function makes sure that the pawns goes into into casting range. The following things can happen if the function is called (this is all pure vanilla):
A. The pawn is at closer range than the minimum range of the hunting weapon. The pawn will therefore move a bit, until it's within a range larger than the minimum range.
B. The pawn is already in casting range, and outside the minimum range of the weapon, so it doesn't need to move.
C. The pawn is outside the maximum range of the weapon. In that case it'll move until it is within 95% of the maximum range.

In your case when testing vanilla, you saw C happening, as the pawn started outside the maximum range. But if you were to draft the pawn, let it move to the animal manually, and then let it start hunting, you'd get situation A.

Now what happens with Ride and Roll enabled? Well, the pawn first gets a "ride to job" job assigned, and it'll move to the animal. Now again situation A will occur. The minimum range is not that much, so the pawn will only move a bit (like what you observed). So it actually IS vanilla behaviour, though without Ride and Roll, you won't see it as often.

Vanilla or not, it is still annoying, so I'll think of a fix (probably I'll just make another exception so the "ride to job" job doesn't go to the first job target for hunting, but to a cell with a minimum distance from the first target).

[henk]

Thanks a lot. Now I actually understand what happens .
And thank you for fixing it. In case of a turtle it is no biggy but attacking a Thrumbo is a whole lot different with this distance thing ^^.

If I find other jobs with the same problem I will reply here again.

Vanilla or not, it is still annoying, so I'll think of a fix (probably I'll just make another exception so the "ride to job" job doesn't go to the first job target for hunting, but to a cell with a minimum distance from the first target).

What do you mean exactly? A fixed minimum distance for all weapon types? Or variable distances like in Vanilla?

I don't get it. Can't you just sort of copy paste the code from Vanilla? Why is this not possible? With or without pet riding doesn't make a lot of difference, does it? There would be no need for more exceptions in your code.

You said yourself: 'There's no way to automatically detect which target is the first target, so I have to manually make exceptions of each job that doesn't have TargetA as first target, which I didn't do yet for the "repair machine" job.'

But as a matter of fact the game (Vanilla) knows which target is the first, second, third target for each and every job. So there has to be a code for this. Can't you go with this code and align the rest around it? At least that is what I would try to accomplish (as a not-programmer ^^').

[Roolo]

I don't get it. Can't you just sort of copy paste the code from Vanilla? Why is this not possible? With or without pet riding doesn't make a lot of difference, does it? There would be no need for more exceptions in your code.

That wouldn't work. Take in mind that for any Ride and Roll job, a "ride to job" job is issued first for various reasons, before the actual job is started. When the "ride to job" job is created, TargetA of the hunting job is used as a target. TargetA is the animal that's being hunted, and not the location at 95% of the maximum range (this location isn't stored anywhere but calculated during the hunting job). So there needs to be an exception for hunting jobs, so that the "ride to job" job goes to a location outside the max range, and not to the animal, or the "ride to job" job needs to be skipped entirely, but then "forbid riding zones" will be ignored (which probably isn't a big problem for hunting). But either way, an exception is needed.

[henk]

That wouldn't work. Take in mind that for any Ride and Roll job, a "ride to job" job is issued first for various reasons, before the actual job is started.
[...] But either way, an exception is needed.

Yes, that is how it works now (with your code). But couldn't you have it coded another way?
Like this:
TargetA -> Go to animal and get on its back -> Command finished (no further commands, targets or whatever).
From there on the normal Vanilla commands start / take effect. With all their exceptions and targets as we mentioned above.
So it is just a normal pawn (riding an animal) doing his jobs. With exceptions for 'no riding zones' of course.

So instead of having one huge string of commands at once you split them completly. One command is to ride an animal. Afterwards a whole other command starts.
Or will this lead to problems because the pawn is now strapped to an animal? xD

The whole command chain would look like this:
[Ride and Roll Mod]
1. Start task (for example hunting) (check for pet within range that was applied in mod options and check for no riding zones).
[Exception]-> And check for job category. If sleeping, surgery, putting out fire, watching TV, cooking, etc. etc. -> just ride to location, get off animal, then go on with step 3.[/Exception]
-> You could also put this exception after step No. 2. So that a pawn will ride to a sleeping, surgery, etc. job but then gets off the animal if exception = sleeping, surgery, etc. = true. But I don't want to tell you where to place your exceptions xD
2. If restrictions fit the requirement get on the animal.
[/Ride and Roll Mod]
[Vanilla]
3. Start same task again, the same as mentioned in No. 1 (hunting) (but now the tasks of Vanilla take effect).
4. Ride / go to task and do the task as stated in Vanilla.
[/Vanilla][/b]
[Ride and Roll Mod]
5. After finishing the task start all over with No. 1
-> if requirements fit, stay on animal and just go on riding to next job
-> if one requirement doesn't fit, get off animal and walk to task (or ride to nearest 'get off animal spot' and get off animal there).
[/Ride and Roll Mod]

[Roolo]

That wouldn't work. Take in mind that for any Ride and Roll job, a "ride to job" job is issued first for various reasons, before the actual job is started.
[...] But either way, an exception is needed.

Yes, that is how it works now (with your code). But couldn't you have it coded another way?
Like this:
TargetA -> Go to animal and get on its back -> Command finished (no further commands, targets or whatever).
From there on the normal Vanilla commands start / take effect. With all their exceptions and targets as we mentioned above.
So it is just a normal pawn (riding an animal) doing his jobs. With exceptions for 'no riding zones' of course.

So instead of having one huge string of commands at once you split them completly. One command is to ride an animal. Afterwards a whole other command starts.
Or will this lead to problems because the pawn is now strapped to an animal? xD

Trust me, I've thought this through. Take in mind that many jobs shouldn't be performed on a mount, but even for those jobs, you want the pawn to ride to the job. With your approach, pawns would end up in bed with their mount, they'd perform surgery on their mount etc. etc. Or they just wouldn't ride to any jobs that can't be performed mounted.

Anyhow, please take in mind I spent countless hours on developing this mod, and I made decisions for reasons that might be hard to follow if you're not familiar with the code.

[henk]

Trust me, I've thought this through. Take in mind that many jobs shouldn't be performed on a mount, but even for those jobs, you want the pawn to ride to the job. With your approach, pawns would end up in bed with their mount, they'd perform surgery on their mount etc. etc.

No, they wouldn't. Because jobs like sleeping, surgery, etc. would be within the requirements in No. 1 and 2 (edited part in thread above).
[Exception]
If job = surgery, sleeping etc. -> only ride to job location and get off animal before doing actual Vanilla task No. 1 (=surgery, sleeping) again. (step No. 3 as above)
[/Exception]

Anyhow, please take in mind I spent countless hours on developing this mod, and I made decisions for reasons that might be hard to follow if you're not familiar with the code.

Alright alright xD. I trust you on this. As mentioned I am clearly no programmer, coder or whatever and am in fact not aware of any code of the game.
If you say it is not possible, it just isn't. Thanks for the clarification .

[Roolo]

No, they wouldn't. Because jobs like sleeping, surgery, etc. would be within the requirements in No. 1 and 2 (edited part in thread above).
[Exception]
If job = surgery, sleeping etc. -> only ride to job location and get off animal before doing actual Vanilla task No. 1 (=surgery, sleeping) again. (step No. 3 as above)
[/Exception]

Ok, in that case it would work, and it would solve the problem with hunting. However, it wouldn't solve anything more than that. For jobs that can't be done mounted, the "ride to job" job, still has to issued, and for those jobs, we still need all the exceptions we currently have. And unfortunately, the only jobs that form exceptions to the rule of having targetA as first target are jobs that can't be done mounted.

So with your approach you end up with even more exceptions, since you now need to check whether the job can be done mounted or not, while you still need to check for exceptions in terms of what is the first job target. Since it only solves the issue with hunting, it's not worth the added complexity. It's far easier to just add another exception for hunting like I planned. This also keeps things more consistent which is something to strive for when coding.

[henk]

I see, my approach would have been too easy xD.
Thanks for the explanation. I'm looking forward for the changes in the jobs fixing constructions with components and hunting.
Do you already have a timeline for those fixes?
Thanks for your efforts.
Greets

[SargBjornson]

Hi Roolo! I was adding some new saddles, this time to Alpha Animals, and I noticed that

Code Select Expand

<li Class="GiddyUpCore.CompProperties_Mount">
<drawFront>true</drawFront>
</li>

Seems to not be working. Because what it should do is draw the mount in top of the rider, right? I was trying to use it for the Meadow Aves, which are like ostriches, so their neck should draw on top when facing south

[Roolo]

Hi Roolo! I was adding some new saddles, this time to Alpha Animals, and I noticed that

Code Select Expand

<li Class="GiddyUpCore.CompProperties_Mount">
<drawFront>true</drawFront>
</li>

Seems to not be working. Because what it should do is draw the mount in top of the rider, right? I was trying to use it for the Meadow Aves, which are like ostriches, so their neck should draw on top when facing south

Nice, more saddles, that makes me happy . Strange though, it's working fine for trumbo's alpacas and some other vanilla animals. You can find the code for that in Patches.xml, did you look at that? Also for the meadow aves it's probably best of you don't draw them in front, but use am overlay to draw only the head/neck in front of the pawn, like how I did it with the caribou. Otherwise you'll also get the tail in front of the pawn, which looks really awkward.

[SargBjornson]

Yeah, problem though, the Meadow Aves use the Animal MultiSkin DLL, which was coded by the guys behind Animal Collab Project, so if I create, say, a blue skinned overlay it will look terrible on a pink Meadow Ave

Perhaps this DLL is too what is causing the drawFront not to work...

Damn, can't see a way around it!

[Roolo]

Yeah, problem though, the Meadow Aves use the Animal MultiSkin DLL, which was coded by the guys behind Animal Collab Project, so if I create, say, a blue skinned overlay it will look terrible on a pink Meadow Ave

Perhaps this DLL is too what is causing the drawFront not to work...

Damn, can't see a way around it!

Ok, I understand. Maybe I can come up with some patch for the Animal Multiskin DLL, I'll have to look into it. Though I'm very busy with real life stuff, and have an almost finished update for What the Hack I want to release soon, so those things will have to go first.