Jump to content

BadgerDog

Members
  • Posts

    278
  • Joined

  • Last visited

Posts posted by BadgerDog

  1. I uninstalled 4.265 completely.

     

    Then I installed 4.267 and it's now up and running fine for me, including scenario creation and testing.

     

    Went smoothly following the PDF documentation instructions.

     

    Thanks to eSims for the update and bug fixes. 👍

  2. 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.

  3. 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?

  4. 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. 👍

     

     

  5. 3 hours ago, Valleyboy said:

    Just chiming in with some work-arounds, and the below by no means should be considered an official endorsement, but rather conversational input  for the purpose of information sharing given some of the requests expressed here

     

    Thank you Valleyboy. 👍

     

    Appreciate the input.... very helpful. ;)

  6. On 8/11/2021 at 2:28 PM, mrivers said:

    I'm sorry, this feature was intended for internal use and severely limited in function.  It is completely disabled.

     

    Ok, just checking the EVENTS options and there is a "Play Media" selection, which refers to a sub-directory called "media/".  I put an MP4 file in there but when I choose the option to select and load the media file, no files appear at all?

     

    Can I assume that this function is for internal use only as well, which is why it doesn't appear to work?'

     

    Thanks ... 🤔

  7. 1 hour ago, Ssnake said:

    Like I wrote, errors that are reported to me are immediately updated in the User's Manual, and the User's Manual PDF is updated with regularity when you install a new version. What the installer doesn't do is removing obsolete versions of the manual, and since the "User's Manual.pdf" has always the same name across versions and time, if you have multiple versions of SB Pro installed confusion about which is the latest may occur (but I don't think that this was the case in the original request).

     

    Nils... I understand and I agree with the issue of trying to keep printed bound manuals up to date, but even the PDF shows this as a usable function/feature. ;)  .. but I think Mark's suggestion is a good one as a compromise.

     

    As an aside, I just find it so convenient to sit back in a chair and read an actual current and bound hard copy, which I for one am willing to pay for.

     

     Regardless, as Mark always says "... it's all good!"... 😀

     

     

  8. 2 hours ago, Ssnake said:

    Yes. Like I wrote, the 4.2 manual version doesn't even mention the function anymore, so I suppose once that a new patch is made available (or an upgrade to 4.3, whichever is first) you'll receive the latest manual with it.

     

    I like using the multi-ring soft cover version.  Can we order that from eSims when the next iteration of the manual come out?

     

     

  9. 12 hours ago, mrivers said:

    I'm sorry, this feature was intended for internal use and severely limited in function.  It is completely disabled.

     

    Ahhh... thanks for letting me know. 👍

     

    I won't wasted any more time trying to make it work. ;)

     

    Perhaps the manual needs to be updated to reflect that. 

  10. Thanks Nils ... 😀

     

    For clarity and as a reference to others, I just did a lot of testing on this issue. ;)

     

    It is not a "dozer blade". It's still called a "mine plow" as it's currently mounted using v4.265, on tanks ie: M1A1 (HA) or a Wisent (standard or wide version plow).

     

    The clearing of "steel beam" obstacles is accomplished using the "pop -up menu" in the bottom right screen and selecting option "breach to ..."  A 5 sided arrow symbol appears on screen and you place it at a distance (left click) ahead and after "steel beam" obstacle.  The tank (or Wisent) then moves forward and breaches the "steel beam" and the path is now clear.  The Wisent leaves red signs and flags behind marking where it went through, whereas the tank does not.

     

    Hope this helps... 😀

  11. 2 hours ago, Ssnake said:

    I'm wondering if this means Ctrl+Shift+F12 (by default), as Shift+F12 is the default hotkey for a simple screenshot.

     

    I just tried Ctrl+Shift+F12 and a red text message came up saying "image saved", although I can't find it and I suspect it's just a screenshot anyway.

     

     

  12. Tried this, but perhaps I'm doing something wrong. ;)

     

    Page 123 of manual says Steel Beams can be "can be breached with mine-plow equipped tanks."

     

    Tried this in test mode with M1A1(HA) equipped with a mine-plow and I couldn't move it?  Tracks just spin but it doesn't move.

     

    Am I missing something?

     

    I did discover that you can push a destroyed status T72 tank off a bridge it was blocking, using another tank. 😁

     

    Very nice realism feature. 👍  Thank the programmer for building that into the code. ;)

     

     

  13. 20 minutes ago, Ssnake said:

    The Camera Animation Window, on the other hand, gets used with regularity.

     

    Thanks Nils... 🙂

     

    I am in test mode and I was trying the camera animation window, which works great while viewing from within its window.

     

    Unfortunately, I can confirm that that viewed animation can't be saved as an AVI with the CTRL-PRTSCRN key combo as per the manual on page 106.

     

    No worries .. it's not mission critical for what I'm trying to do anyway. ;)

     

    Thanks .. :)

     

     

     

  14. Manual and PDF says use CRTL-PRTSCRN key combo to switch from capturing Screenshot mode to AVI format.

     

    I can't seem to get it to do that?  It just captures a screen image with that key combo?

     

    Am I missing something or has the function changed, or just doesn't work?

     

    Thanks for any feedback. 🙂

     

     

  15. 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 . ;)

     

     

  16. 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. 👍

     

  17. 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. 😀

     

  18. 3 hours ago, Ssnake said:

    Not sure if the 106mm gunner is "crew", or got lost during the spawn as a "passenger".

     

    I hadn't thought about that.. could be.  Regardless, make sure you let the development team know that they've done a fantastic job, even partially complete.

     

    This function and its features with all the little BOT options makes the ability to create scenarios with scripted storylines, and in my opinion makes SB much more interesting.

     

    I'll delete the 106mm for now and work with the Milan. ;)

     

  19. On 8/4/2021 at 5:24 PM, Ssnake said:

    If they belong to a hostile party and not a neutral or friendly one, and if the prototype isn't set to be blind or impotent - then yes, they will move in a very predictable and non-tactical way, but open fire if given the chance.

     

    Nils.... 😀

     

    Update... I discovered that the BOT defined as a Milan weapon does indeed engage, however, the 106mm Recoilless does NOT, even though it's set with fire control to engage (and with ammunition quantity set), and on normal.

    Not sure if this is a "bug", or there's something else I need to do to get it to behave and engage like the Milan BOT does. ;)

     

    Hope this helps and is productive. 👍

×
×
  • Create New...