FuryoftheStars

Hi, sounds kind of like the issue in this thread? https://www.avorion.net/forum/index.php/topic,6140.0.html Reply #7 (currently second to last) from that thread:

Do you have any mining turrets on the ship itself? I’ve never tried it without any on the carrier itself, so can’t say for sure if that’s the cause. I also use the carrier commander mod, so that may make a difference with me, too.

I think they've got something that only allows 2 squads of cargo shuttles to be operating from any one ship/station at a time.

I've seen other threads discussing this and I believe the cargo capacity of cargo shuttles is hard coded at the moment, so can't be changed.

Hyperspace rework rework looks promising. Will give it a test go next chance. Thanks!

Yeah, pretty much! I'm not sure I see the need to make it 120 secs like current, especially if the hyperspace recharge of larger ships is increased, but I wouldn't say I'm dead set on a time that I feel would be best.

As I've been working on a mod recently and getting to know the code better, I think I've figured some of this out. Coaxial weapons (mostly) don't start showing up until around tech 50. There are a few exceptions. The earliest you can find a coaxial is tech 39 for cannons. Tech level, however, is based entirely on distance from core. Digging through everything, there are several functions that the math passes through, but when you attempt to consolidate it all into one (easier to read) formula, you get this: math.floor(52.5 + (-51 * math.min(1.0, math.floor(distanceToCore) / 500))) Using this formula, you have to be closer than 25 sectors from the core to start getting tech 50, closer than 133 sectors for tech 39 (I believe Ogonite starts at around 146). Additionally, when you use research centers, they take the current sector they are in into account to determine the new weapon's tech level, NOT the tech level of the weapons you are feeding into it. This means taking tech 52 weapons back to a research center 100 sectors from the core will reduce the tech level to 42, and vice versa taking tech 1 weapons to a research center darn near at the core will up it to tech 52. When it actually uses the tech in turret generation to determine the size, there is also a 50% chance of its picking a smaller size. So if you're close enough for the coaxial of that weapon type, 50% of them are going to be coaxial (roughly. Exceptions are a couple weapons have two sizes of coaxial, so being in an area that will generate the larger coaxial will skew this). The other 50% will be of a smaller size by random. It will not, however, ever pick a larger sized weapon. Further, dps is also related to distance from the core (though through a separate formula than tech level), so the dps of your weapons suffer (or gain) from these same things.

Ah, ok. I always figured this was happening during the loading screen. I think it takes my computer 2 seconds or less usually to calculate the jump route. Anyone know what the "average" is? Still, I think it'd make more sense if jump calculation had a minimum time of 5-10 secs, variable based on the factors of the sectors, but would take sector generation into account so you weren't waiting generation time + the additional time. Just which ever was greater. Edit: Spelling? Grammar? What ever it is that means "I used completely wrong words." lol Had "were wanting generation time" instead of "weren't waiting generation time". :P

I mentioned this in the post for the 0.31 beta, but figured I might as well make an "official" feedback post on it, too. While I do like the base reduction in recharge times for hyperspace, I don't like the fact that all ships - big and small - have the same recharge times, now. It also doesn't make a lot of sense to me having the recharge time vary based on the content of the sector. I think the hyperspace recharge time should be short for small craft (maybe even shorter than now for something the size of the drone), but then should get longer with larger craft. The time it takes for these ships to recharge should be unaffected by the content of the sector you are in. What should be affected by the content of the sector you are in (and maybe even take where you're jumping to into consideration, especially if it's near/over a rift) is the jump calculation time. Have that be quick for empty sectors, a little longer for sectors with something in it, and even longer when hostiles are present (if it's felt to be necessary, which I'm not too sold on, especially if large ship recharge times are increased). IMO, especially seems we have the ability to create whole fleets of ships, the small ones should be used for quick sector to sector scouting while the large ones sit in wait for something worthy of their attention to be discovered.

Well, to be honest, in reality you'd never be going around and trying to buy the supplies yourself to have the factory manufacturer something, anyway. The factory would take your order in, then would get the needed supplies from their established suppliers (which are going to sell to them much cheaper than to you), manufacture your order, then would give it to you. While you could get the supplies yourself, why would you? Sure, you pay less to the factory, but you'd pay more in the long run from getting all the supplies yourself.

Unfortunately, I find the use of goods on turrets enough of a frustration as is that I’d rather have nothing - not even turrets - require them.

Ah, so is that what it’s called? Best I could come up with in my head was “reverse diminishing returns”.... I’ve been thinking about something else today in regards this, but is more complex so don’t know how others would feel. Instead of having the functionality of the block directly linked to block hps, create a separate hp pool (that’s specific to the blocks... no global pool) for the block’s functionality. Then you can have the different weapons and damage types damage block integrity hps differently from each other than they do the block functionality hps. This would allow for some weapons being better at disabling than others, maybe even make it where some couldn’t disable (cause they won’t damage functionality as quickly as integrity). I would also then say that functionality hps should be repaired faster than integrity. It can use the same formulas and calculations as current block integrity hps, but also factor in engineers (either in whole or in part). This would allow it so sustained damage from a “disabling” weapon can disable the block before destroying it, but if you allow the block too many breaks to repair, then even the disabling weapon would destroy it before it could be disabled. The block’s functionality would be directly related to the remaining functionality hps, but I would almost say should be considered disabled and shut off when it reaches a value other than 0. So for example, a block could still be 10% functional at 10% functionality hps remaining, but then any further damage would cause it to shut straight off. The functionality hps would then have to be restored to 10% or greater before being able to reactivate. I’d almost advocate for saying that the functionality hps would have to be greater, like say 15% in this example, before reactivating. You could even take this a step further (though this may be unnecessarily complicating it further) and say that the lower a block’s integrity hps, the more damage that can be caused to the block’s functionality. So, for example, a weapon that has a 0.8 damage modifier to functionality, at 50% block integrity could get a 50% boost to its modifier and be doing 1.2x damage.

Well, if they share how they use that value core side, then we can use that to figure out all valid combinations. Edit: Should say, rather than all valid combinations, all unique combinations. If they had a simple formula they could share (not sure if it is that simple... hoping), then that'd solve everything. :)

Yup, I got that in there now. It’s how I confirmed that they had such a large range of seed values. Just hoping to get something more definitive so I’m not wasting a lot of time trying or recording different values. With me, there’d be a high chance of me missing a few, too. :P

I think this is more a question for the devs, but if anyone else happens to know this.... I'm working on a mod that, among other things, will hopefully allow a player to pick the look of their turret at turret factories. IE, they can pick the seed that's used. In looking into this, I see in weapongenerator.lua where weapon.appearenceSeed is set to a random signed 32 bit integer. So, that's over 4 billion possibilities. I'd really rather not have users scrolling through 4 billion + possible numbers and I'm guessing (though I could certainly be wrong!) that the game won't actually generate 4 billion + unique weapon designs for each weapon type. My question here is, assuming the above is true, could the devs, or anyone else who's experimented with this and gained some knowledge, share some of the inner workings here? Specifically, my assumption here is that there is a function/formula in the core of the game that takes this appearenceSeed value and is somehow pairing it down to the actual number of unique weapon designs that the game can do. If this could be shared, it'd allow me to limit the user to only going through 0 - x (being the limit of the weapon designs the game does), and then I can set the needed value to appearenceSeed that would generate this. I hope that makes sense. :-\ Thank you!

Haha, sorry, I hadn't been saying anymore on it cause I pretty much already agreed with it all and was just waiting to see what other feedback others gave, if any was negative, etc. That said, to give some little feedback on #2, Decreased performance with block damage, while I like this, I wouldn't want to see a straight 1:1 on the performance degradation. IE, I wouldn't want 50% functionality at 50% block health, 25% at 25% block, etc. I'd rather see the degradation start off slower, then at some point start picking up so we'd reach an obvious conclusion of 0 at 0. If that makes sense.

I posted similar in my first post of this thread as well. Interesting thought. Though I believe part of the reason for (or at least benefit from) IFGs is making it so that smaller detail blocks aren't as easily blown off, and those often include glow blocks, glass, and the like, so I'm not sure about changing it to affect armor only. Up for debate, though.

Outer hull or armor looking shabby is still outer hull or armor that’s intact with the internals untouched, though. But I do agree that damaged blocks should look damaged. Just think there needs to be a bit more to this than a simple hp pool, or something different with the hp pool and how damage gets applied to it so that your ships aren’t dying while still mostly intact.

Yup, I’d pretty much like to see all of this, too.

Hmm, ok. So essentially like an energy generator only for ammo. I'm not as against that idea, though some balancing would need to be done so that small/early ships that are heavily reliant on ammo turrets aren't hard nerfed by it, while not making the inclusion of it almost irrelevant on larger ships. Maybe some kind of diminishing return of fabrication speeds/amounts? It'd also be good if turrets had a default ammo storage which could be expanded with the use of turret base blocks, dedicated ammo storage blocks, the inclusion of ammo storage with the ammo fab blocks, or some combination thereof.

Did you ever play Earth 2150? Non-energy weapons had limited ammo, but resupplying wasn’t too hard. You plopped down an ammo supply structure, assigned some light aircraft to it, and it took care of the rest. You had some control over at what ammo level resupply was requested and the structure could only support just so far and so much ammo in each resupply aircraft. Still, without some kind of management system like that for this game, not sure I’d want it.

Sorry, somehow double posted. ???

I don’t believe so, no. And yeah, fully agree that it’s weird feeling to see your ship die while most of it is still intact.

Yeah, I'm in agreement with the others on ammo. While it could add some new dynamics, etc, I think the amount of additional management it'll add will be too much for this game. Maybe if there were ways to have supply ships and automated resupply, etc, that might make me reconsider. I do like the idea of volatile blocks and getting number of turrets off from system upgrades, though.

Yes, fully aware of that. Again, your earlier post mentioned because of the difference between the use of electromagnets and powder charge, not size. That's what I was disputing.