Jump to content

Sable Phoenix

Members
  • Posts

    91
  • Joined

  • Last visited

Everything posted by Sable Phoenix

  1. Why can't stations just mount weapons? They're already made from ships as a base.
  2. Goodness this is funny. I just made a post over on the suggestions forum discussing this exact thing, with the exact same thought processes behind it. It really makes no sense at all and just increases tedium.
  3. I don't see any reason that Independent Targeting should be such a rare property on weapons in addition to being penalized by costing damage. Why the heck do we even hire gunners if we are still required to still fire our weapons manually? All weapons should be able to fire manually with no gunners, and all weapons that have gunners assigned to them should be able to set independent targeting active, with no penalty to damage. Given that the the independent targeting will be hitting multiple targets at once, rather than massing its firepower on a single target, fights will tend take longer in general and your ship will be taking proportionally more damage over the course of the battle, which should be enough of a tradeoff for the flexibility of being able to target things outside of your forward cone. In addition to making things like mining and salvaging unnecessarily tedious and taxing to the hand and wrist, the rarity and penalties associated with independent targeting weaponry is a severe restriction on ship design; it highly incentivizes placing all your weapons at the front of your ship since most of the weapons will only fire when you tell them to and thus will only fire where you're looking.
  4. If you have mentioned it somewhere else, then you should've made your reply there as well. There's no point to make a new thread to address something that was discussed in existing thread 3-4 days before. The thread I mention was specifically talking about coloring thruster exhaust and weapons fire independently of their materials. I mentioned light blocks in passing as well. Different subject entirely. Why is that such a problem? Light block sprites fade away just as well. With Glow blocks you can modify the color as well as the size and shape. Light block sprites have a much larger and stronger glow around them and do not fade with distance nearly as quickly as the lighting around a glow block. You cannot get the nice diffuse glow around a pinlight that the light block sprites have by using glow blocks.
  5. Yes, I've tried that. Two problems: 1. The glow of glow blocks fades rapidly with distance. If you use small glow blocks to simulate running lights they will become nearly invisible at a moderate zoom length. 2. Glow blocks are square. Now, you could of course take the time to model a sphere using glow blocks, but that's time consuming and you'd still run into the light falloff with distance problem. An additional suggestion that would be nice would be to give us the option to make the lights on light blocks blink, like the ones outside space stations.
  6. Yet another cosmetic suggestion. I like the little cosmetic light blocks, but there are a couple problems with them. 1. The light is floating a significant distance away from the block itself, and the distance is unalterable. This is weird and annoying if you want to place the light flush to the hull of a craft. Could we get an option on the block to set the light's distance from it? Or if that's not possible, at the very least move the light closer so it looks like it's actually in contact with the block that originates it? 2. As I mentioned somewhere else, the color of the light itself is unchangeable. If we want red or green running lights on our iron craft, we can't have them. We have to work our way all the way up to Avorion to be able to place port and starboard running lights.
  7. In my opinion, having thruster arms on ships is great. I love the nods to realistic design in this game, and if or when we actually get out into space, ships with long arms for thruster leverage will be de rigeur. I'd personally love it if the game were even more realistic with us having to take into account center of mass and thrust differential and all that, meaning you have to really think about where you place your engines and keep them balanced to the ship's center of mass rather than slapping them on anywhere and having them apply their thrust equally across the entire aft face of the ship, but I understand that this game isn't designed to be an engineering- and physics-accurate simulation. Nevertheless the more steps we can take towards that, the better. Your typical sci-fi spaceship would actually be functionally useless in the deep space of real life. Seeing the game encourage ship designs that have at least token nods to realism, like Babylon 5's Starfury (my personal favorite starcraft of any sci-fi universe), makes me very happy.
  8. You're basically advocating the integration of the Kzinti Lesson into Avorion. The Kzinti lesson is, "a reaction drive's efficiency as a weapon is in direct proportion to its efficiency as a drive."
  9. The more I play with it the more I think that the entire weapons system needs to be rethought, and this proposal sounds pretty fantastic. It would pretty much fix my biggest sore point when it comes to ship building.
  10. My first ship got destroyed by pirates in a sector very far from my "home" sector. I managed to jump back to where the unfortunate circumstance occurred but I can't find the wreck of my first ship or any of the stuff it dropped. I have nothing except a couple salvage turrets since all my stuff was on the ship that died. At this point, if there isn't some way for me to locate my original ship's wreck, I might as well delete the galaxy and start over, since I will be in a much better place equipment-wise if I do that.
  11. A lot of the "cheaty" warp retreats could be fixed if the AI ships could use boost as well. Then the hyperspace blockers could boost to keep up with the player's ship, forcing the player to kill the blocker before getting away. Improving enemy functionality is always a much better way to increase challenge than to punish the player for doing something the game allows them to do.
  12. Okay so integrity fields are basically a flat 90% damage reduction to all damage received by each individual block? Is that only on the beta version, or public release? Because I myself have experienced (it was an experiment in my Creative Mode galaxy) ramming an asteroid with a small, fast iron ship at high speed while equipped with integrity fields. The only part of the ship that contacted the asteroid was a long, thin spar (a diagonal spar, so made up of multiple small blocks) on the front of the ship. The entire ship instantly detonated. Without the integrity field, the spar simply shears off, leaving the rest of the ship lacking a percentage of HP but otherwise unharmed.
  13. Some other games already do this and it would be great to see it here. The dev team looking at mods and deciding to integrate ones that fit their vision of the game could conceivably add lots of functionality while reducing their own workload.
  14. I think one of the dev team already mentioned, on a fighter thread somewhere I think, that they're looking at adding docking options for ships larger than fighters?
  15. Understandable. Cosmetic features are some of the last things that should be added, I just would like to know it is in fact planned. I also do not like the idea of paint cans dropping as loot to unlock colors; it feels very MMOish and doesn't really fit a game like this, IMO, but that's a different discussion. I would just like to have a full color palette (ideally a hex/HSB color wheel as I mentioned in another thread) to work with right from the start.
  16. You say that it's been "demonstrated" many ways how this idea would be a bad thing, but that's not really true... you've just repeated that it would, without really getting into the actual game mechanics of how integrity fields work and how changing them to function in this way would destroy the game. Frankly, getting so confrontational does more to weaken your argument than the OP's. I'll fully admit that I may not (and very likely don't) understand the mechanics of integrity fields, or how ship HP and damage are calculated and assigned, but I think what the OP might be looking for (and frankly, this is the way I thought integrity fields would work as it just makes intuitive sense, before reading on the forums how they actually work) is something like this: As I understand it, integrity fields not only apply a flat increase to the functional HP of the blocks they cover, they also tie those blocks' "life", if you will, to the hitpoint pool of the entire ship, meaning that if the block dies the whole ship dies. It's a weird mechanic that doesn't make intuitive sense, and can result losing an entire ship to an impact that only actually hits a single antenna. What if, when you apply an integrity field that covers, say, one quarter of your ship, the blocks' HP is tied to the integrity field generator, rather than the ship as a whole. In other words, the HP pool only consists of the blocks in the actual integrity field. Let's say that's 1000 HP worth. Let's also say that you take a volley of railgun slugs into that "crumple zone" that totals 2000 damage. Everything in that integrity field is simply sheared off instantly by 1000 of that damage; the remaining slugs are free to continue and hit the rest of the ship, if they're angled correctly, dealing their damage to whatever other parts of the ship they hit, if any. You mention that this would be too powerful when combined with shields, and that's entirely possible. Frankly, I think shields are too powerful already, but that is a different discussion for a different thread. Suffice to say this kind of mechanic paired with a reduction in shield health pools and effectiveness would allow for more interesting combat scenarios.
  17. I'm kind of surprised that there aren't any comments on this. I don't know if that means nobody else but me wants this, or what. Seems like it'd be easy enough to add.
  18. I actually have had this same idea, I think it's a fantastic one. Ablative armor and damage compartmentalization is definitely a thing in real life engineering and design, I don't see why it shouldn't be in this game either, other than the fact that the procedural ships won't really be taking advantage of it (although I could easily see that being included in their seeding).
  19. So... what if we want to have purple engine flares or laser guns? Currently, the color of a weapon or exhaust (as well as the light block, not the "glow" blocks which are colorable, but the little floating light object) are determined entirely by the material from which it is made. I'd love it if we could paint our weapons fire and engine exhaust the same way we can paint glow and hologram blocks.
  20. Oh cool, thank you! Suggestion withdrawn. ... although, this useful functionality is not documented anywhere.
  21. Mr. Nova, before lashing out in an unprovoked fashion, you should take the time to understand what you're ridiculing. What you're saying actually has no bearing on the original post. What the poster wants is a turret that will remain active even when its turret is turning to follow the reticle. You can see this behavior even on your starter drone. Start mining a asteroid, then turn the crosshairs quickly to target another part of the asteroid. The beam will shut off until the turrets catch up with the reticle. This leads to annoying stuttering if you turn your drone as your mining beams flicker on and off repeatedly. What the OP wants to see is turrets that never shut their beams off while the turrets are turning. I concur with this request. The flickering beams are highly annoying, for the sound effects if nothing else.
  22. Please add: the ability to set the "center" block of a subconstruct/prefab/block group. If you have made a ring, for example, it can be nearly impossible to place correctly because you're positioning it by a block somewhere on the edge of the ring, rather than at the center.
  23. What. I'm afraid to ask, but how many hours did it take to make each one of those? The detail level is beyond insane.
  24. Currently when you scale a block, it scales universally along that axis, so if for example you scale a block along the X axis, both faces that are perpendicular to the X axis will move towards or away from the center of the block. Sometimes this is fine, other times, it means that once you have finished scaling the block you need to reposition it in order to return it to where you wanted it. It would be nice if we had a "Grab Block Face" button that allowed us to select whichever block face the cursor is in contact with, and "drag" that block face so that it and it alone changes position along the axis of scaling. All other faces would remain in their original position, so if you've already got the block perfectly positioned but want to change its scaling in a single direction, you're not required to realign the block when you're finished.
×
×
  • Create New...