|
|
|
|
|
subtitle-crash-debug.PNG (98,490 bytes) |
|
|
subtitle-crash-2.PNG (64,113 bytes) |
|
|
Wanted to mention as well - this may have some relation to issue 0003050 which is the same sort of error and problem (game crashes with a "stack was corrupted" error because a given value seems to be too long) - although I'm not sure if the relation goes any deeper than that given the disparate nature of the symptoms. |
|
|
Sorry for the spam - one more update. On a casual whim I decided to try changing char text [TOKEN_LENGTH] in multi_sexp_show_subtitle_text() to char text [256] instead (to match sexp_show_subtitle_text()). This fixed the client-side crashing, and even enables the text to actually appear client-side in it's entirety, which is awesome! I'm really not sure on the implications of this though (since TOKEN_LENGTH - hard-coded at 32 - is referenced just about everywhere I'm assuming there was some multiplayer-specific significance in using it here) - the game seems to run just fine when the event triggers with this large a value, but I do notice a few formatting inconsistencies... i.e. width doesn't seem to be properly respected, so text is arranged oddly compared to the host system (and even gets completely jumbled up if you're connecting to a standalone server). If I had to guess, I'd wonder if the check for width (which works as a percentage, I think?) is being calculated by the host system and is then fired out, rather than each client calculating it independently. I might be wrong though and need to do more testing. I'll try to avoid rambling on for much longer, but if I find anything else that might be useful towards making this work correctly in multiplayer I'll post an update. Edit: Yup, if I'm reading sexp.cpp right, that's exactly what happens. The pixel positions are calculated on the host in sexp_show_subtitle_text, and are then received by multi_sexp_show_subtitle_text. I'd like to think it wouldn't be a big deal to set up some local functions in multi_sexp_show_subtitle_text to check this stuff locally, but I'd like to defer to some expertise first. |
|
|
Pinging karajorma for his multiplayer expertise... |
|
|
I'm not going to be able to look at this for a couple of weeks unfortunately. However any increase in the size of TOKEN_LENGTH is likely to have a very nasty knock on effect on another (so far minor) bug if that constant is also used in multi_sexp.cpp. Try making a single SEXP make multiple calls to the string sending fuctions so that more than 512 bytes needs to be sent. I suspect you'll crash the game. In fact I'm pretty damn sure you will. |
|
|
Thanks for commenting karajorma. Sorry as I might be misunderstanding -- "....any increase in the size of TOKEN_LENGTH is likely to have a very nasty knock on effect on another (so far minor) bug if that constant is also used in multi_sexp.cpp. " I'm actually not making any changes to the fixed TOKEN_LENGTH value in globals.h (where I think it's defined?), but instead I'm just changing the "char text[]" line in multi_sexp_show_subtitle_text() from [TOKEN_LENGTH] to [256] instead. The TOKEN_LENGTH define in itself is untouched and left at 32, so everything else calling it would be unaffected. Is this what you're referring to as potentially causing other issues? And could you provide an example on how I'd get the string sending functions to fire more than 512 bytes at a time? Right now I've got multiple show-subtitle-text SEXPs firing at the same time in an event (up to four, each with generally 200+ characters of text on average) and so far it seems to be working OK. I'm not sure if the way I'm doing it is breaking up the traffic into multiple packets though. |
|
|
Sorry, meant to reply to this one earlier. I think your fix can be implemented as is. I was speaking more generally about the multi_sexp code. There is a rather nasty bug in it which this may or may not expose. I suspect in this case you'll probably get away with it. |
|
|
Cool! No worries. I've been doing a lot of host + client testing (between two disparate systems on a local network) with this change in place as well, and so far have not seen any signs of stability or functionality problems caused it. My own local testlab is of course a bit limited and we may see different results over the long-term, but so far I think this should work OK. Thanks for following up. There's still an issue I see as well with the height / width calculations for this function being done exclusively "host-side" (which leads to really weird results in terms of subtitle positioning if the host and client are running very different screen resolutions), but I'm going to submit this as a separate report after I have a chance to investigate it more thoroughly and perhaps propose a fix. |
|
|
Yes, the underlying issue is that that code the stuffs a subtitle into a SEXP multiplayer packet -- sexp_show_subtitle_text() -- allows the packet to contain up to 256 chars whereas the receiving code -- ------- void sexp_show_subtitle_text(int node) { int i, n = node; char text[256]; ... } and void multi_sexp_show_subtitle_text() { int x_pos, y_pos, width=0, fontnum; char text[TOKEN_LENGTH]; // Currently defined as 32 chars ... } ------- Regardless of the length we choose, both the sending and receiving function should use the same #define length for the sending and receiving array. |
|
|
Based on Echelon9's detective work, I think I know what happened. Originally, the sexp could only display the text entered into the actual sexp node. This is limited to TOKEN_LENGTH. At some point, show-subtitle-text (or maybe show-subtitle before it) was modified to allow subtitles to be obtained from messages, which can be longer than TOKEN_LENGTH. But the corresponding multi sexp wasn't updated accordingly. |
|
|
Fix committed to trunk@11034. |
- Anonymous
