Draxiss

It'd be kind of neat if, instead of saving the ships such that each blocks size is recorded as-is, the parts were all scaled as if the smallest component was a certain unit length, and then appropriate scaling is applied to the ship. This is hard to explain in a way that doesn't look awful.

+1 That is all

+1 I appreciate that you mentioned computer cores. The bonus they provide towards gaining another slot should also be distinct, like all the other bonuses given by components on your ship. Does it really just artificially inflate your volume, and that's it? That's what the Wiki says, and I've not found anything to contradict it. I think modders would appreciate having the ability to control system upgrade slots.

An angled ANYTHING block would be nice. However, that'd require the Devs to change the way they index block types. As it stands, each (angle, function) permutation is registered individually, based on what I've seen of the wiki and documentation. That should REALLY be fixed before blocks are opened up to modders.

Was . . . was there supposed to be more to this statement?

Bumping because max speed is weird. Max speed should REALLY be determined by how quickly you can slow down, and you shouldn't need a module to eliminate it. Until you reach relativistic speeds, you shouldn't 'leak' energy to go faster. I feel like I'm flying through soup, not the vacuum of space. If we ARE going to go down the route of swimming through soup in space, I agree that more mass shouldn't increase max speed, so simply scaling a vessel up shouldn't allow it to go faster.

I did think the absurdly close range was unrealistic. Being able to zoom in would be HUGE. I don't think it should be a block, though; it should be available by default.

After taking a look at the API, it's clear that the function of a block(whether it's an engine, thruster, battery, computer, etc.) are not distinct from the shape of a block(whether it's a corner, slope, edge, etc.), the way the 'material' property of a block is already distinct from this. You have to list out whether it's an edge armor, slope armor, corner armor, or cubical armor block individually, and your list is already getting quite extensive, and will only get longer the more blocks you add. By separating the 'shape' property from the 'function' property, you'll increase the polymorphism of your design. If there's a block that you wish to limit the shape on, add some sort of 'blacklist' property to the 'function' aspect, so that, for example, computer blocks cannot be edge blocks. (You could also do a whitelist sy)stem, or some combo thereof.) It will SERIOUSLY help you out later on, especially since a lot of players want things like edge engines or some-such. If you really want to be kind to your player base, implement a conversion tool to read old versions of ships and convert them to the updated system, silently in the background. I'm actually surprised you haven't done this yet. It seems like something that will REALLY help you AND modders out in the long-term. Of course, I'm not writing your code and there's a real possibility that you've already done this and I'm just looking at the wrong thing in the API. ALSO of course, I'm not writing your code so there could be a very good reason for why you're doing things the way you're doing them. But just in case, I reeeeaaallllllyyy want to make sure you guys see this and are at least considering it. Poiymorphism 'nd all that. Unless I'm thinking of modularity. Heck. I get those mixed up all the time. P.S.: Speaking of shapes, I'd love to see Round Things ®© implemented in the future. Having Round Things ®© has the potential to greatly improve performance because players don't have to use so many blocks to emulate Round Things ®© using lots of other blocks.

I'm not sure whether the engine could support rotating blocks, but if it can that this would be a pretty cool addition. I like most of your suggestions, in fact. Don't have a particularly strong opinion about the Transporter Room idea. Someone recently suggested curved blocks as well, so I'd suggest +1-ing that post as well. I think that the function of the block (engine, armor, hull, etc.) and the shape of the block (slope, edge, curve, etc.) should be stored as two distinct values, and the UI should reflect that. Then, for rotating a piece, two sets of rings reflecting the functional rotation and a menu reflecting the shape-based rotation show up, one inside the other. Also, engines should be able to face directions besides to the aft. I do like the propellant-based engine idea, and the variety you suggest sounds pretty cool. I don't think forcing the player to deal with a UI for every engine block they place down is such a good idea, though. Maybe just have each kind of drive be it's own block? The Impulse Drive Manifold sounds like a reactionless drive, which would work great as a replacement for the current Inertial MoistenerDampener.

It'd be nice if the UI reflected that, but thank goodness!

Ahhh okay. Getting a warning when health is low WOULD be pretty nice. It's easy to ignore that health bar. It sort of . . . fades into the background. Maybe if it lit up whenever you were hit? Avorion's UI in general seems to have this problem where aspects of your environment are hard to distinguish.

Adapted from this Reddit post: https://www.reddit.com/r/avorion/comments/6s4306/suggestion_inertial_dampeners_make_no_sense/ Let's get some things out of the way: In layman's terms, an object's inertia is that object's resistance to change in velocity. If you could somehow magically increase your inertia while flying through a vacuum, your velocity would not change. However, you'd have a harder time accelerating. The opposite is true of your acceleration if you magically decreased your inertia, and your velocity would still not change! 'Acceleration' refers to any change in velocity or direction, unless specified otherwise. Instead of saying 'decelerating', all you're really doing is accelerating backwards. Moving left simply is accelerating backwards and left such that your forward speed is canceled out and accelerating left at the same time. Note that this doesn't have to do with rotation (relative to outside objects, that is), since you can spin around without changing velocity. Nothing about Inertial Dampeners makes sense. Avorion's Inertial Dampeners do not exert any change over your vessel's inertia, outside of the additional mass they add. They no not cancel out any deleterious effect caused by your vessel's inertia. Inertial Dampeners could negate the internal deleterious effects of changes in Inertia, such as by reducing collision damage, allowing sharper turns, or allowing for faster acceleration. Instead of being crushed by an impact, your vessel simply bounces off. Integrity Field Generators negate the negative effects of inertia more than Inertial Dampeners. Inertial Dampeners could also negate effects relative to external forces, by simply increasing your vessel's inertia such that collisions don't affect you as much. Instead of being crushed by an impact, the thing you impact is crushed. Avorion's Inertial Dampeners do not moisten your vessel's inertia. In fact, I'm pretty sure fluid physics aren't even in the game. It is distinctly more likely that the name you're looking for is Inertia Damper. Avorion's Inertial Dampeners are not what they claim to be. They are reactionless drives that can only impart acceleration in arbitrary directions. They acceleration your vessel towards a speed of zero. Not zero relative to anything, mind you. Just zero. The lore states that they work by generating "subspace friction," and while I'm willing to believe that the 'subspace' the game refers to is simply another way of looking at the properties of spacetime, it seems just a liiitle bit silly that whatever makes up subspace just happens to slow you down to match the surrounding matter. All that being said, here're my suggestions: * Rename 'Inertial Dampeners' to 'Reactionless Drives,' 'Cavitation Thrusters,' or some-such. Use your imagination. Remove the arbitrary limitation that causes them to ONLY brake your vessel. If needed for balancing purposes, make them directional. Make them more expensive/less energy efficient than normal engines/thrusters. In fact, make versions of said reactionless drives that correspond to engines, 2-way thrusters, and 6-way thrusters. * If you want your new Reactionless Drives to feel special, require thrusters and engines to be exposed in order to function. Two- or six-way thrusters have boosted output to sides that are not covered, so it isn't awful to use them. Allow players the option to convert covered thrusters and engines they've already built into reactionless drives of the same kinds, to minimize broken builds. At the end of the day, Reactionless Drives should cost more in terms of money and energy for similar outputs, but allow greater freedom in controlling their craft's design. * Re-add Inertial Dampeners Inertia Dampers. Instead of providing acceleration, actually have them affect inertia! When added to a vessel, that vessel has an easier time accelerating under it's own control, is more impact resistance, and is less susceptible to external forces affecting it's momentum. Allow the vessel a faster turning speed, and potentially even increase the vessel's rotation speed limit beyond 4 Rad/sec. Reduce the effects of kickback. Basically, have Inertia Dampers cause the vessel to act as if it's more or less massive then it really is, depending on which is more advantageous. Having atmospheric physics is space is NOT intuitive. A significant chunk of Avorion's audience is familiar with games like KSP and Space Engineers. Avorion is a game that takes place in space. Implementing atmospheric rules is not intuitive when I am trying to play a space game! When I am playing a space game, I expect space rules. There's a very physics-y feel to the game; you're supposed to learn spacial awareness, understand momentum, and that building RC Thrusters (AKA just 'Thrusters') away from the center of mass allows you to turn more quickly. Inertial Dampeners are jarring because they conflict with the at least somewhat realistic aesthetic of the rest of the game. Side Note: The empty vacuum of space slows you down far too quickly. Am I flying through space or soup? TL;DR: Inertia Dampers don't make sense, add Reactionless Drives while minimizing build breakage, and make Inertia Dampers actually do stuff to inertia. Also, call them Inertia Dampers.

When you've detected an enemy, they are highlighted by a dark red targeting symbol. This is very hard to see against a black sky. I'd appreciate if it were a bit brighter or otherwise made more visible.

I don't quite understand what you mean. Do you mean a warning when you've built your ship's health too low or a notification when you've reached low health?

Several suggestions for fighters and other 'microships': First, I can't help but notice that fighters look kind of like crap up-close. The texture size doesn't scale with the model, and while that works on some ships, it doesn't work super well on small vessels like fighters. It'd be really nice if, when your vessel gets below a certain threshold, the vessel's texture scaled with the size of the vessel. While seeing the texture size change when scaling a ship can be a handy tool for determining how large or small it is, maybe instead use an actual measuring system, such as providing a sample distance? You could even just list the ship's dimensions in the corner. On really big vessels, I'm still okay with the size of the texture remaining constant to give a sense of enoromity. As discussed in the the roadmap for Avorion([url}https://avorion.gamepedia.com/Roadmap#Planned_Content[/url]), fighters are getting a dodge mechanic. Will this apply to players as well? It'd actually be pretty neat if players leveled up their ability to function as pilots (and other roles) as a compnent of the Alliance update. What about for vessels that are not fighters, but are particularly small, fast, and/or maneuverable? I'd love to see a player-built vessel, not meant to be mass-produced like fighters, with these kinds of capabilities (I really like playing microvessels). It'd be kind of cool to build a microship with dodging capabilities, provided it's got a pilot OR player controlling it. Also mentioned in the roadmap was the possibility of AI Crew. I hope this means that a ship has the ability to spawn in remote-controlled fighters for AI Modules that include pilots. It'd certainly feel more space-y to have remote, unmanned drones in addition to regular pilots.

I've not had this issue but I could run into it in the future. Plus-one-ing this so it hopefully won't be forgotten.

I really like the idea of voltron-ships as well. (Or in the real world, of multi-stage ships.) I was actually planning on posting this as well, but it looks like you beat me to it!

Note: Most of the this is directly copied from my reddit post on the subject: https://www.reddit.com/r/avorion/comments/6s3sh5/suggestionmod_idea_maximum_velocity_should_be/ I have updated my thoughts on the subject and added a bit with this post, though. For some reason, the Max Velocity cap is based off of how many thrusters you have, which makes no sense. The in-game justification is that it's for safety reasons, but allowing bigger ships to move faster than smaller ships sounds about the opposite of safe. Additionally, so long as the acceleration isn't too abrupt, there is no velocity a ship might travel at that will cause it to break apart from the stress or whatever. Instead, the max velocity in a given direction should be based on how quickly you can accelerate in the opposite direction, or just based on how fast you can go after a given number of seconds (say, 1, 2, or 5?). Maybe ships have the option of choosing between the two, so the cool maneuver where you turn around and boost in the opposite direction to slow down is still relevant. The reasons I've given so far have been based on a realism/sense-making perspective, but there's also good gameplay balance reasons to make maximum velocity based on acceleration over a fixed amount of time. This allows players to make small and fast ships, gives larger ships a building challenge if they want to stay quick and maneuverable, and means that you're a LOT less likely to bump into stuff because you're going too fast. Seriously, speed limits are there so you don't run into stuff. If people are running into stuff in spite of your speed limits, there is probably something wrong with your speed limits. If you base speed limits on how long it takes you to brake in 5 seconds or so, a much more intuitive approach to movement is had. I would like to point out that this suggestion doesn't negate the usefulness of the Velocity Security Bypass System that applying a max acceleration or somesuch would have. However, I really think really shouldn't be necessary to install a module to boost beyond the default speed limit; that should be a built-in option. Also, how do you manage to leak energy by maintaining your normal acceleration? I could see a non-linear relationship between how much energy you put into a thruster and the output in terms of acceleration yielding diminishing returns, but a constant acceleration should NOT become less efficient after you've passed some arbitrary speed limit relative to . . . whatever is deciding what a zero velocity is. Finally, am I flying through the vacuum of space or am I flying through soup? While I get that I would encounter the occasional particle in a vacuum, my velocity would not be affected AT ALL like how the game slows ships down. In fact, it'd be pretty negligible over the distances you fly in normal gameplay (not including jumping). I really want to have that feeling of moving up to a certain velocity, cutting the thrusters, and spinning around to shoot things like I'm in a Star Fury. (*coughBabylon5isamazingcough* ) I'm probably going to go into more detail on this in a later post, but for now, I'd just like to have an option to control the 'thickness' of a Galaxy. TL:DR: Base max velocity off of ability to brake and NOT off of vessel size. You shouldn't leak energy based off of velocity (with the Velocity Security Bypass). Stop making my ship fly through soup instead of the vacuum of space. Okay because I really like Star Furies and they're what inspired me, here's a few more links: https://www.youtube.com/watch?v=96idw23kHdY

I'm fine with it not being a high priority, but I hope the Devs do decided to implement Round one day. Being able to create curved blocks (maybe dynamically determine the curve?) would cut down on unnecessary ship complexity.

I could NOT give it a linear value based on material because System Upgrades have no 'material' property. They have a seed, rarity, and script, and whatever calls the script passes down only a seed and rarity, so that's all I have to work with to create stat bonuses from. If I used the distance from core as a parameter to determine the bonus, that would just mean that a given System Upgrade's bonus would change as I got closer to the core. The problem is, the scripts I have to work with don't get passed an instance of a SystemUpgradeTemplate, they get passed a seed and a rarity. For example, I cannot readily modify a script such as "arbitrarycts.lua" to set the number of bonus turrets and then later retrieve the value I set.

Sort of. Actually, based on your advice about RNG and distance to The Core, I'm actually trying to accomplish the opposite of what you describe. I want to eliminate the random components of System Upgrades. I'm want to be able to change the stats of a System Upgrade Module in a controlled many, such that I *wouldn't* have to guess-and-check my way to finding the right stats by trying out different seeds until I get the one I like. I want to be able to store the information I need about the module and retrieve it later. I'm looking to eventually create a command to give a user a System Upgrade with the bonuses and energy costs specified in the command. The two relevant sections in the documentation that have anything to do with this are SystemUpgradeTemplate and VanillaInventoryItem. The SystemUpgradeTemplate seems to be the most relevant; and confirms what I just said in an earlier post. The information the game uses to determine the stats of a System Upgrade is determined solely from a seed, rarity, and script location. All the stats are calculated from the seed and rarity, using the script! I am *trying* to find a way to create a special class of System Upgrade that does not use seeds to retrieve information about already-created System Upgrades. Instead, I'm trying to create special scripts that can store/retrieve, say, Radar Bonuses from stored bonuses. At this point, it looks like I must create a class that extends SystemUpgradeTemplate, and then figure out how to tell the game to use that extended object to call the script that actually details how to use that template. I'm sorry if I'm not articulating this clearly enough, but I'm having a lot of trouble figuring out what's going on and which scripts to look at next. I'm not even sure where the appropriate location to start writing a file that extends the SystemUpgradeTemplate. I'm currently just looking for classes that call SystemUpgradeTemplate to try to decide where to go from here.

For that matter, where should I look to find the script that manages the storage/generation/modification of System Upgrades? For THAT matter, how would I go about creating entirely new kinds of inventory items? So far, I've seen System Upgrades, Turrets, and Licenses.

My end goal is to be able to control the creation of a given System Upgrade in a similar way to how I can control the creation of turrets: with commands. I do not simply want to change how the Upgrade Script analyzes seeds (and rarities); I want to find a way to store more information about the upgrade so that a custom-generated upgrade will maintain its properties. The best workaround I can think of is writing an script for a new kind of system upgrade, called a Custom Upgrade, that uses the values passed through a seed in a predictable and controlled manner. The problem I'm running into is that my (currently unoptimized) script requires the seed to be around 80 digits long (in base-10). As this is a little bit more than the 32-bit integer I found in the documentation, I'm looking into ways to compress/unpack the needed information. Is the seed variable passed to System Upgrade scripts an instance of the Seed class found in the documentation? Is it possible to store and/or use multiple seeds for one System Upgrade? For that matter, is it possible to store other kinds of data for a particular System Upgrade?

Basically, my problem is that I want to be able to create modules whose properties I could control, the way there's commands to control the properties of turrets. Since the only reference to seeds I could find gives a 32-bit integer for the value, that's all I have to go on. Does anyone know where seed generation for turrets is done? Is there any way I could store additional information about a module that I've custom-made? Maybe if I set up a .txt file that has a list of custom turrets, treat the seed like a key to a particular custom configuration, and have the game reference the .txt file . . . ?

Thanks for the info! That confirms what I was feared: you cannot directly control the properties of an upgrade unless you are able to calculate the exact seed needed to get your results. This makes what I'm trying to do a lot harder. Is there a limit to the length of a seed?