#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
#33

2 things with your command line arguments,

  1. Does fakefullscreen do anything? I haven’t heard of that argument though it does appear in the exe (Though as fakeFullscreen [Second F is a capital])
  2. You miss-spelt traceHODs, you have it as taceHODs
#34

I’ll correct the trace, though the Fakefullscreen is for borderless full screen.

#35

Thought of something else. I mean maybe you’ve thought about this already? But by changing those missiles into ships do you think you’re hitting the hard-coded limit of the number of ships a player can have? I thought that was somewhere around 250. I don’t know. Maybe that’s different for RM. No idea.