2020-08-11 04:57 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001947FSSCPgameplaypublic2020-05-10 17:15
ReporterGoober5000 
Assigned ToGoober5000 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
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.
Attached Files

-Relationships
+Relationships

-Notes

~0011030

Goober5000 (administrator)

Reminder sent to: karajorma

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

~0011032

KeldorKatarn (reporter)

Last edited: 2009-07-01 23: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.

~0011033

karajorma (administrator)

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.

~0011040

KeldorKatarn (reporter)

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.

~0011043

Goober5000 (administrator)

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.

~0011044

KeldorKatarn (reporter)

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.

~0011045

Goober5000 (administrator)

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?

~0011047

karajorma (administrator)

Last edited: 2009-07-04 04: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.

~0011048

KeldorKatarn (reporter)

Last edited: 2009-07-04 11: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.

~0011049

Goober5000 (administrator)

Bah. Bah I say!

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

~0011050

KeldorKatarn (reporter)

Last edited: 2009-07-05 00:04

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

~0011051

karajorma (administrator)

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.

~0014547

Goober5000 (administrator)

Not a high priority, so deferring to 3.7.2.

~0015446

Goober5000 (administrator)

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.

~0016294

Goober5000 (administrator)

Feature request, not critical for 3.7.2.

~0016984

Goober5000 (administrator)

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

~0016995

Goober5000 (administrator)

PR merged.
+Notes

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