View Issue Details

IDProjectCategoryView StatusLast Update
0001947FSSCPgameplaypublic2020-05-10 21:15
ReporterGoober5000 Assigned ToGoober5000  
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Summary0001947: Need to make comm system consistent for other ships
DescriptionIt just occurred to me (and I confirmed via a test mission) that the comm system does not seem to apply to one's wingmen. You can issue them orders, they can issue praise, etc., even if they have a dead comm system. This should be fixed.
TagsNo tags attached.

Activities

Goober5000

2009-07-01 05:50

administrator   ~0011030

Reminder sent to: karajorma

Pinging karajorma as he'll undoubtedly have something to say about this.

KeldorKatarn

2009-07-02 03:27

reporter   ~0011032

Last edited: 2009-07-02 03:27

From what i could see in the code no ship at all is effected, including capships.
Aside from weapons and engines no destroyed subsystem affect any ship but the player.

karajorma

2009-07-02 17:26

administrator   ~0011033

Problem is that you could have quite a big effect on gameplay changing this. Every single mission written so far has always been based on the assumption that you could order your ships around unless forbidden from doing so via FRED.

Any mission which relies on you being able to order your wingmen around could potentially break on this one. And I really don't know what to do about cases where one person in a wing has broken comms and you give orders to the entire wing. Cause having them blithely carry on doing whatever is just as wrong as having them mysteriously able to hear the order.

KeldorKatarn

2009-07-03 21:55

reporter   ~0011040

Exactly. I'd stay away from changing this. Making AI ships unable to communicate doesn't really help gameplay but can potentially break a mission to great frustration to the player. I'd leave this as-is. Maybe one could scramble the comm window animation if the comm system is gone, but not the sound and the text.

But I'd vote for not doing anything about this. This is Working As Designed. And changing it doesn't really improve gameplay. I doubt any player enjoys his wingmen being unable to communicate just because it is more realistic.

if the realism part bothers anyone ingame simply guardian the subsystems so they can only be damaged but not destroyed.

Goober5000

2009-07-04 01:20

administrator   ~0011043

Except that this isn't a gameplay breaker. The player has to cope with wingmen events that happen during the course of a mission. If one of his wingmates get disabled, the player would have to deal with it. It should be no different if one of his wingmates has his comm system disabled.

Furthermore, in both cases, the wingmate is perfectly capable of calling in support.

KeldorKatarn

2009-07-04 01:34

reporter   ~0011044

It is a gameplay breaker for Saga and it will probably be for many other mods. So if you do this, activate it by flag only.

otherwise we'd pretty much have to subsystem.guardian every single ship in our missions.

Goober5000

2009-07-04 02:05

administrator   ~0011045

It's not a game-breaker because the chance of any fighter having its comm system knocked out is approximately the same as the chance of the same fighter having its engine subsystem knocked out.

Do you subsystem-guardian every engine system for every ship in every mission in WCS?

karajorma

2009-07-04 08:42

administrator   ~0011047

Last edited: 2009-07-04 08:42

While the chance of having comms knocked out may be the same as engines, the effect knocking comms out has on the game currently is none.

The effect it would have after this change is not none. How large that would actually be remains to be seen but it is worth bearing in mind that since the game has not been balanced with this in mind there may be ships out there with comm systems that are exceedingly easy to knock out. The example of how it's easy to disable Nials in TBP comes to mind but in that case it's always been a well known thing and thus has always been part of the mission design.

In this case we'd suddenly be adding a factor that can make the game harder out of nowhere. The argument that the ship can call in support is of no use to mods and campaigns which didn't include support.

KeldorKatarn

2009-07-04 14:43

reporter   ~0011048

Last edited: 2009-07-04 15:12

"Do you subsystem-guardian every engine system for every ship in every mission in WCS? "

Yes. We do for all friendly ships! And we'd have to do this with comms for ALL ships.

Btw Goober. It is really amazing that I get along great with SCP as long as you are gone. This kind of attitude towards the mods "I don't care if it breaks you and I know better anyway" is REALLY getting on my nerves.

if I tell you it will break Saga then that's a fact and not open for opinion polls.

Goober5000

2009-07-04 19:46

administrator   ~0011049

Bah. Bah I say!

Okay, I'm going to add this as an ai_profiles flag.

KeldorKatarn

2009-07-05 04:03

reporter   ~0011050

Last edited: 2009-07-05 04:04

How about leaving it alone and working on bugs until someone actually asks for this and uses it?

karajorma

2009-07-05 13:50

administrator   ~0011051

In that case I'm asking.

While I might be worried about backwards compatibility I have no problem with this being an inclusion in missions from now on.

Goober5000

2012-12-20 04:04

administrator   ~0014547

Not a high priority, so deferring to 3.7.2.

Goober5000

2013-11-21 05:54

administrator   ~0015446

I've created a comm_between_player_and_ship() function as part of the scramble-messages enhancement. This could be used in the future to regulate communications from AI-controlled ships. It already has a hook to add a future AI profiles option.

Goober5000

2014-09-24 06:41

administrator   ~0016294

Feature request, not critical for 3.7.2.

Goober5000

2020-04-27 22:13

administrator   ~0016984

PR posted: https://github.com/scp-fs2open/fs2open.github.com/pull/2342

Goober5000

2020-05-10 21:15

administrator   ~0016995

PR merged.

Issue History

Date Modified Username Field Change
2009-07-01 05:49 Goober5000 New Issue
2009-07-01 05:49 Goober5000 Status new => assigned
2009-07-01 05:49 Goober5000 Assigned To => Goober5000
2009-07-01 05:50 Goober5000 Note Added: 0011030
2009-07-02 03:27 KeldorKatarn Note Added: 0011032
2009-07-02 03:27 KeldorKatarn Note Edited: 0011032
2009-07-02 17:26 karajorma Note Added: 0011033
2009-07-03 21:55 KeldorKatarn Note Added: 0011040
2009-07-04 01:20 Goober5000 Note Added: 0011043
2009-07-04 01:34 KeldorKatarn Note Added: 0011044
2009-07-04 02:05 Goober5000 Note Added: 0011045
2009-07-04 08:42 karajorma Note Added: 0011047
2009-07-04 08:42 karajorma Note Edited: 0011047
2009-07-04 14:43 KeldorKatarn Note Added: 0011048
2009-07-04 14:44 KeldorKatarn Note Edited: 0011048
2009-07-04 15:12 KeldorKatarn Note Edited: 0011048
2009-07-04 19:46 Goober5000 Note Added: 0011049
2009-07-05 04:03 KeldorKatarn Note Added: 0011050
2009-07-05 04:04 KeldorKatarn Note Edited: 0011050
2009-07-05 13:50 karajorma Note Added: 0011051
2012-12-20 04:04 Goober5000 Target Version => 3.7.2
2012-12-20 04:04 Goober5000 Note Added: 0014547
2013-11-21 05:54 Goober5000 Note Added: 0015446
2014-09-24 06:41 Goober5000 Note Added: 0016294
2014-09-24 06:41 Goober5000 Severity minor => feature
2014-09-24 06:41 Goober5000 Target Version 3.7.2 =>
2020-04-27 22:13 Goober5000 Note Added: 0016984
2020-04-28 05:22 Goober5000 Status assigned => code review
2020-05-10 21:15 Goober5000 Status code review => resolved
2020-05-10 21:15 Goober5000 Resolution open => fixed
2020-05-10 21:15 Goober5000 Note Added: 0016995