The game breaks whenever I do this...

Kontra

Kontra http://www.mediafire.com/file/160xb46njm8xuh1/Kodename%27s_Halo_Weapons_mod.rar

Walt

Your plasma torpedoes provide a RailgunShot buff whose value is also buffable by RailgunShot. So the problem is that if you put two plasma torpedoes next to each other they buff each other in an infinite feedback loop until the game crashes.

Kontra

Walt affirmed

clojelo

Walt buff each other in an infinite feedback loop

i have bumped into similar infinite loop crash with AreaBuffProvider, losing changes to ship design.
[Game crash] Directional buff infinite loop at Build panel

Any chance that future Cosmoteer would prevent crash when player building ship?

Bubbet

Walt I sure wish there was a way to avoid this from happening, i'd like to have all connected parts share the same buff value, not infinitely buff each-other forwards and backwards.

Walt

clojelo Yeah I think I can prevent that crash.

Lafiel

Bubbet This basically the same with my suggestion. Only difference is within buffing range rather than connected.

Walt

Lafiel Your solution would mean that buff providers would only get buffed by other buff providers within direct buff range and could not get buffed indirectly through a chain of buff providers.

Lafiel

Walt Correct unless they buff themselves with what they received. In a group of 4 each one would get 3x buffs where as now it would get n!.

Bubbet

Walt I'd just like a method of chaining buffs together without adding anything more to them.

Walt

Lafiel Correct unless they buff themselves with what they received.

I must not understand your proposal because that's how it works right now, which causes an infinite buff loop and crashes.

Lafiel

Walt My proposal is that each provider only uses its base buff value for buffing and not after it has been buffed. And all parts may only receive a buff once from any buff provider, meaning no multi buffing from the same buff provider, hence, no looping. After everything has been applied the final buffed buff value is used to buff non-provider parts.

Walt

Lafiel The first part of your proposal can already be done just by using two different buffs, one to buff the buff providers and one to buff the other parts.

The second part of your proposal would lead to different buff values for different providers depending on the order in which the buffs happen to be applied. For example, say you have a part that gives a +100% buff to adjacent parts and is itself buffable by that +100%. If you have three of those parts in a row, the desired behavior would be that all three have +300% buff, but the actual result would be that some of the parts would have less than +300% depending on the arbitrary order in which the buffs were applied.

Lafiel

Walt Yes, you are correct about that for adjacent only buff providers. It's not necessary for range ones (which usually have 100 range).

For those connected as a single group it would require the game to look and check; and then apply as if they are all in range to each other (this saves range checking).

However, having the game do the search and all is costly like the fill function. Rather than that it could be done when the parts are placed. The game would have to keep track of group lists of buffing providers. It will be memory intensive either way... I don't think there's a better solution. I imagine having the game to adjust during combat when buff providers get destroyed has a huge impact on performance.