Search results

No, that's exactly why this suggestion was posted. It would make it easier not to confuse bugs with just not-implemented-things.

Yeah, I do that too... Just go in and spawn a hundred Isanths and watch my missiles take them out one by one. Rapid missile turrets are great. Even tiny ones.

I support this all the way, especially since with the new HP system missiles seem to be king. It'll make firing missiles more of a tactical decision and less of something that you just do as much as possible with as many missiles as possible, and will provide an excellent consumable item that...

...Why? I never really use Steam by choice, but it something happens to be running on or hooked into Steam, I just let it run...

If there's anything here that I agree with, it's generally that SM needs a change in scale. Crappy, 2oo-meter-wide planets that still create lag despite being ridiculously small just won't cut it... However, this Level of Detail thing I dunno about. If we had something like a giant ball of...

Uh, IDK if I've missed something, but isn't this guy suggesting that the modular bits' systems are also merged formula-wise with the main ship? So if a ship has passed the softcap already, docking a reactor module would only give you another 25 energy per block, rather than working like a docked...

The game can be made better without removing the ability to roam freely... But if we must, then it should come in the form of needing food, oxygen sources, or something. Not fuel. Resource and shop distribution should definitely change though - There's a reason I wrote a really long topic about...

Wouldn't it be easier to just be able to create text boxes/circles/trapezoids, and format them like display blocks? The variables can just be [shield],[shieldCap],[selectedShield],[selectedShieldCap], etc.

No, I have a basic understanding of how CSS/HTML works... But I don't really like relying too much on code in a game setting. I'd rather be able to put in, color, and scale predefined parts, TBH, as lame and clumsy as that would be, than have to learn HTML to do something in a game. :\

Yeah... I once said, I'd rather have seen a living universe with depth but still only have wedges and blocks for ships and only missiles and AMCs for weapons, than tons of awesome building possibilities in a dead universe. (Granted, a few things should be added to ships no matter what, so...

I want custom HUDs too (Maybe the ability to design a custom HUD for your ships... A unique Aethi yellow-and-brown HUD would be cool) but I don't think this is the way to do it...

Personally, I'm more excited for the HP system. Apparently, by the next build it's supposed to be finished.

No... The Steam Early Access release was already stupidly early. The last thing we need is a full release; it would be a huge waste. Remember, as cool as the game's individual features may currently be, there are still no quests, no reason for faction war... Really, no reason to actually play...

How much HP do logic blocks have anyway? Because if we want, say, an 8-switch/8-button switchboard thing, all we need is a few bits from HP. (As long as Schema doesn't accidentally cause the block to take damage if we turn on our lights... :p)

There's no rotating the core, nor is there any hope of a feature to do so being implemented, due to the way Starmade's data structure works.

Not really sure how to begin this post, so I'll just get straight to the point. The idea is, there would be a new block (here referred to rather awkwardly as a Status Block) that is toggleable on and off. It has three text fields: One line to name the block, which would become the label you use...

Those two things are Schema's jurisdiction, not Kupu's... All he can do is take existing systems and make them prettier.

My god... Whatever you did, tell Schema to dump it in the next patch. Looks so much better O_o

I'm pretty sure turn rate is still calculated the same way. The only thing that changes now is the old core-as-a-turning-axis and the resulting stupid physics.

I like this, but there's probably a better solution. Personally, I'm a fan of some kind of "status broadcast block" system. Basically, there would be a logic block that you could name and assign two text lines to, one for the on state and one for off. (One field could also be left blank, for...