Mission timer fails during "events" randomly.

[BadgerDog]

I've done a lot of testing with this and I debated whether it was me, or a code issue with the scenario editor.

 

The steps to duplicate failure (at least for me)

 

1.  Create an event and put a text message in to be displayed.

2.  Set "mission timer" > any value

3.  Run test mode.

 

The message display randomly disappears from functionality without any pattern, the EVENT will not display the message and the mission times goes past the "set time" without anything happening.  This applies to "mission times", or "H-hour time" as well.

 

Added a conditional "AND" statement in addition to  "mission timer" > any value.  Used a unit that was static and never moves to say "if HQ91 is in REGION X" AND "mission timer" > any value.  That did't work either.

 

Exited mission editor and reloaded scenario again.  This time it works with "mission timer" > any value when I run test mode.  I continue programming and adding code, and also continue to run the results in test mode.  By the way and as an aside, if I stay in scenario editor too long doing coding, SB sometimes just crashes to the desktop and I have to restart SB and reload the scenarios.  Maybe a memory leak?  That's a separate issue.

 

At some point doing the "code then run test mode", the "mission timer" > any value fails to display again, as if it doesn't know where the variable for mission timer is, or its value.  If I exit the scenario editor to SB menu and then load the scenario back into the scenario editor and run "test mode", it magically appears... MOST of the time, which I find the lack of consistency odd.  Clean repeatable code doesn't normally do that.

 

Anyway, I'm looking for a way of having an event that says "mission timer" > any value execute and display consistently

 

Thanks for any ideas or thoughts. 😀

 

Edited August 6, 2021 by BadgerDog

[Ssnake]

As far as the crashes are concerned, we're always interested in the Crashdump files (link below).

Other than that, happy to have a look at the scenario, though from your description it sounds so simple that it's hard to imagine how something could go wrong.

Nevertheless, may I ask you to run SB Pro in debug mode for a while, and whenever a test run is inconsistent, end SB Pro immediately and save the log file. Maybe we can read a pattern from a number of such files (though I'm not super optimistic).

Needless to say, I agree: Code should run deterministically.

[Ssnake]

 

[BadgerDog]

2 hours ago, Ssnake said:

As far as the crashes are concerned, we're always interested in the Crashdump files (link below).

Other than that, happy to have a look at the scenario, though from your description it sounds so simple that it's hard to imagine how something could go wrong.

Nevertheless, may I ask you to run SB Pro in debug mode for a while, and whenever a test run is inconsistent, end SB Pro immediately and save the log file. Maybe we can read a pattern from a number of such files (though I'm not super optimistic).

Needless to say, I agree: Code should run deterministically.

 

2 hours ago, Ssnake said:

 

Understood ... I will run troubleshooter and see if I can capture crash logs for you as well.

 

I don't want to burden you or your staff with the actual scenario.

 

Let's see if the logs (if any) show something of value first. 👍

 

[Ssnake]

It's not a "burden". It's an opportunity to learn where things go wrong, and fix them.

[BadgerDog]

12 hours ago, Ssnake said:

It's not a "burden". It's an opportunity to learn where things go wrong, and fix them.

 

Thanks for that , but I want to make sure I'm not the problem first.

 

I decided to run the random failing mission timer scenario as an off line test, outside of the mission editor test mode. 

 

Of course, I have to sit though long waits without the 10x speed up, but after two tries so far, all messages with the timer seem to appear fine. 🤔

 

Conclusion... I have no idea . 🤪

 

I'm going to try some more times in test mode and see if I can find a pattern.

 

Thanks Nils... appreciate the patience and support .

 

 

[Ssnake]

While it shouldn't matter (shoulddawoulddacouldda), time acceleration can yield different results than test runs without it.

[ben]

On 8/7/2021 at 9:00 PM, Ssnake said:

While it shouldn't matter (shoulddawoulddacouldda), time acceleration can yield different results than test runs without it.

I find the time x10 can have drastic effects on vehicle pathfinding and traffic jams!  Luckily I have never seen it effect events/logic or timers though. 

[BadgerDog]

Well, I finally figured it you!!!   I do think it's a code issue, but I could be wrong. 🤪

 

It's a little long explanation, but I'll type it out here when I get a moment.

 

Thanks for all the feedback.. 

[Ssnake]

Thank you very much already for the precious time invested. I appreciate, time is the most valuable thing anyone can spend.

[BadgerDog]

On 8/10/2021 at 10:17 AM, Ssnake said:

Thank you very much already for the precious time invested. I appreciate, time is the most valuable thing anyone can spend.

 

You're welcome ... 😀

 

Thanks for developing such an enjoyable simulation for us "old' tankers.... can you model and add the Sherman M4A2E8? 🤣

 

Sorry for the late response, bit I've been busy with the my scenario creation.

 

I solved the problem and in the process, discovered the underlying cause.

 

Apparently, SB will ONLY show "event" driven messages to the same side and not to other sides.  For example, BLUE events where you can enter an OPTIONAL message in that field, will result in ONLY BLUE players seeing it.  The optional message doesn't appear to the RED side when viewing the scenario from their point of view and even GREEN, although confused as ALLIES don't see them.  This characteristic of messages is not referenced anywhere that I can find in the printed manual, or the PDF.

 

I guess I should have thought about the issue more as it is intuitive, but is confusing because you can type a CHAT message and specify ALL parties.  That confused me.

 

Unfortunately, to effectively create the type of realistic scenario I'm working on, I need a method of being able to SEND an event driven optional message that appears to ALL parties as well.  Actually, what I really need is MORE message slots (>64) because of general messages to ALL I'm trying to implement.

 

Bottom line... is there anyway of turning ON event driven optional messages so they appear for ALL parties?  Or... getting more that 64 slots for a side... or prefixing an event driven message with a special charter that signifies that message should be broadcast to ALL parties?

 

Unless I can find away around this, I'll be limited within my specific approach to scenario creation, so I'd appreciate any help or ideas as to how I can turn ON within the events the send to ALL, like you can manually do in CHAT.  In other words a "Broadcast to ALL parties" type of optional event message.

 

Thanks for any and all feedback. 👍

 

 

Edited September 6, 2021 by BadgerDog

[Ssnake]

56 minutes ago, BadgerDog said:

Apparently, SB will ONLY show "event" driven messages to the same side and not to other sides.

Yeah... interesting suggestion, though.

[Ssnake]

57 minutes ago, BadgerDog said:

Bottom line... is there anyway of turning ON event driven optional messages so they appear for ALL parties?

At this point, only in a cumbersome way. Say, you have Green Event n and you want Purple's players to read the message, you'd create a Purple Event m referencing Green Event n with an identical Purple Event text.

[BadgerDog]

4 minutes ago, Ssnake said:

At this point, only in a cumbersome way. Say, you have Green Event n and you want Purple's players to read the message, you'd create a Purple Event m referencing Green Event n with an identical Purple Event text.

 

That doesn't really solve my problem of freeing up event slots. I would still need an event driven message added to PURPLE that refers to the GREEN event... it's a sum zero game?

 

I need a way of being able to get > 64 BLUE events by utilizing events from GREEN or PURPLE that broadcast a message that can be READ by BLUE side, just like you can by sending to ALL from manual chat mode.

 

Does that explain it better?

 

If could turn ON the manual chat mode to ALL, but in my scenario script code right at the start, that would do the trick.  It's just a switch I presume?

[Ssnake]

1 hour ago, BadgerDog said:

That doesn't really solve my problem of freeing up event slots.

I fully understood that. I'm just saying what's possible right now and what isn't.

Also, as a programmer you probably realize the significance of having 64 events available, and why that can't be easily expanded.

[BadgerDog]

56 minutes ago, Ssnake said:

I fully understood that. I'm just saying what's possible right now and what isn't.

Also, as a programmer you probably realize the significance of having 64 events available, and why that can't be easily expanded.

 

Sorry partner.. 🤕  I wasn't being disparaging about your reply, I was trying to ensure there was clarity to the issue and the incongruity of the event messaging text as it's used in manual chat mode, compared to how it's implemented for generally scripted transmissions.

 

For example, I have GREEN allied with BLUE.  If I send a BLUE text message from a scripted event, it only appears to BLUE. If I send a GREEN text message from a scripted event, it only appears to GREEN ... yet, the two parties are configured as ALLIES, so wouldn't it make sense the message in either case should appear on both BLUE and GREEN channels?

 

Even if it did that, I would gain an extra 64 slots for use without code impact, and yes ... I do understand the code impact of a single byte register (2,4,8,16,32,64... etc).

 

Thanks for clarifying that there aren't any current workarounds.  I'll see what I can accomplish within the current confines.

Edited September 6, 2021 by BadgerDog

[Ssnake]

Chat messages typed by humans in a network session may use the same output window as text messages defined in the mission editor's events, but they aren't the same. That, by default, event messages are confined to the party where they were defined shouldn't be such a big surprise; even where all parties are privy to the same information (which they typically are not) the same incident may carry differen meaning. An Event in the context of SB Pro mission design is a set of conditions within a tactical context; in the simplest case, Red capturing a contested region from a Blue defender, one party's victory is the other's defeat. Having the same message appear for players of both parties would either appear out of place for half of them (Congratulations, tovarisht, the town is ours! For the glory of the Party!), or impersonal and bureaucratic for all ("Region 53 has changed ownership from Party 0 to Party 1, EOT").