Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: TopAce on May 29, 2010, 03:20:36 pm
-
A debriefing stage is limited to 2,000 characters. You can exceed this 2,000-character limit in a debriefing, but you need to use more than one debrief stage to do that.
I stumbled on this limitation when I expanded one of my debriefing in WordPad, and found that the game engine and FRED could no longer open it.
It's 100% reproduceable, but I have only one comp to test it with, so I need confirmation whether this limitation is indeed there, or it's simply my comp that's not powerful enough, which I doubt.
-
Sure it's not 2048? Think just about every section in FRED has a limit of either 2048 characters.
-
I'm not sure, but at 2,100 characters, it certainly crashes.
-
Sounds about right. That's surely a fixed size buffer limit in the engine. We're working on getting rid of as many of those limits as possible as the FS2 Open codebase slowly adopts C++ features.
-
I think that it shouldn't be too high priority now, if a debriefing stage is a 2048 characters wall of text, it should be broken into stages anyway.
-
I think that it shouldn't be too high priority now, if a debriefing stage is a 2048 characters wall of text, it should be broken into stages anyway.
The problem is that you don't know what's wrong because the game crashes without an informative error message. If you run the game immediately after changing the debriefing, and only the debriefing, then you'll figure out what's wrong. Otherwise, you may suspect that something else is going wrong, say, with a ship or an event. The debriefing is the last place you'd look for possible errors.
-
I think that it shouldn't be too high priority now, if a debriefing stage is a 2048 characters wall of text, it should be broken into stages anyway.
The problem is that you don't know what's wrong because the game crashes without an informative error message. If you run the game immediately after changing the debriefing, and only the debriefing, then you'll figure out what's wrong. Otherwise, you may suspect that something else is going wrong, say, with a ship or an event. The debriefing is the last place you'd look for possible errors.
A crash with no error even with a debug build?
-
I get an error message that complains about insufficient memory. It's a Windows in-built message, not an FSO one.
-
I could be using strcpy instead of strcpy_s or something.
-
I think that it shouldn't be too high priority now, if a debriefing stage is a 2048 characters wall of text, it should be broken into stages anyway.
Yea but it's a real pain in the butt for events. They have the same limit.
-
Ah, so there is a limit for amount of events in mission.
Then, it should be dealt with.
-
Has a Mantis bug been filed for it? If so, what is its number? If not, can someone file one, with an example mission that causes the crash please?
-
Ah, so there is a limit for amount of events in mission.
Then, it should be dealt with.
Correction: It's not a limitation in events, but in nodes. In other words, there is a limit as to how many lines your events can altogether take up in the mission file.
-
Well, that also limits the amount of events.
But limitation in nodes means that it's more strict, which is bad.
-
Errm, no?
Seriously, chances are you're going to have to do some pretty elaborate sexping before you hit either of those limits, and events can always be split into several parts. You just have to use them intelligently.
-
I exceeded the limit once in retail. Never again with FSO. Node limitation isn't a very big problem.
For reference: There are 106 events in Mystery of the Trinity. Most simply send a message using a single send-message instead of one event triggering one big send-message-list. That's a waste, but it still works!
-
I exceeded the limit once in retail. Never again with FSO. Node limitation isn't a very big problem.
For reference: There are 106 events in Mystery of the Trinity. Most simply send a message using a single send-message instead of one event triggering one big send-message-list. That's a waste, but it still works!
Send-message-list can be kind of problematic. I stopped using it and switched to chained single events a while back.
I have hit the event size limit quite a few times during War in Heaven development. It can be pretty irritating at times.
-
I've got an event that sends 30 consecutive messages with one send-message-list. FRED didn't complain. Unless you want some happening break the chain of messages (someone dies, something arrives, player presses a button, etc.), I don't see why a lot of chained events are better than one big one.
-
Pretty much that. With chained events, you have much finer control over when and where messages are sent, not to mention that you can use things like is-event-true-delay on chain elements to trigger things in the mission.
-
I've got an event that sends 30 consecutive messages with one send-message-list. FRED didn't complain. Unless you want some happening break the chain of messages (someone dies, something arrives, player presses a button, etc.), I don't see why a lot of chained events are better than one big one.
The two big problems with send-message-list aren't the length (I've never had a problem with that) but:
1) As The_E said, it's much easier to have events during the conversation without kludgy timing.
2) Editing. My god does send-message-list render editing frustrating. You can only delete the very last string in the SEXP's data, so it's impossible to selectively prune a single message from the middle of the list.
That's why I switched. But send-message-list is a useful tool, and I'm not saying you absolutely should switch either. They both have their place, and really, it's up to the comfort of the FREDder.
-
2) Editing. My god does send-message-list render editing frustrating. You can only delete the very last string in the SEXP's data, so it's impossible to selectively prune a single message from the middle of the list.
Yes, editing is problematic. I can't disagree with that.
-
It's very easy to hit the size limit per event when using when-argument. You can eat up that 2048 characters real quick.
I believe I did file a Mantis report on this way back. http://scp.indiegames.us/mantis/view.php?id=1852 Probably need the same type of check for other areas.