#13

Update: it works.

I have a centralized code that uses this new way of working with missiles and in addition to using tables to properly manage fuel, my strikecrafts can now manage their anti-fighter missiles, their anti-ship torpedoes and drop decoys to lure enemy anti-fighter missiles away, all of these being limited in numbers (optionally displayed besides the stats) and automatically refilled at a carrier - torpedoes and fuel triggering an automatic return to base when they are completely used. Furthermore, this system allowed multi-tiered weapon improvements, with Tier 0 (default) being no missiles, Tier 1 (after a first research) being missiles and Tier 2 (after a second research) being cloaking missiles replacing the normal missiles. You could have as many Tiers as needed. With 40 squadrons equipped with this full code, I see a very small stuttering even when fighting, if the time between iterations is at one second. Given the variables at play, it’s completely acceptable to increase the iteration time to five seconds, allowing a smooth gameplay even with numerous units, the strikecrafts being the units with the largest amount of code (capital ships not having to bother with ammunition and fuel, only launching the missiles).

Once the code is finalized and smoothened, I’ll get as much comments on it in the version to be uploaded in the next update of my mod so anyone can use it in their own works. Thanks to all for your help in making this a reality! :slight_smile:

4 Likes
#14

interesting, is 40 ships, 40 strike groups? or 40 individual fighters?

I am thinking about how to stagger the missile management even more. For my purposes the ships would need to select a good target, preferable a battle cruiser or destroyer for a one time salvo then return to a carrier to rearm. it would only need to be the bombers and potentially only a subset of those.

I am also wondering if this could be applied to capital ships but in reverse, havign an ordinance resupply ship. Give each capital ship 100 missiles or so (a few minutes worth. then the ordinance resullply ship has to get close to restock (maybe fly a shuttle over)

a lucky hit on the ferry shuttle or the ordinance supply ship makes a big boom.

actually that may introduce a new mechanism, can we just measure ammo as attack time? i’m not sure when the attack timers start and end, but I could see a script that just racks the time and stores that in subsystem health, so it would be a ship wide missile count.

2 Likes
#15

40 strike groups, 3 fighters each, and each sends one of its eight missiles and drops one of its twenty-four decoys. As for firing everything at once, I’m pretty certain it’s doable, you would need a way to smoothly tell the code to switch between the single-mode and the salvo mode.

Or there is something more general, which would be to predefine the “good targets” and automatically select in the code when you attack between “fire a single torpedo at the Nebulon frigate” and “fire everything at this Victory II destroyer”.

For the capship ammunition, it would be as easy as with strikecraft, so very simple to port. The resupply ship would be a simple code to check the surroundings and see if it is there, which would then resupply x missiles per code iteration until this is done.

Now… for the ferry shuttle, I guess this should be doable too. Check if the supply ship is onboard, spawn the shuttle, have it land on your ship, give some ammunition, take away, land on the supply ship, despawn. Repeat.

Ammo as attack time is already done and working in some mods, AFAIK. It would definitely be a good alternative to what I offer when it comes to long combat and logistical fatigue.

The important question is whether you want to keep using the HWRM missile system, defined with .weapon, .wf and .miss files, which is smooth, hardcoded but with some limitations, or if you want to use the ship-missile system, which can bypass most of these limitations but requires to emulate the entire missile behaviour, with more complex things having more cost on the CPU usage. Note that for some weird as hell reason, I cannot make parade formations oriented upwards. Every time I try it, the missile spawns downwards instead, so if you really need an upward launcher, you would have to modify the .dae to add some virtual hangars and go the drone frigate route.

I’d say that the ammo as attack time fits better for capital ship scaled combat, but the ship-missile is better for strikecraft management, when you cannot expect a long and homogeneous combat behaviour with averaged ammunition use.

2 Likes
#16

If you mean tracking if a sobgroup is attacking, I don’t think this will work. A sobgroup is “attacking” even if it is out of range, so you would get a false time.

#17

Not necessarly. You can find the SobGroup being attacked in the Custom Code, then check its distance to the CustomGroup and start counting the ammunition consumed only when you are in range. Of course, this would be reasonable only for units which have reasonable expectations of being in active combat (firing their weapons) for as long as they are in range of their target. For capital ships, it makes sense. For strikecrafts, it doesn’t, thus the new system I’m working on at the moment.

1 Like
#18

If the player band box attacks, a ship could be in range of multiple targets but only actually firing at one of them. But maybe that’s not a problem for this application…

#19

As long as it is in range, it should consume ammunition. But, once again, for the thing suggested by evillejedi, it’s not that much of an issue because it is supposed to average the ammunition consumption over time, like a prediction table for real world logistics, planning that a regiment will consume X tons of ammunition per week of combat. If you have an error of a few hours here and there, it’s not that critical as long as you are not doing some “just in time” logistics (good for the industry, very bad for the military).

In other news, I reduced the CPU load of the code by staggering its implementation with a simple trigger based on the shipID of every ship and making it so the code for that specific ship gets activated once every X iterations with all ships dispersed relatively homogeneously between all X iterations. Before this, if the code was activated every 5 seconds, I noticed that all units activated the code at the same time, every 5 seconds, thus the stutter experienced in-game. Here, the stutter is reduced even more.

2 Likes
#20

Double post, but I have to acknowledge that you are right and the decoy code activated itself for missiles fired at other planes of the group. Of course, it led to really cool effects of missiles banking hard away from their initial target to rush at a decoy fired a couple km away.

The other issue is that if you targeted 50 fighters and a destroyer, the capship-targeting torpedo would likely be fired at a fighter, and vice-versa.

In any case, I wrote an additional piece of code to pseudo-randomly select individual crafts in the selected target group and check whether they are of the appropriate attack class and within the correct range. It was a bit inspired by the code written a long time ago by, I think, the Star Trek mod team to do auto-repair on ally ships by scanning each ship and seeing whether it needed repairs.

EDIT 1: I will test this improved code during the week and check if it solves the CTD issue I have. Outside this issue, BTW, the code survived a stress-test with two groups of 150 flights of 3 planes each using missiles and decoys. I had around a thousand missiles and decoys fired before the CTD ended the game the very same way it ends it when a couple of flights fight each other.

14B6A1C097F6CC61566BC944EF38CFC2D7E997F81920×1080

It was lagging “a bit” at the time, but I had debug print options on giving me a log a MB large with the list of missiles, decoys and script steps being done.

EDIT 2: this new feature seems to be perfectly compatible with the AI script released on the other thread.

EDIT 3: I got the single target selection to work, which, by the way, leads to really cool BSG 2003 salvo missile launches. However, I still have this CTD bug I cannot isolate. It does happen even if the decoys are deactivated and is definitely linked to the missiles, but the log doesn’t say anything and even if I add print instruction between each and every script instruction, I simply learn that the crash takes place after the end of the custom code update for some missile and before another custom code can even begin. Strange and very annoying as it is the only real obstacle left for a release. The only clue at the moment is that the CTD takes place mostly at the same time, when the missiles’ shipID reach around 2,500. But it’s not it as my huge stress test reached 17,000 before the CTD, with a lot more launchers, of course.

You can see below the effects of the pseudo-random target selection algorithm for missiles:

415216FD2CDCEB02A4DE5B19C82197AB20D5909E1920×1080

EDIT 4: I rewrote the missile code (the new version is, BTW, fully commented and much cleaner to help people reverse-engineer and improve it as needed) as well as increased the time between code updates. It seems to have done the trick. Honestly, I have no clue what happened. I’ll do the same things for decoys and keep my fingers crossed.

EDIT 5: scratch this, it crashed pretty fast during a stress test with 200 fighters fighting it out.

3 Likes
#21

I’ll be blunt, people: this is bad.

The CTD issue happens specifically during missile fire, AKA the core asset of the massive update I planned. It flew under the radar initially because it seems to trigger after numerous shots, but it cannot be ignored, as even with four dozen fighters firing missiles (without decoys), it still crashes under three minutes of total gameplay (including the game setup). I have tried tracking the whole thing without success or playing a bit with the update times, but it doesn’t seem to affect the entire mess. It doesn’t look a code error either, as the tracking procedure did not report any script interruption, and given that the scripts work just as planned for some time before the crash, it excludes the whole issue.

As I said, I rewrote the code, this time with nice comments and a clearer structure, without the legacy bits of code commented out like I had before. It did not work either. It is not linked to a table overload or stuff like this as I can get almost arbitrarly large numbers of missiles shot if I increase the number of available fighters.

This is both frustrating and infuriating as I am this close to a fully working clean ammunition system.

#22

Oh dear :frowning: Good luck tracing the source of the CTD…

1 Like
#23

Yeah. I’ve been on it for hours at a day over the past three or four days. Since the AI was working, actually, so I could see how it integrated itself with the new gameplay mechanic. If you have any idea on how to find the source, I would be grateful. Hell, I am seriously considering the option of putting a good bounty, like 150 to 250 $, on a reliable fix to that CTD (if I do so, I’ll upload a set of files with the code and all that’s needed to run the game with its new functionality), if only because it’s blocking me from something I have been dreaming of for a dozen years now. Plus, it could be something really good for other works such as full-feature remasters of Cataclysm.

#24

It’s a long shot, but maybe @bitvenom or @thisquietreverie can analyze the crash dumps for some extra clues.

1 Like
#25

Are they still active?

#26

My approach is generally to put print statements everywhere until you can track what lines cause the issue. Beyond that (which I am sure you have already tried) I cannot offer any insight…

#27

I did it indeed. That’s why I’m tearing my hair out, because the crash happens outside the scripts. I had, at one time, a long series of print(“A”) to, like print (“EG”) or something, and a log in MB before the crash. But at the beginning of each script, I had specific “start script X” and “end script X”. Guess what? The last thing I saw was stuff like end script decoy or end script missile. I’m 90 % sure it’s not a syntax issue, as I rewrote the scripts afterwards with no change to the result, and frankly, it’s working pretty well outside this, even stable with very low number of units. I’m starting to suspect my computer, since my hard drives are all 95 to 99 % full and the laptop starts getting old.

#28

if its working properly with less units, it could be an overload of fx . It could also be an issue with data left over from one missile being used by a new missile . You could try uploading enough source on here so others can give it a test . if it is your computer being overloaded to much, then it may become more noticeable with the more people who try it .

1 Like
#29

I will clean the stuff and try to make a standalone package for testing purposes, I will post a link when it’s done. Thanks!

3 Likes
#30

Just a shot in the dark. But I figured I’d rather pitch you a daft thought than hold up progress in the odd chance this could mean anything.

Since the missiles are now spawning as ships do your fighters have shiphold abilities? I know the game will crash if a ship spawns something without having the option to hold anything at all first. I mean it doesn’t even have to be that ship type.

Or at least it used to be like that. In Classic anyways.

I don’t know.

Sure hope you can figure this out.

#31

Nah, no need for this. The issue is that the code does work as intended. You can see in the screenshots I posted that I had up to several hundreds of missiles and decoys fired properly. Well, not exactly for the decoys, because I am still struggling a bit for a code allowing me to reliably determine which missiles are attacking the specific craft running the code so I can lure them on the decoy. ATM, the decoys will lure missiles fired at other friendly planes or even already-lured missiles. Quite pretty effect, actually, it’s like in Battlestar Galactica when a Raptor’s decoy lures a Cylon missile.

Nah, the problem is that it crashes at some point, and no debugging procedure I have tried managed to isolate a code or a game error at any point. It runs for some time, but after enough (though a different number each time) missiles have been shot, it suddenly crashes.

EDIT: however… I could try to work from the drone frigate code, which does something similar to the trick used here. Might be worth looking into it even though I fear it would require recompiling the .hod with dockpathes. I’ll do it later, though, I got way too much LUA over the past week and I’ve got to start Witcher 3.

#32

In the case @BitVenom or another dev’ has the time to check, here is an upload of the dump and minidump I got after a CTD today (I was checking if configuring the missiles to not be rendered beyond a very short distance would help - it didn’t) after a couple of minutes with fighters firing and dodging missiles.

1 Like