Show Posts
1
Suggestions / Let a UFO's next waypoint be relative to its last rather than absolute
« on: October 31, 2022, 06:59:36 pm »
Suggestion: Add a new optional variable to RegionRule.areas.zone: bool relative. So areas zones can now be defined as [minLon, minLat, maxLon, maxLat, relative], for example [-10, -10, 10, 10, true]. This will make the waypoint +- 10 lon/lat of the UFO's previous waypoint. If relative is not defined, it defaults to false.
Programming considerations: make relative exist in the data. Pass the new "relative" variable to RuleRegion.getRandomRegion. Pass the previous waypoint to getRandomRegion(), which should be the hard part. Add the old waypoint to the return value of getRandomRegion, making sure it doesn't exceed bounds (debatable whether longitude 10-20 = 0 or 10 with latitude flipped, but we could go with 0 for simplicity and the only negative effect would be the feature acting strange around the poles). Ignore relative waypoints when a UFO gets its first waypoint, throw an error when they are all relative. Side note, I have never figured out how to compile OXCE on Windows, mainly due to installing dependencies and not knowing what to do (where the "exe" is) after the instructions are complete.
Why I think this would be nice: Vanilla's zones don't allow you much control over the length of a UFO flight segment, probably the most important variable since XCOM fighters can plot a course in front of the ufo if the length is long, and because it determines the duration of the flight. You can control the average length by repeatedly selecting the same large zone (the length will be about the radius of the zone), e.g. [20, 20, 80, 80], but then it can become obvious that the UFO is not going to leave that square. In general vanilla trajectories need to be very complicated to accomplish the same tasks, while with these trajectories you could use something as simple as [60, 300, -30, 30] for the first waypoint and [-10, 10, -10, 10, true] for every waypoint after that.
Programming considerations: make relative exist in the data. Pass the new "relative" variable to RuleRegion.getRandomRegion. Pass the previous waypoint to getRandomRegion(), which should be the hard part. Add the old waypoint to the return value of getRandomRegion, making sure it doesn't exceed bounds (debatable whether longitude 10-20 = 0 or 10 with latitude flipped, but we could go with 0 for simplicity and the only negative effect would be the feature acting strange around the poles). Ignore relative waypoints when a UFO gets its first waypoint, throw an error when they are all relative. Side note, I have never figured out how to compile OXCE on Windows, mainly due to installing dependencies and not knowing what to do (where the "exe" is) after the instructions are complete.
Why I think this would be nice: Vanilla's zones don't allow you much control over the length of a UFO flight segment, probably the most important variable since XCOM fighters can plot a course in front of the ufo if the length is long, and because it determines the duration of the flight. You can control the average length by repeatedly selecting the same large zone (the length will be about the radius of the zone), e.g. [20, 20, 80, 80], but then it can become obvious that the UFO is not going to leave that square. In general vanilla trajectories need to be very complicated to accomplish the same tasks, while with these trajectories you could use something as simple as [60, 300, -30, 30] for the first waypoint and [-10, 10, -10, 10, true] for every waypoint after that.