View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001604 | FSSCP | multiplayer | public | 2008-02-18 23:39 | 2020-11-01 15:32 |
Reporter | Shade | Assigned To | FSCyborg | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Summary | 0001604: Time to waypoint for AI ships is only displayed correctly for host | ||||
Description | As title. Client players get no time display at all for AI ships under waypoint orders. Replicating: Join any multi game as a client, as long as it includes waypoint orders. | ||||
Tags | No tags attached. | ||||
|
This happens with time-to-dock as well. It does look like it's caused by the new docking code, since AI goals don't get evaluated the same way for multi clients. I can't really figure out exactly how the new docking code progresses so I'm not sure how to even start fixing it. I didn't verify that it actually worked in retail though, so it could be an old bug. It's likely that the two problems are linked, though almost certainly not directly related. |
|
Well in the case of the waypoints issue the cause is that quite simply the waypoint information doesn't exist on the client. It's a null pointer. So the if (aip->wp_list != NULL) { check results in no calculations being done on the client. The simplest solution might be to simply send a packet to the client telling it how much time is left whenever a goal like waypoints or docking is set. Either way this isn't something that I can fix for 3.6.16 quickly so I'm going to unassign it. |
|
Parias, since you did the show-subtitle-text positioning fix for multiplayer, could you take a look at this for 3.7.2? |
|
Heh - I've been looking into this and it seems quite a bit trickier than the "shuffle a few lines of code around" changes I've done so far, but this also looks like an interesting problem to cut my teeth on. I have a few ideas (my findings so far are consistent with karajorma's) so I'll chime in if I hit a blocker. |
|
Parias, any update? |
|
Ack. Sorry for the long wait Goob. This was an awesome learning opportunity in that debugging it took me through the packet handling code, HUD code, AI code, and ship code in all areas... but I was so intimidated by the results that it took me forever to even figure out where to begin. But! I DO have a working solution which turned out to be relatively simple. It's a complete and total hack, but... it works. So far. This provides a fully functional time-to-completion countdown timer for ships performing waypoints that will appear on client systems in multiplayer. It's not perfectly 100% in sync with the host player because I think ships in MP will have slightly different actual velocities, etc on client systems, but it's more or less accurate. I've been hesitant to publish because I need to do some more testing (I haven't validated all use-cases yet and was thinking maybe I could slide in a fix for client-side docking timers too in a similar way, as a bonus) and I don't even know if what I did here is sane. But let me throw up a quick .patch of what I have now so you can see what I've got. Could I get an advisory on if my fix even makes sense, or if there's a better way I should be going about this? I mean it's a bit messy, but I can't argue with the results I've seen... so far. Or on the off-chance this actually does make sense, I'll add some proper comments to the code (once I finish figuring out WHY it works) and fire along a final product that can be added to trunk. |
|
ship.cpp-ai_waypoints_timer_mp_hack.patch (671 bytes)
Index: code/ship/ship.cpp =================================================================== --- code/ship/ship.cpp (revision 11171) +++ code/ship/ship.cpp (working copy) @@ -14515,10 +14515,19 @@ float dist = 0.0f; object *objp; float min_speed, max_speed; + ai_goal *aigp = NULL; objp = &Objects[sp->objnum]; aip = &Ai_info[sp->ai_index]; + if (Game_mode & GM_MULTIPLAYER & !MULTIPLAYER_MASTER) { + if ( aip->mode == AIM_WAYPOINTS ){ + aigp = &aip->goals[aip->active_goal]; + aip->wp_list = find_matching_waypoint_list(aigp->target_name); + aip->wp_index = 0; + } + } + min_speed = objp->phys_info.speed; // Goober5000 - handle cap |
|
This is good thinking but it's not the correct solution. For one thing, as you said, it's a hack. The proper patch should be a fix rather than a Band-Aid. For another, it causes an unintended side-effect. The aip pointer will now leave the function with a wp_list assigned, whereas it didn't have one upon entering the function. The wp_list may have been null for a reason, or it may not -- but in either case it will be an unexpected change to the data structure in a function that should not have changed it. The *minimal* change to the function would involve calculating the time in such a way that the wp_list was not modified (or if it was, it would be set back to null). I'm unmarking this as a 3.7.2 bug and bumping it from trivial to minor due to the difficulty. The proper fix needs to involve hunting through the multiplayer code and finding where clients get their time updates from. Once that code is found, it should be extended for the waypoint and docking cases. One clue as to where to start may be found in Taylor's comment. Since he said "it looks like it's caused by the new docking code", I would start by checking out a version of the code from before the new docking was added and seeing how it handles time-to-dock on the clients. |
|
One quick note - after some digging I've actually been able to reproduce this kind of problem in retail as well, so I think this is definitely a very old bug (anybody recall cases of this working properly for MP clients ever?). Definitely working on a more elegant, less hacky fix for this in any case though - will follow up once I've got it figured out. Appreciate the critique Goob. |
|
Sounds good. And while I haven't confirmed it myself, it wouldn't surprise me if this has been a bug since retail. |
|
So, this is now fixed in the multi Beta builds. There were a couple pieces of information missing on the client side which kept the hud text from being correctly displayed, like which waypoint the ship was heading to. All we had to do was reuse the "target" net signature and put the waypoint's net signature instead. Waypoints moving on the client had to be fixed first, however. In any case, this should be closable once the object update refactor is in. BTW, there's almost no way the client ever had this information, so I'm pretty confident it is a retail bug. |
|
Fixed merged. |
Date Modified | Username | Field | Change |
---|---|---|---|
2008-02-18 23:39 | Shade | New Issue | |
2008-10-19 17:42 | karajorma | Status | new => assigned |
2008-10-19 17:42 | karajorma | Assigned To | => karajorma |
2008-11-04 23:34 | taylor | Note Added: 0010155 | |
2012-12-22 05:48 | karajorma | Note Added: 0014561 | |
2012-12-22 05:48 | karajorma | Status | assigned => new |
2012-12-22 05:48 | karajorma | Assigned To | karajorma => |
2012-12-22 14:20 | MjnMixael | Target Version | => 3.7.2 |
2014-10-09 13:59 | Goober5000 | Note Added: 0016335 | |
2014-10-09 13:59 | Goober5000 | Assigned To | => Parias |
2014-10-09 13:59 | Goober5000 | Status | new => assigned |
2014-10-14 02:30 | Parias | Note Added: 0016337 | |
2014-11-21 04:09 | Goober5000 | Note Added: 0016383 | |
2014-11-21 06:21 | Parias | Note Added: 0016385 | |
2014-11-21 06:21 | Parias | File Added: ship.cpp-ai_waypoints_timer_mp_hack.patch | |
2014-11-21 06:23 | Parias | Note Edited: 0016385 | |
2014-11-21 23:14 | Goober5000 | Note Added: 0016389 | |
2014-11-21 23:14 | Goober5000 | Severity | trivial => minor |
2014-11-21 23:14 | Goober5000 | Target Version | 3.7.2 => |
2015-01-09 00:50 | Parias | Note Added: 0016446 | |
2015-01-09 15:49 | Goober5000 | Note Added: 0016447 | |
2020-09-10 05:20 | FSCyborg | Assigned To | Parias => FSCyborg |
2020-09-10 05:20 | FSCyborg | Status | assigned => code review |
2020-09-10 05:20 | FSCyborg | Note Added: 0017019 | |
2020-09-10 05:21 | FSCyborg | Note Edited: 0017019 | |
2020-11-01 15:32 | FSCyborg | Status | code review => resolved |
2020-11-01 15:32 | FSCyborg | Resolution | open => fixed |
2020-11-01 15:32 | FSCyborg | Note Added: 0017033 |