Eventing the ability to run out of torpedoes [SOLVED]

[JayIsrael]

Okay - been wrestling with this problem for a while and have resisted asking for help because I felt it was too complex an issue for me to even explain, much less get help with - but here goes.
I have been making a Star Trek fan game. In one part of the game, I developed a first person space ship battle - which I am mostly very proud of. However, I wanted the Enterprise to fire torpedos, but to have those torpedoes run out. I created an event in the corner of the screen where upon pressing the F key (using Yep_ButtonCommonEvents plugin) it would switch on a common event that shoots a heat seeking torpedo toward the enemy ship.
I thought I did the write eventing to ensure that once you have used up your three torpedoes, the game would read that you had none, and not fire a torpedo, but for some reason, it just keeps allowing you to fire. torpedoes, which is a problem as the torpedoes are very powerful and unlimited torpedoes would make the fight too easy for the player. You can re-load torpedoes, but only by asking your tactical officer to do so, and it takes 15 seconds for them to re-load.

Oh, and to explain some of the other eventing in this text, it is set so that the enemy ship has a shield that needs to be decreased, etc.

Anyway - I have included screen captures of my eventing in the hopes that someone can see what I have done wrong.

 

[Andar]

that is a rather strange way to handle events, but your screenshots are missing one part:
where do you give the torpedoes? where do you set the variable?

because most likely that is where your problem is caused, because the torpedoes will fire as long as that variable is greater than zero.
and nowhere you display what the number of torpedoes really is, so that could easily get lost.

 

[Wavelength]

Your eventing is a bit messy, and I think that improper Page switching is the main reason you are seeing this behavior.

Remember that the HIGHEST-numbered page whose Conditions are all met will always be active for an event (so that when it is triggered, only that Page will run, unless this page's contents include commands that will make another page, which is autorun or parallel, be the highest-numbered page whose conditions are met).

In your case, since you set Self Switch A ON, and never turn it back Off, once it's turned On Page 2 will be the only thing that ever runs for this event. And since you don't check for the number of Torpedoes before running your damage processing on Page 2 (which will be activated forever as soon as the Shield is down), at this point you can keep firing forever even into a negative count. Yeah, you turn off the Fire Torpedo switch afterwards, but that just ends the event's processing and your Common Event is turning it back On every time you hit 'F'.

Ideally you should combine the two event pages into a single one (just have a Conditional Branch when you're about to deal damage to know whether to hit the Shield or Hull), but if you want to leave your two-page structure intact, you should change the eventing of your 2nd page to resemble that of your 1st page: put all of the damage processing inside a Conditional Branch that checks Torpedoes, and make sure you are always turning Switch 36 back off at the end of the event (even if you still have Torpedoes).

Additionally, I think you should probably use > 0 rather than >= 0 for the Torpedo checks, so that you can't fire when you have exactly 0 Torpedoes. (Your use of <= 0 for the Hull and Shield are correct, though).

May the Force be w--Live long and prosper.

 

[JayIsrael]

Thank you so much for this response - once I have my brain wrapped around all of this and can try it out, I will let you know.
I had so much concerned that there was no way I would be able to explain the issue I was having because it is an issue in the middle of an already overly complicated set up. I am grateful for your input.

Your eventing is a bit messy, and I think that improper Page switching is the main reason you are seeing this behavior.

Remember that the HIGHEST-numbered page whose Conditions are all met will always be active for an event (so that when it is triggered, only that Page will run, unless this page's contents include commands that will make another page, which is autorun or parallel, be the highest-numbered page whose conditions are met).

In your case, since you set Self Switch A ON, and never turn it back Off, once it's turned On Page 2 will be the only thing that ever runs for this event. And since you don't check for the number of Torpedoes before running your damage processing on Page 2 (which will be activated forever as soon as the Shield is down), at this point you can keep firing forever even into a negative count. Yeah, you turn off the Fire Torpedo switch afterwards, but that just ends the event's processing and your Common Event is turning it back On every time you hit 'F'.

Ideally you should combine the two event pages into a single one (just have a Conditional Branch when you're about to deal damage to know whether to hit the Shield or Hull), but if you want to leave your two-page structure intact, you should change the eventing of your 2nd page to resemble that of your 1st page: put all of the damage processing inside a Conditional Branch that checks Torpedoes, and make sure you are always turning Switch 36 back off at the end of the event (even if you still have Torpedoes).

Additionally, I think you should probably use > 0 rather than >= 0 for the Torpedo checks, so that you can't fire when you have exactly 0 Torpedoes. (Your use of <= 0 for the Hull and Shield are correct, though).

May the Force be w--Live long and prosper.

 

[JayIsrael]

Okay - I tried to put it all on one page. I wanted to double check with you to ensure that I understood what you had advised before i saved this.
Now I have it as an "Else" and I am not sure if the engine will say "Oh yeah - this is 0 torpeodes, so we know what to do" or if I have to be more specific.

 

[gstv87]

put all of the damage processing inside a Conditional Branch that checks Torpedoes, and make sure you are always turning Switch 36 back off at the end of the event (even if you still have Torpedoes).

THIS.
always, when you'll be working with a complex process that needs to trigger other processes, always build the in and out sequence of those processes FIRST, and then the actual processing.
if your process is "get in, talk to the manager, get out" make sure the get in and get out part work as intended, before dealing with the talk to manager part.
otherwise, this happens..... you can't isolate the actual processing from the condition that triggers that process.

 

[Wavelength]

The largest If/Else branch looks good, and I believe this will only allow you to fire on the ship if you have any Torpedoes. Be sure you get rid of Page 2 if you don't need it anymore, because again, the highest numbered page whose conditions are met will run.

However, there are some serious issues in your inner eventing that will cause unwanted behavior. As long as you have any Torpedoes, you are always doing the stuff before the first inner If branch (If Romulan Shield <= 0). Therefore, you will always reduce the Shield (even if it's below 0... which I guess is OK) and you will always turn off Switch 36 (which this page needs to run, which isn't OK.) Even if you remove that Switch OFF command, if the Shield is less than or equal to 0 (including if you just reduced the shield to zero with this torpedo), it will run the second block also, meaning that you are taking 50 health off the hull and taking away a second torpedo from your count. Essentially, you need to separate out the things that should always happen when this event runs, and the things that should only happen under a certain condition.

Here's how I would rewrite it:

If Torpedoes > 0

..Torpedoes -= 1

..If RomShield > 0

....Animation: Hit Effect
....RomShield -= 50

..Else ((this will trigger if RomShield is already 0 or less))

....RomHull -= 50

....If RomHull <= 0 ((this will trigger if the hit reduced RomHull to 0 or less))

......Animation: Hit Fire
......Transparency ON
......Message: "Klingon (Romulan??) Ship Destroyed"

....Else ((this will trigger if RomHull is >0 even after the damage))

......Animation: Hit Effect

....End

..End

Else

..Play SE: Cancel
End

Set Event Location ((I don't know what this is doing in your game, so you may need to find the right place to insert this in one of the above branches, rather than here))
Switch 36 Fire Torpedoes OFF

 

[JayIsrael]

Okay - as shown in the screen capture, I have rid myselfof page 2. I got rid of the "else" and simply had an "If: EntTorpedoes < - 0" then the typical hit animation, with depletion of hull or shield. Then a seperate "if: EntTorpedoes > - 0" then a cancel, and at the end of all of it,turning off the control switch 36.

As evidenced by the video - (the weapon fires even after the torpedoes have been depleted to 0. You can see the torpedo count at the top right corner of the screen ) - nothing seems to have changed in the behavior.

 

[Wavelength]

Your first line is checking If EntTorpedoes <= 0.
It should be checking If EntTorpedoes > 0.

Much later, you are checking If EntTorpedoes >= 0.
It should be checking If EntTorpedoes <= 0.

I'm assuming that the video is from an older test than the screenshot you are showing now, based on the behavior I observed. If this video is showing the behavior from this version, it's possible you have another event somewhere which is being accessed instead of this event. But try the above fixes first.

 

[JayIsrael]

I made the switch you suggested and now when I attempt to fire the torpedoes with 0 torpedoes loaded, a red torpedoe will fly aimlessly with no sound effect, and then will vanish without hitting the Romulan ship. When I try to fire the torpedoes after having loaded 3 torpedoes, the same thing will happen, but it does not register on the HUD that any torpedo has been lost at all (it remains at 3 the entire time).

I am very confused, ha.

Your first line is checking If EntTorpedoes <= 0.
It should be checking If EntTorpedoes > 0.

Much later, you are checking If EntTorpedoes >= 0.
It should be checking If EntTorpedoes <= 0.

I'm assuming that the video is from an older test than the screenshot you are showing now, based on the behavior I observed. If this video is showing the behavior from this version, it's possible you have another event somewhere which is being accessed instead of this event. But try the above fixes first.

 

[gstv87]

naming.

 

[Wavelength]

Ooh, great catch by @gstv87 - you're referencing the wrong variable because you have two variables with very similar names. (Either that, or you're doing something weirder where you're not even looking at a variable in the Conditional Branch.) That would be impossible for us to catch if not for the misspell.

If you're seeing really weird behavior with the Eventing I suggested, it's probably because of further behind-the-scenes mistakes in your setup, and that's going to be really hard to help with because we don't know what your dozens of other events and variables look like.

 

[JayIsrael]

@gstv87 you saved me ! Thank you and @Wavelength for fixing a problem I have been bothered with for months (I was so miffed with this problem that I took a lengthy break from even working on the game). Of course it would be a damn typo. I edit copy for a living, one would think I would be more careful with my spelling.

It now works perfectly. Well - I mean, I still need to change "klingon" to "romulan." Also, I think I need a louder sound effect for when the torpedoes load up, and I think I need to put the instructions on how to fire the torpedoes more up front (as it is now, you only get told that the "F" key fires torpedoes after you ask Chekov to load torpedoes - and the Romulan ship is very hard to beat without having at least a few torpedoes in the fight, so I should probably clue the player in sooner that they'll need to load those).

Anyway - I thank you both from the bottom of my heart and will keep your names in mind for the "special thanks" if this game ever gets finished.

J

 

[slimmmeiske2]

This thread is being closed, due to being solved. If for some reason you would like this thread re-opened, please report this post and leave a message why. Thank you.