Source Code Project Mantis - FSSCP
View Issue Details
0001874FSSCPgameplaypublic2009-01-23 14:282009-07-03 18:13
ReporterTolwyn 
Assigned ToGoober5000 
PriorityhighSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.6.11 
Summary0001874: invisible characters ('#') do not work properly in fs2_open_3_6_10r-20090120_r5052
DescriptionEverything after the '#' character should be hidden by the engine. In the current build however, every single character shows up in the subtitles, so we end up with something like this:

KIS BlahBlah#D: text
TagsNo tags attached.
Attached Filesjpg comm#.jpg (13,199) 2009-01-24 03:51
http://scp.indiegames.us/mantis/file_download.php?file_id=1218&type=bug
jpg

Notes
(0010598)
Goober5000   
2009-01-24 01:23   
What do you mean, they don't work properly? Somebody (IIRC Shade or Backslash) spent a great deal of time going through the code to make sure they *would* work properly. And they work for me. So if they don't work for you, I'd appreciate it if you made a list of places where they don't work, instead of making a generalization.

Now, are you saying that subtitles are one of the places they don't work? Show-subtitle, perhaps?
(0010601)
Tolwyn   
2009-01-24 03:53   
Like this. And I know that this worked before.

single comm message: syntax: #kis shipname#invisible character (in other words: death message is sent in the same manner as the usual command message. Not sure if it is related though)
(0011000)
KeldorKatarn   
2009-06-26 13:01   
-This is a Saga showstopper-
(0011004)
Goober5000   
2009-06-26 13:42   
...Wait. You're using two pound signs? So, if it were a FreeSpace campaign, it would be like this?

#Command#GTVA: Enemy wing has just arrived!

And you're saying that you see Command#GTVA where you expect to see Command?

If that's the case, that's not a bug. The # symbol, when used at the beginning of a string, is an escape character. It instructs the game to display the message source exactly as typed, whether or not it contains another #.

The solution is very simple: Just write #Command. There's no need for #Command#GTVA.

Please confirm that I have the correct interpretation, as this Mantis bug doesn't contain much detail.

(0011010)
KeldorKatarn   
2009-06-28 20:14   
(Last edited: 2009-06-28 20:16)
We entered this as a bug since it was originally working and was later revised in the code.
We did use this for death screams. If there is a ship

KIS Whatever

and we have an even that triggers a message once the ship is destroyed, that message will not be sent, since destroyed ships don't send any messages anymore (this is valid behavior).
So we had to use #KIS Whatever#dead instead, which as I mentioned, worked and got broken later.

Btw.. the suggestion to use #KIS Whatever doesn't work. The game recognizes that as an existing ship name (possibly because it simply looks for the message source by string comparison), looks for that ship, sees it is dead, and again doesn't send the message. So we needed to add something invisible to the name to distinguish it from the ship that just died.

In principle we don't need this anymore since Karajorma now helped us with an implementation that lets capships have a deathcry by persona if the "always scream on death" flag is set. This is however now the only possibility for us to give capships a death scream so we can only work without THIS solution if that flag usage remains 100% intact. if we get a confirmation that we can rely on this "always scream"-flag -> capship-uses-persona-deathscream feature, then this can be closed. But please give us such a confirmation first and inform the team, because we will heavily rely on that later and a change of this later on will break Saga.

(0011014)
FUBAR-BDHR   
2009-06-28 23:39   
Wait so in a send-message sexp you have #shipname as the source and it doesn't send if shipname is destroyed? Isn't # in front of a message source supposed to be special source ignore checks to start with?

Even the Wiki agrees: http://www.hard-light.net/wiki/index.php/Retail_SEXPs#send-message

although the original FRED docs don't go any further then #command
(0011015)
Goober5000   
2009-06-28 23:52   
Okay, well then the bug is that #shipname does a check for shipname. That is a legitimate bug that we should fix.

This is another instance where you guys at WCS need to say *what the problem is*, instead of *what you think we should do*. :p
(0011019)
Tolwyn   
2009-06-29 03:29   
I told karajorma, that the message code was broken a few times, but he wouldn't listen... ;)
(0011020)
KeldorKatarn   
2009-06-29 09:59   
Do you want me to open a new ticket with a new description of the problem?

(Btw.. I didn't report it in that way because I didn't know that was supposed to work. I don't ever remember being able to use #Shipname if Shipname was a destroyed ship. So I didn't know that wasn't supposed to be like that.)

Also be careful when trying to fix this.. the game engine is probably doing a simply string lookup, so you best keep the # inside the shipname when doing the message sender lookup. If you just look for Shipname you'll always find something which would force you to use a different method of identification and that would have huge implications. So you better don't remove the # at all, and simply change the display code so it ignores anything behing a # if the # is somewhere in the middle of the name (starting at index 1) and ignore the # and write the rest, if it is the first character of the name.

This can potentially be a tricky fix since the code is so spread around, so be careful here. I'd offer my help but I'm working on some other code already, trying to get those stupid custom gauges to behave :P
(0011021)
Goober5000   
2009-06-29 10:23   
Generally, the only time you should open a second ticket is if there is a second issue (like the cutscene bars report). We want to avoid a single ticket having a forking tree of numerous issues.

In this case, there is only one issue: the invisible character bug. So even though it's not exactly what was reported, there is a clear relationship from what was reported to what will be fixed. Plus you can follow the discussion.

I'll prioritize this. Hopefully I'll have it fixed by the end of the day.
(0011024)
Goober5000   
2009-06-29 23:33   
Okay, should be fixed. Check the next nightly build that includes revision 5383.
(0011041)
KeldorKatarn   
2009-07-03 18:02   
Tested. Seems to work.
(0011042)
Goober5000   
2009-07-03 18:13   
Awesome. Marking as fixed.

Issue History
2009-01-23 14:28TolwynNew Issue
2009-01-24 01:23Goober5000Note Added: 0010598
2009-01-24 03:51TolwynFile Added: comm#.jpg
2009-01-24 03:53TolwynNote Added: 0010601
2009-06-26 13:01KeldorKatarnNote Added: 0011000
2009-06-26 13:08portej05Prioritynormal => high
2009-06-26 13:42Goober5000Note Added: 0011004
2009-06-26 13:42Goober5000Statusnew => assigned
2009-06-26 13:42Goober5000Assigned To => Goober5000
2009-06-26 13:42Goober5000Note Edited: 0011004
2009-06-28 20:14KeldorKatarnNote Added: 0011010
2009-06-28 20:16KeldorKatarnNote Edited: 0011010
2009-06-28 23:39FUBAR-BDHRNote Added: 0011014
2009-06-28 23:52Goober5000Note Added: 0011015
2009-06-29 03:29TolwynNote Added: 0011019
2009-06-29 09:59KeldorKatarnNote Added: 0011020
2009-06-29 10:23Goober5000Note Added: 0011021
2009-06-29 23:33Goober5000Note Added: 0011024
2009-07-03 18:02KeldorKatarnNote Added: 0011041
2009-07-03 18:13Goober5000Note Added: 0011042
2009-07-03 18:13Goober5000Statusassigned => resolved
2009-07-03 18:13Goober5000Resolutionopen => fixed
2009-07-03 18:13Goober5000Fixed in Version => 3.6.11