Realistic Fusion Weaponry


Energy production isn't the only use of nuclear fusion. Weapons of mass destruction are another use, for example. Fully compatible with True Nukes, K2, Angel's/Bob's, SE and IR2. Addon to Realistic Fusion Power. Unmaintained since 2024-10-25.

Content
a month ago
1.0 - 1.1
14.6K
Combat

g True-Nukes adding optimisations to base

3 years ago

Hi, I'm the developer of True-Nukes, so happy to see you added support!
Would it be alright if I use the edits you have done in the base mod (just the optimisations on loading chunks) - I'm asking for licensing reasons, just to make sure - the "share alike" clause on the license you are using may (just about) be complicated, and it's to be better safe than sorry - I'd give attribution for the idea.

Also now you bring it to my attention, I could add bigger nukes... mwahaha!!!

3 years ago

Of course! Though do keep in mind that it's not updated to the latest TN version (0.1.12 is the one I edited iirc).
Also, while you're here, would it be possible to add some way for other mods to add TN-style nukes without copying all of your code? The easiest way I can think of is making the atomic_weapon_hit() function in control.lua global (simply removing the "local" in front of it), which should make it accessible to other mods if I'm not mistaken.

And about the license, as far as I know, CC BY-SA means in simple terms that you have to give credit and distribute the code under the same license, though here I give you written permission to ignore that (it's almost all your code, anyway, and not like anyone's going to actually take this to court).

3 years ago
(updated 3 years ago)

Thanks for the permission, I wasn't planning on copying the code anyway, just taking inspiration for the optimisation!
I'm going to add some compatibility stuff as that seems like a good idea - I'm planning on moving all those functions into their own file and returning their references, so that they can all be accessed by other mods - that should fix your use case. For compatibility, I might explore allowing the script triggers to give the parameters for the detonation, but I'm not sure how that would work (might be slower)...
I'm also going to add some more bigger nukes, and might do some magic to make it seem like they simulate further than they actually do (by applying the script for a given chunk when that chunk loads - might be a bit tricky, but should allow unlimited nuke sizes)... like all the way into gigatons maybe?
Not entirely sure how that would work, but it would certainly help...

3 years ago

I'm going to add some compatibility stuff as that seems like a good idea - I'm planning on moving all those functions into their own file and returning their references, so that they can all be accessed by other mods - that should fix your use case. For compatibility, I might explore allowing the script triggers to give the parameters for the detonation, but I'm not sure how that would work (might be slower)...

Moving all the functions to a separate file and returning them would work, but if you want to go more complicated, I'd recommend adding a remote interface (wiki page about that here) instead of somehow passing all the parameters through the effect_id.

I'm also going to add some more bigger nukes, and might do some magic to make it seem like they simulate further than they actually do (by applying the script for a given chunk when that chunk loads - might be a bit tricky, but should allow unlimited nuke sizes)... like all the way into gigatons maybe?
Not entirely sure how that would work, but it would certainly help...

As much as I'd like to see nukes in the Gt range, what you're describing is most likely not possible, because on every new chunk loaded you'd have to:
1. Calculate how far away it is from the ground zero of EVERY powerful bomb
2. Check how many (if any) of the chunk's tiles are inside a fireball of any bomb and vaporize accordingly
3. Check how much of the chunk should be a crater and replace all the tiles
4. Somehow check how much destruction would've been done by the blast and damage stuff accordingly
and so on, until all of the nuke's effects are accounted for.

It would be hard to code in and even if it worked, generating any new chunks would freeze the game for a while.
For bigger nukes, I think that the best thing you could do it spread all of the calculations over a several seconds (or minutes in case of really big bombs) instead of freezing the game completely.

3 years ago
(updated 3 years ago)

Moving all the functions to a separate file and returning them would work, but if you want to go more complicated, I'd recommend adding a remote interface (wiki page about that here) instead of somehow passing all the parameters through the effect_id.

Oh yeah, forgot about that... good idea!

As much as I'd like to see nukes in the Gt range, what you're describing is most likely not possible, because on every new chunk loaded you'd have to:
1. Calculate how far away it is from the ground zero of EVERY powerful bomb
2. Check how many (if any) of the chunk's tiles are inside a fireball of any bomb and vaporize accordingly
3. Check how much of the chunk should be a crater and replace all the tiles
4. Somehow check how much destruction would've been done by the blast and damage stuff accordingly
and so on, until all of the nuke's effects are accounted for.

It would be hard to code in and even if it worked, generating any new chunks would freeze the game for a while.

The hope is that there are never that many entities in a newly generated chunk, so while it may slow the game somewhat, it shouldn't be that bad.
Also the 'powerful bombs' would only include 100kt and above, and anyone who detonates loads of those would get what they deserve, I will also apply a range limit to each bomb, so as long as the chunk is more that a certain distance away from the bomb, the script just skips it - this adds some overhead to every chunk, but not that much.
Besides this, the blast and thermal are actually pretty quick to do on a small number of entities, particularly as I can skip making it look like they just died, most of the problem of a really huge nuke is that all this is happening at once, which creates huge memory usage, reducing the CPU's ability to cache stuff, etc. and this is all times several hundred chunks, and it has to load those chunks. Hopefully, when working on a single chunk, I can just get every entity in that chunk (realistically no more than 2000), and go from there.
My main concern is honestly that it will introduce weird desync issues, as the game would then depend on chunk load order, which it really shouldn't, so I'll have to use random number generators from the chunk position, not the global one.
This whole thing will also introduce some problems with mod compatibility, but that is kind of to be expected.

For bigger nukes, I think that the best thing you could do it spread all of the calculations over a several seconds (or minutes in case of really big bombs) instead of freezing the game completely.
I have now time-blurred the thermal calculations which were a big part of the huge super-freeze, most of the rest of the super-freeze is from the map load, which shouldn't need doing now.

3 years ago

The hope is that there are never that many entities in a newly generated chunk, so while it may slow the game somewhat, it shouldn't be that bad.
Also the 'powerful bombs' would only include 100kt and above, and anyone who detonates loads of those would get what they deserve, I will also apply a range limit to each bomb, so as long as the chunk is more that a certain distance away from the bomb, the script just skips it - this adds some overhead to every chunk, but not that much.
Besides this, the blast and thermal are actually pretty quick to do on a small number of entities, particularly as I can skip making it look like they just died, most of the problem of a really huge nuke is that all this is happening at once, which creates huge memory usage, reducing the CPU's ability to cache stuff, etc. and this is all times several hundred chunks, and it has to load those chunks. Hopefully, when working on a single chunk, I can just get every entity in that chunk (realistically no more than 2000), and go from there.

I'm mainly worrying about the crater, because you either have to go through every single tile to check which ones should be replaced to form the circle, or you have to somehow simulate the entire crater but only replace the tiles in the new chunk (in case the player decides to change some of the crater to concrete before all of the chunks were generated).
Although it should still be mostly okay, since this would only be necessary for the chunks on the edge of the crater; if a chunk is close enough to ground zero to be all crater tiles, you know you can replace all of it.

My main concern is honestly that it will introduce weird desync issues, as the game would then depend on chunk load order, which it really shouldn't, so I'll have to use random number generators from the chunk position, not the global one.
This whole thing will also introduce some problems with mod compatibility, but that is kind of to be expected.

As far as I know, the chunk load order shouldn't be a problem. Factorio is deterministic, so all clients should load chunks in the exact same order.

I think it's worth a shot, and if you'll need any help with it feel free to ask me.
Also (in case you didn't know), if you want to measure the performance impact of your code, use the log() function before and after the code you want to test and run it. Afterwards you'll be able to see how much time it took in the log file.

3 years ago

I'm mainly worrying about the crater, because you either have to go through every single tile to check which ones should be replaced to form the circle, or you have to somehow simulate the entire crater but only replace the tiles in the new chunk (in case the player decides to change some of the crater to concrete before all of the chunks were generated).
Although it should still be mostly okay, since this would only be necessary for the chunks on the edge of the crater; if a chunk is close enough to ground zero to be all crater tiles, you know you can replace all of it.

This might be a bit of a problem yes, but the worst part will be applying the noise function to the edge, as I'll only be able to generate part of the noise at a time...

As far as I know, the chunk load order shouldn't be a problem. Factorio is deterministic, so all clients should load chunks in the exact same order.

True, but it might be a bit weirder than other things I've done. I agree I doubt it will be a problem, but still.

I think it's worth a shot, and if you'll need any help with it feel free to ask me.

Thanks, I'll keep that in mind!

3 years ago

OK, my first attempt at this is up... feel free to try it (there should be remote calls now).

3 years ago
(updated 3 years ago)

Sorry that it took so long, I made the update and then forgot to publish it...
The remote calls work, and good job on optimizing the really big explosions; I might make some >1Gt antimatter ones at some point...

Only thing that I've noticed is that the log file gets spammed from your control.lua's line 1842. That and the 2 lines above it should be removed. Nevermind, you apparently fixed that already.

3 years ago

Yeah, that was me trying to optimise it that little bit more, then forgetting to remove the log line... oops

New response