Skip to content
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

Problems with auto-moving #73062

Open
IdleSol opened this issue Apr 16, 2024 · 11 comments
Open

Problems with auto-moving #73062

IdleSol opened this issue Apr 16, 2024 · 11 comments
Labels
(S1 - Need confirmation) Report waiting on confirmation of reproducibility

Comments

@IdleSol
Copy link

IdleSol commented Apr 16, 2024

Describe the bug

During the automatic movement, I encountered three types of bugs

  1. Incorrect path construction

Instead of moving in a straight line, the game tends to use roads.

For example.
If you move on foot
1
If you ride a motorcycle
2

It's a clear field. With a patch of tall grass. Why would the game suggest a longer path?

These screenshots are not the most representative example. Sometimes the detour is even longer.

  1. Speed reduction
    When using vehicles, the speed is reduced to 6 km/h in some locations. On the road, in the field or elsewhere.

  2. 360 degree turnaround
    Encountered only when driving on vehicles. Moving along the laid route, the transport makes a 360 degree turn. After that it continues to move along the route. Attempts to repeat the car movement on the same section pass normally.

  3. Another reminder
    19 km/h? Why is that so slow?

Attach save file

N/A

Steps to reproduce

N/A

Expected behavior

N/A

Screenshots

No response

Versions and configuration

cdda-windows-tiles-x64-2024-04-16-1009 and earlier versions

Additional context

No response

@IdleSol IdleSol added the (S1 - Need confirmation) Report waiting on confirmation of reproducibility label Apr 16, 2024
@ZhilkinSerg
Copy link
Contributor

Why would the game suggest a longer path?

Move cost for roads is smaller than for off-road overmap terrains (fields, trails and dirt roads):

overmap_path_params overmap_path_params::for_land_vehicle( float offroad_coeff, bool tiny,
bool amphibious )
{
const bool can_offroad = offroad_coeff >= 0.05;
overmap_path_params ret;
ret.set_cost( oter_travel_cost_type::road, 10 );
const int field_cost = can_offroad ? std::lround( 15 / std::min( 1.0f, offroad_coeff ) ) : -1;
ret.set_cost( oter_travel_cost_type::field, field_cost );
ret.set_cost( oter_travel_cost_type::dirt_road, field_cost );
ret.set_cost( oter_travel_cost_type::trail,
( can_offroad && tiny ) ? field_cost + 10 : -1 );
if( amphibious ) {
const overmap_path_params boat_params = overmap_path_params::for_watercraft();
ret.set_cost( oter_travel_cost_type::water, boat_params.get_cost( oter_travel_cost_type::water ) );
ret.set_cost( oter_travel_cost_type::shore, boat_params.get_cost( oter_travel_cost_type::shore ) );
}
return ret;
}

You need to use wheels with bigger offroad_rating on your vehicle if you want to move off-road.

@ZhilkinSerg
Copy link
Contributor

When using vehicles, the speed is reduced to 6 km/h in some locations. On the road, in the field or elsewhere.

Autodrive has speed limits. Read here -

* This file contains code that allows a vehicle to be driven by an in-game character (most

@IdleSol
Copy link
Author

IdleSol commented Apr 16, 2024

Thank you.

Move cost for roads is smaller than for off-road overmap terrains (fields, trails and dirt roads):

And how does this manifest for vehicles? A character that spends more moves. What does the vehicle spend? It travels 19 km/h on asphalt and travels 19 km/h in a field. What's the point? Does it affect fuel consumption?

I know that for some vehicles, there is a maximum speed limit. But that threshold is higher than this 19 kilometers per hour. So what's the point of going down the road?

@IdleSol
Copy link
Author

IdleSol commented Apr 17, 2024

However, sometimes the simplified simulation used to compute the search graph fails to accurately predict where the vehicle will end up. This could be because there was too much error in an approximation (such as time to accelerate) or the driving conditions changed (ran over a mound of dirt that interfered with steering). When such a discrepancy is detected, autodrive will fall back to "safe mode", cutting the speed to the minimum (1 tile per second) and recomputing the path.
Since the navigation graph is cached and not updated in response to dynamic obstacles (such as animals) autodrive will also perform collision detection at every turn, before taking any action that may end the turn. If a possible collision is detected autodrive will enter "safe mode", reducing speed and recomputing. If the speed is already at minimum it will abort instead with a warning message.

If I understand correctly. We get an error or detect an obstacle (animal/zombie). We reset the speed and recalculate the path.

But why do we need to slow down? Maybe I'm missing something. We're not driving in real time. If an error or obstacle is detected, recalculate the path and follow it. Or give control to the player. Only slow down if a collision is guaranteed at the current speed. And there is no way to avoid the obstacle while keeping the speed.

P.S. Why am I thinking of Tesla and its autopilot?

@PatrikLundell
Copy link
Contributor

The reason auto driving speed is limited is because it's hard to make a robust feature that doesn't do the Tesla thing and crashes into something it can't recognize.
Acceleration and (to a lesser extent) deceleration are tricky to predict exactly how large they'll be. A miscalculation results in the vehicle ending up in a different location from where it was predicted to be, thus disrupting the whole path, possibly to the extent that a recalculated path no longer have enough safety margin to an obstacle.
In addition to the issues with the path itself, you also have to deal with the fact that the vehicle doesn't occupy a single tile, but rather several tiles in a configuration that morphs based on the orientation.

You need to slow down when facing obstacles in order to ensure the vehicle ends up exactly where it was intended to end up. There are already issues with partial tile displacement sideways (move one tile sideways every X tiles forward), and you'd compound that if the movement forward is also in partial tiles so you'd have to predict when those partial tiles end up in an extra tile of movement.

If I understand it correctly, the fuel consumption is indeed higher off-road. I also believe (without knowing) that the path finding's road preference is a result of a calculation based on the vehicle's performance over different kinds of terrain without accounting for the limited speed the travel can actually be performed at, so if the travel logic was able to actually travel at maximum safe speed the road would be faster.

Making a 360 degree turn for no reason would obviously be a bug. Making a 360 degree turn due to a mobile obstacle might not be, although it seems odd.

Personally I'm amazed this dog speaks, rather than complaining about the deficiencies in it's speech.

However, if someone steps up to try to improve the logic it would be great.

@IdleSol
Copy link
Author

IdleSol commented Apr 17, 2024

I realize that using a dynamic velocity value, is additional complexity and calculations. That's why the calculation uses 3 tiles per move.

But we have some interesting parameters. Acceleration, braking and top speed off-road. They depend on wheels, engine and maybe something else. But clearly above 3 tiles per turn. Why aren't we targeting them?

Let's say the turns are complicated. Straight sections. Conditionally 5 tiles * 5 moves = 25 tiles or ~1 OMT. Straight sections, in the representation of the function responsible for building the route. That is, sections where there are no turns. And if we go straight, let's add speed. And this speed will be calculated so that the car could stop completely in 1 turn.

Total, turns we pass the old way with 1-3 tiles per turn. Straight sections - 5...8 tiles per turn.

Some tests from the game

Vehicle name Acceleration (characteristic), km/h Acceleration (characteristic), tile/turn Acceleration (real), km/h Braking, km/h Speed, km/h
motorcycle (road) 54 8 54 54..64 -
motorcycle (field) 54 8 28 51..53 72
motorcycle (tall or long grass) 54 8 8 20 / 32 20 / 32
coupe (field) 26 4 26 45...54 -
coupe (road) 26 4 16 43...48 118
coupe(tall or long grass) 26 4 6 37..41 33..57

The spread is most likely due to rounding. It depends on what initial speed the braking starts at. Or it's just a bug. For areas with high and long grass. Apparently they have different effects. But since they are intermixed with each other, it's hard to say for sure.

Summary.

We have a section of straight path for which we know the road characteristics. We can calculate the braking. For a motorcycle, that's 8 tiles per stroke. So we can go up to 54 km/h. Or 20/32 if it's long grass sections. And for the coupe, 35-40 km/h.

@IdleSol
Copy link
Author

IdleSol commented Apr 17, 2024

I don't know if anyone needs this. And maybe it's already implemented, but I don't know about it.

I suggest adding some tools to test path building and automatic movement.

  1. Highlighting the current OMT. For example, using monochrome colors. Or other marking of OMT boundaries.
  2. Color visualization of the constructed path. Colored tiles are overlaid on top of the tiles. For example, of blue color. They denote the path on which the player or transport will move. In general, this is the path that is built in driver.omt_path (if I understood correctly). Ideally, we will have a strip of width from 1 tile to the width of the transport.

Obstacles are highlighted in a separate color, red.

  1. Ariadne's thread. This is the analog of the 2nd point, but it is built only for the part of the car with coordinates (0,0). It is highlighted with a different color (gold, from the golden Ariadne's thread).
    The main difference, it's always one tile wide. For easier perception of the path. Relevant if the transport begins to make loops or "twitch" left-right.

Additionally, you can specify control points: the points of the beginning and end of movement for 1 move. As well as the angle of rotation at these points.

Something like that.
Example

  1. Adding the possibility of automatic movement with confirmation. That is, it's automatic movement, but requiring confirmation from the user every n moves (on OMT boundaries?). Would allow better response to strange car behavior. Or analyze the constructed path.

@Uwuewsky
Copy link
Contributor

Yes, the difference in path costs between roads and fields looks a bit high. It would be nice to change the formula a little since off-road driving isn't that punishing regardless offroad rating of your vehicle.
road1

@IdleSol
Copy link
Author

IdleSol commented Apr 22, 2024

1
Is a hayfield considered not driveable?

Госпорт-trimmed.tar.gz

@ZhilkinSerg
Copy link
Contributor

Is a hayfield considered not driveable?

Check travel_cost_type field in overmap terrain definition. Some terrains are impassable.

@IdleSol
Copy link
Author

IdleSol commented Apr 22, 2024

If I understand correctly

"type": "overmap_terrain",
"id": [ "hayfield_straight", "hayfield_turnL", "hayfield_turnR", "hayfield_end" ],
"copy-from": "generic_rural_building",
"name": "hay field",
"color": "brown",
"see_cost": 2,
"extras": "agricultural",
"looks_like": "ranch_camp_76",
"spawns": { "group": "GROUP_FOREST", "population": [ 0, 2 ], "chance": 15 }

"type": "overmap_terrain",
"abstract": "generic_rural_building",
"copy-from": "generic_city_building_no_sidewalk",
"name": "rural building",
"sym": "#",
"color": "i_brown",
"extend": { "flags": [ "SOURCE_FOOD", "SOURCE_SAFETY", "RISK_LOW", "SOURCE_FARMING" ] }

"type": "overmap_terrain",
"abstract": "generic_city_building_no_sidewalk",
"name": "city building",
"sym": "^",
"see_cost": 5,
"extras": "build",
"mondensity": 2

Nowhere is the travel_cost_type parameter specified. And that's why this OMT is considered impassable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
(S1 - Need confirmation) Report waiting on confirmation of reproducibility
Projects
None yet
Development

No branches or pull requests

4 participants