Rapid fire torpedo launcher not reloading completely

[Anew9]

Also, maybe try 0 for both SetMaxReady and SetReloadDelay for the duplicate forward launcher. I still have a feeling the problem will be found outside the hardpoint file. I will see if I can look for clues in other files.

Tried that already - didn't work

[Anew9]

Also, maybe try 0 for both SetMaxReady and SetReloadDelay for the duplicate forward launcher. I still have a feeling the problem will be found outside the hardpoint file. I will see if I can look for clues in other files.

No luck.

I also noticed that this bug affects my other rapid-fire launcher as well, irregardless of whether it is fired first or not - it's just not as predictable as it is for the forward launcher.

[Tethys]

I came across an interesting file; ConditionTorpsReady.py

SetStateFromTorpCount and the def's below may be something to look into playing around with, and see if you have any luck manipulating an outcome. At least then we would know if we're on the right track. Looks promising to me, many scripts seem to use conditions, if we're lucky, adding a check to or editing one of the def's could fix the bug.

Edit: Also found a file ShipScriptActions.py which may have some relevance. There may be some code in the file that could potentially fix the problem. Looking down to the def ReloadShip if you look at pTorpSys there is a bit of code that deals with filling the torpedo tubes fully, but I believe it also replenishes the ammo stock. I'm sure it can be modified to solely refill the tubes, but I think a new def would need to be created, perhaps calling it def RefillTorps, and inserting the modified code. This file looks like it would be imported by another file, for example any .py that deals with docking the ship to a base with repair or replenishment capabilities would potentially import this file and access some functions.

Side note: Have you tried docking at a starbase/shipyard after unloading the launcher to see if that fixes the bug and refills the tube back to 10?

[Anew9]

I came across an interesting file; ConditionTorpsReady.py

SetStateFromTorpCount and the def's below may be something to look into playing around with, and see if you have any luck manipulating an outcome. At least then we would know if we're on the right track. Looks promising to me, many scripts seem to use conditions, if we're lucky, adding a check to or editing one of the def's could fix the bug.

Edit: Also found a file ShipScriptActions.py which may have some relevance. There may be some code in the file that could potentially fix the problem. Looking down to the def ReloadShip if you look at pTorpSys there is a bit of code that deals with filling the torpedo tubes fully, but I believe it also replenishes the ammo stock. I'm sure it can be modified to solely refill the tubes, but I think a new def would need to be created, perhaps calling it def RefillTorps, and inserting the modified code. This file looks like it would be imported by another file, for example any .py that deals with docking the ship to a base with repair or replenishment capabilities would potentially import this file and access some functions.

Side note: Have you tried docking at a starbase/shipyard after unloading the launcher to see if that fixes the bug and refills the tube back to 10?

Hmmmm.

I'm not sure I'm comfortable with tinkering with those scripts to fix this issue.

[Tethys]

Just make sure you create backups of the original file, if you encounter any problems, you can revert it back. I will assist where/when I can. I have been molesting BC scripts for about 4 years now.. I don't think there's one I haven't touched..

Did you ever try docking with a resupply base after unloading the tubes to see if it goes back to 10?

[Anew9]

Just make sure you create backups of the original file, if you encounter any problems, you can revert it back. I will assist where/when I can. I have been molesting BC scripts for about 4 years now.. I don't think there's one I haven't touched..

Did you ever try docking with a resupply base after unloading the tubes to see if it goes back to 10?

Not yet. I'm trying to modify the stock PY hardpoints to play the game with more screen canon ships.

I hope the bug goes away when I dock with Starbase 12.

[King Class Scout]

Just make sure you create backups of the original file, if you encounter any problems, you can revert it back. I will assist where/when I can. I have been molesting BC scripts for about 4 years now.. I don't think there's one I haven't touched..

Did you ever try docking with a resupply base after unloading the tubes to see if it goes back to 10?

fix the typo in the "warp lights" script, then

Anew: try Tethys' trick as quick as possible.  I wanna see this get debugged to help spread it around.

[Anew9]

fix the typo in the "warp lights" script, then

Anew: try Tethys' trick as quick as possible.  I wanna see this get debugged to help spread it around.

Which trick? Docking with the starbase to reload torpedoes? That's not a problem; the problem is the bug that arises when I completely unload using the rapid fire system. If you fire everything EXCEPT that last torpedo, no bug arises and the tube reloads completely.

Workarounds I have done:

Set reload delay to 0 = torpedoes are rapid fire until you deplete your entire magazine
or
Divide your ships torpedo load into each tube and rapid fire until empty.
or
Count your torpedoes as you fire them and stop firing before the last torpedo and set spread to single and fire.

If I fire torpedoes completely in single spread, the tube reloads completely - its just that silly rapid fire system that causes this bug.

[Tethys]

I will try to explain my trick better. Do as you would normally to unload your forward launcher with rapid fire. After you confirm there is less than 10 torpedoes in the launcher, go dock at a resupply base. After undocking, fire off another salvo and count the shots, if it's 10 then we can create a workaround by force reloading the tubes after each unload, after x amount of seconds (variables) with some altered starbase resupply code from ShipScriptActions.py, most likely within that script. It's going to be tricky going back and forth exchanging code, but I think we can do it; that's if the trick even works to begin with.

[Mario]

Try: https://github.com/bcssov/FixTorps

Timer process which restores torpedoes which haven't been "loaded" needs some tweaking. Clone and make a PR once you're done with tweaking. Also largely untested, just tried basic scenario shooting a salvo and waiting for 40 seconds for all torps to reload to see if the logic kicked in properly.

[Anew9]

Try: https://github.com/bcssov/FixTorps

Timer process which restores torpedoes which haven't been "loaded" needs some tweaking. Clone and make a PR once you're done with tweaking. Also largely untested, just tried basic scenario shooting a salvo and waiting for 40 seconds for all torps to reload to see if the logic kicked in properly.

Is this possible in the stock game that isn't using the foundation process install?

I'm trying to tweak the stock game so that I can play through it using my scripts.

[Mario]

Is this possible in the stock game that isn't using the foundation process install?

I'm trying to tweak the stock game so that I can play through it using my scripts.

Not without heavily modifying stock scripts to inject this piece of code globally somewhere. Hence why the foundation was created.

[Anew9]

Not without heavily modifying stock scripts to inject this piece of code globally somewhere. Hence why the foundation was created.

Hmmm.

Just out of curiosity, what makes BC so unstable with the mods that we add to it?

Is it the foundation plugin?

[Mario]

Hmmm.

Just out of curiosity, what makes BC so unstable with the mods that we add to it?

Is it the foundation plugin?

On the top of my head...

- Unhandled exceptions in some mods
- Mod incompatibility I suppose
- Foundation plugin(s) modifying a bit too much to somewhat "nuke" single player
- NanoFX

[King Class Scout]

holy crap, Mario appeared...or should I have said mamma-mia?

you forgot the inherent Memory Leak in the engine, which probably makes everything worse.  Still, you got a point about Nano.  that seems to be the main script hiccuper.  has anyone ever tried doing a check with Python itself?  I got hold of a copy and ran a couple scripts through.  one of them had a simple "tab" error I couldn't figure out how to fix

[Tethys]

I think only some things with Nano are bugged. Something about blinkers or lighting of some sort. We should be able to deactivate the buggy stuff, rewrite it, or try to fix it. I can live without blinkers, honestly. But we are off topic now.

[Morgan]

On the top of my head...

- Unhandled exceptions in some mods
- Mod incompatibility I suppose
- Foundation modifying a bit too much to somewhat "nuke" single player
- NanoFX

Those and, in the Updating BC thread, I believe it was KCS who found that BC is using a 20-some-odd year old Windows DLL that is a big contributor.

[Mario]

Those and, in the Updating BC thread, I believe it was KCS who found that BC is using a 20-some-odd year old Windows DLL that is a big contributor.

The technical term memory leak has been misused a lot in that thread . And a single DLL cannot be the sole reason for all of games memory leaks. The engine itself can have memory leaks as well, however without seeing the source code one cannot determine efficiently what else causes the following.

Things to know:
1. The engine is very old
2. The engine was written for older versions of DirectX (not too big of a deal)
3. The engine is not designed to take full advantage of modern operating systems\GPUs\CPUs
4. The engine was written in a time before you had multi core computers

[King Class Scout]

the person looking into it said it was ONE of them and had spotted two more.  BC was part of the "Christmas rush" era, after all.  I seem to be having fewer crash errors right now, which is a good thing.

meanwhile, how's this bit with the rapid-fire launcher going?

[Anew9]

the person looking into it said it was ONE of them and had spotted two more.  BC was part of the "Christmas rush" era, after all.  I seem to be having fewer crash errors right now, which is a good thing.

meanwhile, how's this bit with the rapid-fire launcher going?

I've settled so far with just firing all of the torpedoes in the tube EXCEPT the last one on rapid-fire and it works fine. To fire the last torp I switch to single fire and the tube reloads completely.

I just made up a reason that the tube "OVERHEATS" if you fire everything in rapid fire. :/