Search results

Is the inter-ship remote not the wireless logic block already?

I have stated already that using turret docks as static docks were something thing I didn't think of. And, for the record, I did extensively clarify the definition of a turret as something docked to a particular entity via at least one turret dock - though I do recognize that this definition is...

In fact, I've put quite some thought into these specifics. Schema explained the algorithm for shield sharing when it was first implemented- when a docked entity is hit (the damagee), the damage is taken by the lowest entity below the damagee in the tree with shields still above the threshold...

This is an easy fix, no? 100% sharing for docked entities, 75% for turrets. That encourages modular building, removed the penalties for, say, moving hangar doors over plexdoors, keeps turrets as weak spots, and fixes docked hull.

Certainly, I recognize the need for much more sophisticated turret control overall. Now, I could argue that this doesn't mean we can't start with this simple. On the other hand, I think I'm usually the one who argues that no, we shouldn't pepper the game with small features and fixes where there...

I like putting PD turrets on my ship. Very many PD turrets, in fact. So many that, when it's all installed, I realise- this could probably do reasonable damage to a drone or small fighter. But, then they wouldn't be shooting missiles. Thus, I propose- make the 'missile' option a line of its own...

Before I go about offering any more detailed opinions, I'd just like to remark that balancing the game around what AI can and cannot do seems like a terrible idea. This would mean making balance dependent on limiting the game's control features in the long term. Swivel speed and sensor accuracy...

Point of disagreement- A solo player, having put in the time and effort to amass more resources and firepower than three enemy players combined, should stand a fair chance of winning.

After thoroughly reading the original post, and the clarification, I must request additional clarification. Firstly, of course consumption values will be configurable. What I'm asking is, what sort of algorithm are we looking at here? Constant values per chamber? Or, per chamber type...

I'm looking for clarification on two points. Firstly, what determines the TP consumption of a chamber? I had thought it was the block count, but since TPs are constant per entity, and the block count grows with power size, that wouldn't work. If each chamber needs a constant amount of TP, then...

For once, I find myself fundamentally disagreeing. Firstly, the mass economy would prevent the game from ever having trading or manufacturing. The removal of two important - if perhaps slightly flawed and under-developed - aspects of the game for the sake of inventory management? (I'll say it...

Right. We're doing this, huh? Fuel working or not is besides the point. The question is, rather, what for? What purpose does fuel serve? Speaking of fuel as I usually do, as an addition to the current game, I think the answer is clear. To introduce, and balance against current ship-building...

Come to think of it, I would like to advocate the use of the word "pressure". In the vein of Lancake's suggestions, I suppose that would be "Chamber Pressure". Pressure has a long history as an energy system in pre-electric society. Pressure in a system is generally maintained at some stable...

It is not. Fuel isn't a fun gimmick to be put in the game, it's a useful mechanic to balance infrastructure and ship performance. While we can, technically, cannibalize current mechanics to create a fuel-like system, that is entirely besides the point of such a system. Except, perhaps, if one...

One thing to keep in mind is, StarMade parlance is very generic. Jump drives aren't "hyperdrives" or "subspace drives" or "zero-point-whatever". They're just that, "jump drives", because that's what they do. Generally speaking, the naming convention is to say what it actually does in the game...

These ideas just pile up, don't they? And furthermore: I certainly hope we shall be able to draw redundant conduits between chambers, in case one is destroyed.

Oh, and, a couple more things. More concerns: Consider easing the "stabilizer radius" rule to only count reactor blocks part of an intact reactor. That way, an auxiliary reactor can draw on more central, well-protected stabilizers. I am very happy about the reactor HP system. I always thought...

Wow. Alright, I caught this one early, it seems. I was, generally speaking, in favor of the first proposal, and wouldn't have advocated such an overhaul. Yet, this system appears to be good on it's own merits. My concerns: I am in favor of some system wherein multiple reactors can operate...

Even if I were to edit my post, the quoted version in your post wouldn't be altered. Read that, then. In any case, the forum would add a line about the post being edited if I had done so.

Right. My apologies for misreading.