More questions from new scenario designer.

[BadgerDog]

I did look through the printed manual and PDF file first. 😁

 

1.  When I select the options for an RPG based unit as an example, then its ammunition load out, there seems to be some weapons that work (actually fire at enemy) and others that don't?  If I choose ones that have an asterisk beside their name, they work.  If I choose ones with no asterisk, they select fine, but don't actually fire anything when engaging?  Can I assume the asterisked ones are the only ones modeled?

 

2.  Trying to get some custom radio messages to appear.  The manual is pretty straightforward on how to set a control logic "condition", then use an "event" to monitor it going TRUE. If true in the "event", then it should print to the screen radio box the message (white text) I've placed in the event field.   Well, it seems to be hit-n-miss.  Sometimes it does and sometimes it doesn't display the message?  I've checked the "debugger" screen and the conditions are being met and it's recognized by the event, but it's not consistent for the display part of it.  Is this a known bug, or is there something I'm not understanding that would make this function work consistently?

 

Thanks for any guidance. 👍

 

Edited July 27, 2021 by BadgerDog

[Ssnake]

Asterisk in the name indicates a Tandem HET warhead. If all your targets have reactive armor, then RPGs without asterisk "don't work" probably because the enemy armor is considered too strong by the AI, and therefore they hold their fire until some weaker target trundles into the field of fire.

Carets (^) indicate a top attack warhead. Just in case you were wondering.

 

The detour with tying Events to a Condition may often not be required, unless you are referencing a condition by some other party. Hard to make a comment other than in generalities. There's potential to make mistakes in the control logic (happens in the best families), can't entirely rule out a bug (but hopefully not). The more complicated your construction, the greater the chance that the logic isn't what you think it is. The scenario debugger may be helpful in determining which condition is true, when.

[Apocalypse 31]

5 hours ago, BadgerDog said:

that work (actually fire at enemy) and others that don't

Does the RPG have enough penetration power to even damage the tank that its firing at?

 

Quote

how to set a control logic "condition", then use an "event" to monitor it going TRUE

This seems very inefficient unless you're using the condition in multiple events / sides

 

Quote

Sometimes it does and sometimes it doesn't display the message

I haven't had any issues with events displaying Text. Be sure to check your event 'if' statements. 

[Gibsonm]

Badger,

 

Perhaps we can briefly discuss on Thursday night?

[BadgerDog]

On 7/27/2021 at 4:39 PM, Ssnake said:

Asterisk in the name indicates a Tandem HET warhead. If all your targets have reactive armor, then RPGs without asterisk "don't work" probably because the enemy armor is considered too strong by the AI, and therefore they hold their fire until some weaker target trundles into the field of fire.

Carets (^) indicate a top attack warhead. Just in case you were wondering.

 

That's interesting Nils. I didn't know that. 👍

 

That seems to me to be what I'm experiencing.  I didn't realize the AI would be programmed smart enough to avowing even firing using Asterisked RPG's.  Now I know... Thanks.

 

I'll keep that in mind and also I've noted in my manual the (^) top attack indicator.

[BadgerDog]

On 7/27/2021 at 6:44 PM, Apocalypse 31 said:

 

This seems very inefficient unless you're using the condition in multiple events / sides

 

I haven't had any issues with events displaying Text. Be sure to check your event 'if' statements. 

 

1.  Yes, I think you're right partner.  It's too complicated an approach so I've moved directly to just an EVENT as opposed to a CONDITION being monitored then the event.  Thanks.

 

2.  Well, even after I changed and simplified the approach, I'm still getting with the exact same code with no change, that shows messages on one run, then not on another.  No pattern I can find.

 

Follow up question.  I've been using all RED events, even when the action is by a BLUE force.  The only difference I see is changing the "enemy" versus "friendly" reference depending up whether it's BLUE or RED event test, if that makes any sense?  So, is it possible I should be using BLUE event tests for BLUE actions and RED for their actions?  I can't see why that makes any difference, but I was just wondering if that has something to do with messages failing to show?

[BadgerDog]

A comment for Nils to consider for future development... 

 

Some background ... I've been programming since the 1960's (shows my age), starting with Fortran and Hollerith cards feeding IBM Mainframes, then graduated to COBOL, BASIC, C+ and even machine language, with which I wrote a game for the Compucolor Brand of computers in the early 1980s called "Space Invaders". 🤪

 

Much of the scenario development and control logic is essentially a high level coding that compiles in real time before testing.

 

I've used a tool in the past referred to as "code stepping".  In essence, you run the TEST as we do now, but you can use a hot key to stop the execution and a window pops up showing the code step being executed.  You can then hit another key and step one instruction at time, while viewing the code execution on the screen in real time to observe the effect.  It sure was useful debugging what the code is doing to track down illusive code issues.

 

It's nice having the debugger application, but it doesn't really tell me enough except what history has happened to various variables.

 

Anyway, just thinking out loud...

 

Thanks for a great product Nils.... really enjoying being creative with it.

 

 

 

[Ssnake]

Well, there isn't anything about programming that I could possibly tell YOU. If the events aren't triggering, my first guess is that their conditionals don't do what you think they're doing.

I would create a super-simple scenario that replicates (just) the event that doesn't behave and then investigate this "Event primitive" to find out what's wrong with it.

Happy to inspect such a primitive if sent to me by email, I just can't review a large scenario.

[BadgerDog]

15 minutes ago, Ssnake said:

Well, there isn't anything about programming that I could possibly tell YOU. If the events aren't triggering, my first guess is that their conditionals don't do what you think they're doing.

I would create a super-simple scenario that replicates (just) the event that doesn't behave and then investigate this "Event primitive" to find out what's wrong with it.

Happy to inspect such a primitive if sent to me by email, I just can't review a large scenario.

 

Thank you Nils.... 👍

 

I've decided to go back to the beginning and erase ALL "events" and re-do them where events that are caused by BLUE forces are in their own event section and events that are caused by RED forces are entered in their own RED screen area.  It may be pointless, but I need to separate "church and state" from an organizational and clean programming point of view anyway.

 

I think you are right and I'm doing something fundamentally wrong with my BOOLEAN program logic flow. 🙃

 

So, I'll do that first and then I'll see what happens.  Thanks for the feedback.  I'd love to have a "code stepper".....

 

 

 

[Gibsonm]

If you are still unsure / experiencing frustration I should be in a position to resume our sessions on 07 AUG your time.

 

Edited July 30, 2021 by Gibsonm

[BadgerDog]

5 hours ago, Gibsonm said:

If you are still unsure / experiencing frustration I should be in a position to resume our sessions on 07 AUG your time.

 

 

Thanks Mark.. 👍

 

I'll see you then.. same time...