View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000738 | FSSCP | gameplay | public | 2006-01-21 18:02 | 2006-01-23 14:44 |
| Reporter | Jez | Assigned To | taylor | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000738: The Bastion does not follow mission flightpath in Clash of the Titans 2 | ||||
| Description | In Clash of the Titans 2, the bastion stops around 1500 meters from the node, and procedes to spin slowly on its axis for an indefinite period of time. It does not jump through the node, and so progression beyond this mission is made impossible. | ||||
| Tags | No tags attached. | ||||
|
|
Using the FS2_open version 3.6.7 VPs and the same version launcher |
|
|
I recently had this problem as well. One of three times I played the mission it worked, but that isn't really acceptable. I don't really want to claim this bug but I'll look at it in detail before the weekend is over and see if I can find the problem. |
|
|
Maybe, this info is of no use, or it doesn't have any relationship with this bug. But sometime ago I suffered this kind of error with a GTA Charybdis (very often, it just stopped and started to spin arround). I don't remember the mission nor the mod but maybe it can be a little clue for you (maybe it's an old bug and it's not mission-related at all. (In the mission you had to escort this kind of ship to look for an undetectable vessel or something like that, ... maybe in Derelict) |
|
|
If this is in the 1/16 build, there seem to be a lot of similar AI related problems where the ships don't follow their orders (like jumping out) as expected. In one of my missions, my wingmen are supposed to go after a target but just sit still instead. |
|
|
I think that 1/16 was the first build to have the Enif-station-jump bug fixed. This bug fix changed how like (similar in time and priority) AI orders are handled. This could be related to that but it got past all of my other testing (of which there was quite a bit) so I'm not that quick to blame that particular fix. Thinking the Bastion problem was a possible result of the Enif station fix I debugged it and found that this wasn't the case. Directly at least. The Bastion did depart properly once I killed off one of the friendly escort ships so perhaps it's not the Bastion itself with the problem but is one of the other ships instead. I'll be checking on all of that next. I have seen this strange behavior before, in the icculus.org port of retail, so this isn't necessarily but perhaps newly triggered. If you can post your mission CP5670 (or email it to me) I'll take a look and see if it can help me narrow down the problem. |
|
|
It happens in the 8th mission in the PI dump (http://home.comcast.net/~cp5670/pi.rar). You can see the difference if you compare your wingmen actions at the very beginning in the last version (1/09 I think) and in 1/16. There are a couple of people on the forums remarking that the AI behaves quite differently in this version than it used to, so I think there are several missions that are affected by this issue in some way or another. Maybe I should start a new bug thread on this though, as it might not be related to this one. |
|
|
Found the PI8 problem and that fix will hit CVS later today. I haven't checked yet as to whether or not this is also related to the Bastion issue. |
|
|
Ok, the Bastion problem is unrelated to the Enif bug too. This one is a little more strange though. The problem is that to evaluate a waypoint as being done the ships previous and current positions needs to be > 0.1f. If it's just sitting in one place the the positions are the same and it can never move on to the next waypoint because the current one can't be marked as complete. I haven't figured out why it's doing this yet though. The simple fix is just just add a check on the same line to pass if the distance to the current waypoint and the ships current position is less than MIN_DIST_TO_WAYPOINT_GOAL. This code is basically original though so I'm not sure why [V] didn't do that in the first place. I also haven't found a recent change which would directly break the old behavior, it looks mainly like an old [V] bug and nothing more. Why it gets the this point is the question though so I'm all that happy about making this fix until I understand why it happens. |
|
|
Arr, this be an old :V: bug, dating back to FS1. (Interestingly enough, the FS1 mission where it happens most frequently is the original Clash of the Titans.) The weird thing is that this seems to only happen to large ships. Smaller ones like freighters and fighters always run their waypoints with no problem. I used to think cruisers were invulnerable too until I encountered the bug twice while playing Awakenings. (I think those cruisers were both Leviathans, which move at 10 m/s.) So I'm guessing that it comes from slow-moving ships rather than large ships. I have no idea why it happens though. Perhaps the ships are moving so slowly that one of the movements places it directly on top of the waypoint and you get a singularity. The traditional fix, in FRED, is to add a less-than check to the waypoints-done sexp, so if you did the same in the code it would fix it nicely. It all depends on whether we want to find the root cause. |
|
|
The code fix works well and wouldn't need any mission hacking to work. I think this is coming from a previous goal check that would pass and as the ship is manuevering to hit the next waypoint it stays still just a heartbeat too long and gets caught by the next frame. Anyway the fix is: - if (vm_vec_dist_quick(&Pl_objp->last_pos, &Pl_objp->pos) > 0.1f) { + if ( (dist_to_goal < MIN_DIST_TO_WAYPOINT_GOAL) || (vm_vec_dist_quick(&Pl_objp->last_pos, &Pl_objp->pos) > 0.1f) ) { And it should work in every case. "dist_to_goal" would catch the case where it was pretty much on top of the waypoint, but in a stationary position. The stationary position check is obviously to catch the case where the engines are distroyed or disabled, but if it hit the waypoint at that moment then it will now pass the check still and get ready to process the next waypoint. The only time that this should mess up is when two waypoints are extremely cose to each other. |
|
|
Fix is in CVS so considering this resolved. Reopen if it still messes up, or would appear to cause waypoint problems in other missions. |
|
|
Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-01-21 18:02 | Jez | New Issue | |
| 2006-01-21 18:05 | Jez | Note Added: 0004424 | |
| 2006-01-21 18:59 | taylor | Note Added: 0004425 | |
| 2006-01-21 20:32 | ARSPR | Note Added: 0004426 | |
| 2006-01-22 00:54 | CP5670 | Note Added: 0004429 | |
| 2006-01-22 01:53 | taylor | Note Added: 0004430 | |
| 2006-01-22 05:29 | CP5670 | Note Added: 0004432 | |
| 2006-01-22 12:44 | taylor | Note Added: 0004433 | |
| 2006-01-22 16:33 | taylor | Note Added: 0004435 | |
| 2006-01-22 16:34 | taylor | Status | new => assigned |
| 2006-01-22 16:34 | taylor | Assigned To | => taylor |
| 2006-01-22 22:02 | Goober5000 | Note Added: 0004441 | |
| 2006-01-22 22:15 | taylor | Note Added: 0004442 | |
| 2006-01-23 14:44 | taylor | Note Added: 0004448 | |
| 2006-01-23 14:44 | taylor | Status | assigned => resolved |
| 2006-01-23 14:44 | taylor | Resolution | open => fixed |
| 2006-01-23 14:44 | taylor | Note Added: 0004449 |
