Bridge Commander Central
BC Forums => BC Scripting => Topic started by: Anew9 on October 06, 2018, 08:15:56 AM
-
Hey everyone,
I recently found a way to create a rapid firing torpedo launcher WITHOUT using a pulse weapon launcher.
-I just went into the hardpoints script and set max ready torpedoes to 1 launcher at 10
- reload delay 40
- immediate delay to 0
- Deleted the other launchers
- Set firing chain to 0; single;53;Full spread (make sure the torpedo launchers are in these firing groups)
- Launch game
- Target enemy set spread to full spread and fire.
Torpedoes are now rapid firing.
BUT...
For some reason after launching a full volley fully, the tubes don't ever fully reload back to 10 again for the rest of the battle. In fact, they actually start firing fewer and fewer torpedoes - even when I set torpedoes to single spread again AFTER firing full.
Does anyone know how to fix this issue? It doesn't happen when I only fire torpedoes in single spread pattern, only when I use my new spread config.
-
What torpedo is the hp using? Can you upload the file so we can have a look at the modified code? Check the projectiles, there may be a power cost to be accounted for that may be preventing the torpedoes from fully reloading. Have you checked the warp core/battery in F5 when using the rapid fire torpedoes? There may also be a power cost in the hardpoint as well. As a test, you could make the warp core conduits insanely high and see if your torpedoes last longer. That would be a fairly quick test. Or eliminate power costs from the projectile py and the hardpoint torp launcher(s)
-
What torpedo is the hp using? Can you upload the file so we can have a look at the modified code? Check the projectiles, there may be a power cost to be accounted for that may be preventing the torpedoes from fully reloading. Have you checked the warp core/battery in F5 when using the rapid fire torpedoes? There may also be a power cost in the hardpoint as well. As a test, you could make the warp core conduits insanely high and see if your torpedoes last longer. That would be a fairly quick test. Or eliminate power costs from the projectile py and the hardpoint torp launcher(s)
I don't think the torpedoes themselves use power to launch - only disruptor weapons.
I check my main battery levels during weapons firing and they don't move much.
The issue only happens when I completely empty the tube using my Full spread. If I don't empty the tube, it reloads back to 10.
-
ForwardTorpedoTube = App.TorpedoTubeProperty_Create("Forward Torpedo Tube")
ForwardTorpedoTube.SetMaxCondition(2400.000000)
ForwardTorpedoTube.SetCritical(0)
ForwardTorpedoTube.SetTargetable(1)
ForwardTorpedoTube.SetPrimary(1)
ForwardTorpedoTube.SetPosition(0.005519, -0.055472, -0.147180)
ForwardTorpedoTube.SetPosition2D(49.000000, 55.000000)
ForwardTorpedoTube.SetRepairComplexity(3.000000)
ForwardTorpedoTube.SetDisabledPercentage(0.500000)
ForwardTorpedoTube.SetRadius(0.200000)
ForwardTorpedoTube.SetDumbfire(1)
ForwardTorpedoTube.SetWeaponID(0)
ForwardTorpedoTube.SetGroups(25)
ForwardTorpedoTube.SetDamageRadiusFactor(0.200000)
ForwardTorpedoTube.SetIconNum(370)
ForwardTorpedoTube.SetIconPositionX(76.000000)
ForwardTorpedoTube.SetIconPositionY(35.000000)
ForwardTorpedoTube.SetIconAboveShip(1)
ForwardTorpedoTube.SetImmediateDelay(0.000000)
ForwardTorpedoTube.SetReloadDelay(40.000000)
ForwardTorpedoTube.SetMaxReady(10)
ForwardTorpedoTubeDirection = App.TGPoint3()
ForwardTorpedoTubeDirection.SetXYZ(0.000000, 1.000000, 0.000000)
ForwardTorpedoTube.SetDirection(ForwardTorpedoTubeDirection)
ForwardTorpedoTubeRight = App.TGPoint3()
ForwardTorpedoTubeRight.SetXYZ(-1.000000, 0.000000, 0.000000)
ForwardTorpedoTube.SetRight(ForwardTorpedoTubeRight)
App.g_kModelPropertyManager.RegisterLocalTemplate(ForwardTorpedoTube)
#################################################
Torpedoes = App.TorpedoSystemProperty_Create("Torpedoes")
Torpedoes.SetMaxCondition(8000.000000)
Torpedoes.SetCritical(0)
Torpedoes.SetTargetable(0)
Torpedoes.SetPrimary(1)
Torpedoes.SetPosition(0.000000, 0.000000, 0.000000)
Torpedoes.SetPosition2D(64.000000, 60.000000)
Torpedoes.SetRepairComplexity(3.000000)
Torpedoes.SetDisabledPercentage(0.750000)
Torpedoes.SetRadius(0.200000)
Torpedoes.SetNormalPowerPerSecond(100.000000)
Torpedoes.SetWeaponSystemType(Torpedoes.WST_TORPEDO)
Torpedoes.SetSingleFire(0)
Torpedoes.SetAimedWeapon(1)
kFiringChainString = App.TGString()
kFiringChainString.SetString("0;Single;53;Full spread")
Torpedoes.SetFiringChainString(kFiringChainString)
Torpedoes.SetMaxTorpedoes(0, 200)
Torpedoes.SetTorpedoScript(0, "Tactical.Projectiles.PhotonTorpedo")
Torpedoes.SetNumAmmoTypes(1)
App.g_kModelPropertyManager.RegisterLocalTemplate(Torpedoes)
#################################################
-
ForwardTorpedoTube = App.TorpedoTubeProperty_Create("Forward Torpedo Tube")
ForwardTorpedoTube.SetMaxCondition(2400.000000)
ForwardTorpedoTube.SetCritical(0)
ForwardTorpedoTube.SetTargetable(1)
ForwardTorpedoTube.SetPrimary(1)
ForwardTorpedoTube.SetPosition(0.005519, -0.055472, -0.147180)
ForwardTorpedoTube.SetPosition2D(49.000000, 55.000000)
ForwardTorpedoTube.SetRepairComplexity(3.000000)
ForwardTorpedoTube.SetDisabledPercentage(0.500000)
ForwardTorpedoTube.SetRadius(0.200000)
ForwardTorpedoTube.SetDumbfire(1)
ForwardTorpedoTube.SetWeaponID(0)
ForwardTorpedoTube.SetGroups(25)
ForwardTorpedoTube.SetDamageRadiusFactor(0.200000)
ForwardTorpedoTube.SetIconNum(370)
ForwardTorpedoTube.SetIconPositionX(76.000000)
ForwardTorpedoTube.SetIconPositionY(35.000000)
ForwardTorpedoTube.SetIconAboveShip(1)
ForwardTorpedoTube.SetImmediateDelay(0.000000)
ForwardTorpedoTube.SetReloadDelay(40.000000)
ForwardTorpedoTube.SetMaxReady(10)
ForwardTorpedoTubeDirection = App.TGPoint3()
ForwardTorpedoTubeDirection.SetXYZ(0.000000, 1.000000, 0.000000)
ForwardTorpedoTube.SetDirection(ForwardTorpedoTubeDirection)
ForwardTorpedoTubeRight = App.TGPoint3()
ForwardTorpedoTubeRight.SetXYZ(-1.000000, 0.000000, 0.000000)
ForwardTorpedoTube.SetRight(ForwardTorpedoTubeRight)
App.g_kModelPropertyManager.RegisterLocalTemplate(ForwardTorpedoTube)
#################################################
Torpedoes = App.TorpedoSystemProperty_Create("Torpedoes")
Torpedoes.SetMaxCondition(8000.000000)
Torpedoes.SetCritical(0)
Torpedoes.SetTargetable(0)
Torpedoes.SetPrimary(1)
Torpedoes.SetPosition(0.000000, 0.000000, 0.000000)
Torpedoes.SetPosition2D(64.000000, 60.000000)
Torpedoes.SetRepairComplexity(3.000000)
Torpedoes.SetDisabledPercentage(0.750000)
Torpedoes.SetRadius(0.200000)
Torpedoes.SetNormalPowerPerSecond(100.000000)
Torpedoes.SetWeaponSystemType(Torpedoes.WST_TORPEDO)
Torpedoes.SetSingleFire(0)
Torpedoes.SetAimedWeapon(1)
kFiringChainString = App.TGString()
kFiringChainString.SetString("0;Single;53;Full spread")
Torpedoes.SetFiringChainString(kFiringChainString)
Torpedoes.SetMaxTorpedoes(0, 200)
Torpedoes.SetTorpedoScript(0, "Tactical.Projectiles.PhotonTorpedo")
Torpedoes.SetNumAmmoTypes(1)
App.g_kModelPropertyManager.RegisterLocalTemplate(Torpedoes)
#################################################
You're just posting code but you're not telling us why you are doing so. Are you asking us to look and make sure you edited something correctly? Are you asking if these are things you need to edit? What's the deal?
-
You're just posting code but you're not telling us why you are doing so. Are you asking us to look and make sure you edited something correctly? Are you asking if these are things you need to edit? What's the deal?
Tethys said he wanted to see the code I edited to see why my weapons aren't reloading fully.
-
Yes I wanted to look at the code. Perhaps there may be a way to unload all torpedoes except for one, tricking the bug. I will get back to you when I have a little more time later tonight.
-
Yes I wanted to look at the code. Perhaps there may be a way to unload all torpedoes except for one, tricking the bug. I will get back to you when I have a little more time later tonight.
I was thinking the same thing. I even set the maxready to 11 and would count to 10 while firing but it's silly to need to do that - plus I can't tell when I'm on the last torpedo without counting.
Something else I noticed that was interesting is that every time I empty the tube, the next volley that is reloaded fires 1 torpedo LESS. EVERY. TIME. Until it stops at 6. Furthermore, this only effects the FORWARD torpedo tube; the rear tubes always usually reload completely.
What seems to minimize this is to set the immediatedelay to -0.99999 and that stops the reloaded tube from reloading below 6 torpedoes.
-
Can you show me the code for the rear tube please?
Also, have you tried to fire rear torpedo spread first, before firing front spread? What do you mean by "usually" reloads to 10 for rear tubes? I would do a specific test of the rear tubes, I have a hunch that it may not matter which tubes are unloaded first, as whichever is unloaded first may present your bug.
Another thing you might try is to add a dummy torpedo type with 0 ammo and see if switching back and forth fully reloads the tubes to 10.
Torpedoes.SetMaxTorpedoes(0, 200)
Torpedoes.SetTorpedoScript(0, "Tactical.Projectiles.PhotonTorpedo")
Torpedoes.SetMaxTorpedoes(1, 0)
Torpedoes.SetTorpedoScript(1, "Tactical.Projectiles.QuantumTorpedo")
Torpedoes.SetNumAmmoTypes(2)
-
I'm gonna keep an eye on this and see if you get it (both of you) working correctly. script innovation like this is nice to see again.
besides, Anew answered a tube question that's come up while I'm fixing a hardpoint for beta release. cheers.
btw...have a cookie!
-
Can you show me the code for the rear tube please?
Also, have you tried to fire rear torpedo spread first, before firing front spread? What do you mean by "usually" reloads to 10 for rear tubes? I would do a specific test of the rear tubes, I have a hunch that it may not matter which tubes are unloaded first, as whichever is unloaded first may present your bug.
Another thing you might try is to add a dummy torpedo type with 0 ammo and see if switching back and forth fully reloads the tubes to 10.
Torpedoes.SetMaxTorpedoes(0, 200)
Torpedoes.SetTorpedoScript(0, "Tactical.Projectiles.PhotonTorpedo")
Torpedoes.SetMaxTorpedoes(1, 0)
Torpedoes.SetTorpedoScript(1, "Tactical.Projectiles.QuantumTorpedo")
Torpedoes.SetNumAmmoTypes(2)
I already tried to switch torpedo types on my sovereign class with the exact same rapid fire script but the forward tube does the same thing - I thought that might expose the problem also.
-
I'm gonna keep an eye on this and see if you get it (both of you) working correctly. script innovation like this is nice to see again.
besides, Anew answered a tube question that's come up while I'm fixing a hardpoint for beta release. cheers.
btw...have a cookie!
Thank you! Hopefully, we can figure this out.
-
Can you show me the code for the rear tube please?
AftTorpedoTube = App.TorpedoTubeProperty_Create("Aft Torpedo Tube")
AftTorpedoTube.SetMaxCondition(2400.000000)
AftTorpedoTube.SetCritical(0)
AftTorpedoTube.SetTargetable(1)
AftTorpedoTube.SetPrimary(1)
AftTorpedoTube.SetPosition(-0.004098, -2.586010, -0.475469)
AftTorpedoTube.SetPosition2D(59.000000, 100.000000)
AftTorpedoTube.SetRepairComplexity(3.000000)
AftTorpedoTube.SetDisabledPercentage(0.500000)
AftTorpedoTube.SetRadius(0.250000)
AftTorpedoTube.SetDumbfire(1)
AftTorpedoTube.SetWeaponID(4)
AftTorpedoTube.SetGroups(4)
AftTorpedoTube.SetDamageRadiusFactor(0.200000)
AftTorpedoTube.SetIconNum(370)
AftTorpedoTube.SetIconPositionX(77.000000)
AftTorpedoTube.SetIconPositionY(116.000000)
AftTorpedoTube.SetIconAboveShip(1)
AftTorpedoTube.SetImmediateDelay(-0.999990)
AftTorpedoTube.SetReloadDelay(40.000000)
AftTorpedoTube.SetMaxReady(10)
AftTorpedoTubeDirection = App.TGPoint3()
AftTorpedoTubeDirection.SetXYZ(0.000000, -1.000000, 0.000000)
AftTorpedoTube.SetDirection(AftTorpedoTubeDirection)
AftTorpedoTubeRight = App.TGPoint3()
AftTorpedoTubeRight.SetXYZ(-1.000000, 0.000000, 0.000000)
AftTorpedoTube.SetRight(AftTorpedoTubeRight)
App.g_kModelPropertyManager.RegisterLocalTemplate(AftTorpedoTube)
#################################################
-
Also, have you tried to fire rear torpedo spread first, before firing front spread? What do you mean by "usually" reloads to 10 for rear tubes? I would do a specific test of the rear tubes, I have a hunch that it may not matter which tubes are unloaded first, as whichever is unloaded first may present your bug.
Yup, that's the problem. Whichever tube you deplete first presents this bug; forward or aft.
So this is the pattern:
1) Set torpedo to full spread - fire all 10 until empty
2) Next reloaded volley has only 9 torpedoes loaded and won't reload that 1 remaining
3) Fire the 9 torps until empty in full spread
4) Next reloaded volley has 8 torps etc.
If you continue to fire in full spread the loaded torps will decrease until 6 and then won't go any lower (usually).
-
Idea: Duplicate the forward launcher in the hardpoint. Rename the duplicate so there is no conflict, dont forget the label (or whatever its called, I cant recall) at the bottom of the hardpoint. Both forward rapid launchers should empty simultaneously, or if we are lucky one will take precedence over the other. I would like to know if you get 18 or 19 torpedoes upon reload. If 19, the solution could simply be to add a dummy forward launcher with a SetMaxReady of either 0 or 1. Ideally we would want to use 0 so there is no extra torpedoes throwing off the spread, as the tube would by default read as depleted. Good luck; until tomorrow.
I assume that the problem lies outside the ship hardpoint. You might need to SetMaxTorpedoes on the dummy (quantum) torps to 20 to fill all launchers when switched, I do see you tried the switch without success.
It will be tomorrow before I can look any further into the code. From what I can see at first glance the launchers look good. It might be time to look for clues elsewhere, perhaps whatever script handles loading the projectile. Something tells me its in the foundation, but maybe we will get lucky tomorrow.
-
Tethys said he wanted to see the code I edited to see why my weapons aren't reloading fully.
Ah ok. I should have read above.
-
Idea: Duplicate the forward launcher in the hardpoint. Rename the duplicate so there is no conflict, dont forget the label (or whatever its called, I cant recall) at the bottom of the hardpoint. Both forward rapid launchers should empty simultaneously, or if we are lucky one will take precedence over the other. I would like to know if you get 18 or 19 torpedoes upon reload. If 19, the solution could simply be to add a dummy forward launcher with a SetMaxReady of either 0 or 1. Ideally we would want to use 0 so there is no extra torpedoes throwing off the spread, as the tube would by default read as depleted. Good luck; until tomorrow.
I assume that the problem lies outside the ship hardpoint. You might need to SetMaxTorpedoes on the dummy (quantum) torps to 20 to fill all launchers when switched, I do see you tried the switch without success.
It will be tomorrow before I can look any further into the code. From what I can see at first glance the launchers look good. It might be time to look for clues elsewhere, perhaps whatever script handles loading the projectile. Something tells me its in the foundation, but maybe we will get lucky tomorrow.
I just tested that idea out this morning. I set up another torpedo tube with set max ready as 0 but the problem still exists for whatever launcher is emptied first.
Then I tried creating another launcher with a setmaxready of 1, to see if that tube will take the bug away from my main launcher - didn't work.
Something about my main launchers that causes this bug. Maybe its the amount of torpedoes that can be loaded?
Ive tried loading 5 and increasing the reload speed but the bug persists.
-
Which forward launcher is emptied first? Does the second forward launcher reload completely? Did they both deplete at the same time? Do they both fail to reload completely? Perhaps try SetReloadDelay on the new forward launcher to 39.0 instead of 40.0 as you have for the first launcher. Also change SetDumbFire 0 on both launchers. If I remember, this option disallows launching from the tube if another launcher is actively firing. Also, good morning.
-
Which forward launcher is emptied first? Does the second forward launcher reload completely? Did they both deplete at the same time? Do they both fail to reload completely? Perhaps try SetReloadDelay on the new forward launcher to 39.0 instead of 40.0 as you have for the first launcher. Also change SetDumbFire 0 on both launchers. If I remember, this option disallows launching from the tube if another launcher is actively firing. Also, good morning.
Good morning!
I set the second launcher to fire only 1 torp so it empties first and I increased the reload delay so that I wouldn't use it for the rest of the fight but the bug still persists on the main launcher.
I'll try the dumbfire option
EDIT: Dumbfire option didn't work
-
I set the second launcher to fire only 1 torp so it empties first and I increased the reload delay so that I wouldn't use it for the rest of the fight but the bug still persists on the main launcher.
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.
-
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 :(
-
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.
-
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?
-
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.
-
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.. :readme:
Did you ever try docking with a resupply base after unloading the tubes to see if it goes back to 10?
-
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.. :readme:
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.
-
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.. :readme:
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 :P
Anew: try Tethys' trick as quick as possible. I wanna see this get debugged to help spread it around.
-
fix the typo in the "warp lights" script, then :P
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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
-
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 :P
-
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.
-
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.
-
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
-
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?
-
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. :/
-
You have a few people with some time willing to help, I feel like we were close to figuring it out. I would like to see your issue properly resolved, I think it would make a good addition. Is there a way to modify the amount of torpedoes fired and insert something along the following lines:
ceasefire == 0 [this would be the base state of the launcher, ie. no active ceasefire on ptube]
maxload = maximum torpedo load - 1
currentload = maximum torpedo load - current torpedo load
if currentload = maxload: return (ceasefire==1) [this would be the turn off for ptube]
if ceasefire == 1: dont launch anymore torpedoes until (grab the reload delay on the tube) amount of time. [this would be the code turning off the ptube for the specified timeframe, 40 seconds in your case]
(above code is not to be copied, just a general outline of the idea)
I think that should be possible by temporarily disabling the tube for the reload delay value of the tube referenced in the ship script so that the last torpedo is never fired (set num ready to 11 so you fire 10 and leave 1 in the launcher until after reload delay); you may need to call forwardtube.getreloaddelay()
As for where to put that code, I would think it would go into ConditionTorpsReady under the TorpFired definition, so every time a torpedo is fired it will check to make sure that current torpedo load is greater than or equal to >= 1. If 1, disable the launcher for ptube.getreloaddelay() seconds
-
You have a few people with some time willing to help, I feel like we were close to figuring it out. I would like to see your issue properly resolved, I think it would make a good addition. Is there a way to modify the amount of torpedoes fired and insert something along the following lines:
ceasefire == 0 [this would be the base state of the launcher, ie. no active ceasefire on ptube]
maxload = maximum torpedo load - 1
currentload = maximum torpedo load - current torpedo load
if currentload = maxload: return (ceasefire==1) [this would be the turn off for ptube]
if ceasefire == 1: dont launch anymore torpedoes until (grab the reload delay on the tube) amount of time. [this would be the code turning off the ptube for the specified timeframe, 40 seconds in your case]
(above code is not to be copied, just a general outline of the idea)
I think that should be possible by temporarily disabling the tube for the reload delay value of the tube referenced in the ship script so that the last torpedo is never fired (set num ready to 11 so you fire 10 and leave 1 in the launcher until after reload delay); you may need to call forwardtube.getreloaddelay()
As for where to put that code, I would think it would go into ConditionTorpsReady under the TorpFired definition, so every time a torpedo is fired it will check to make sure that current torpedo load is greater than or equal to >= 1. If 1, disable the launcher for ptube.getreloaddelay() seconds
Interesting. Can anyone figure out how to do this in-game?
-
Problem solved.
Just go into the hardpoints and rearrange the rapid fire spread in front of single spread and the tube completely reloads and rapid fires.
-
Interesting! That sounds very simple? SO temperamental this game. Here we were ready to force reload the tubes. So if I understand, your ship will start out with rapid fire selected instead of single fire, correct? I wonder if there are still any hidden bugs? I suppose time will only tell.