- Joined
- Apr 30, 2014
- Messages
- 17
- Reaction score
- 12
I know what you are already thinking: "Oh crud, another Ideas Post. When will these end? Why should I even read this?" I know many of you are fed up with the countless, innumerable ideas posts out there...to the point of near-boredom for some of you, but this post is different. I am not only considering ideas which may actually be possible in the near future, but which have relevance to our main "pet peeves" about StarMade, and how easy it would be for the Devs to implement these features in the course of their updates. Also, I will not just be another "random idea generator" (as most of these posts tend to be), but rather I shall attempt to concisely direct my thoughts into a format which is clear and understandable. I shall be listing these based on how quickly they should be addressed by the Devs to fix certain bugs, followed by the "things that would be cool". But, enough chatter without addressing the issues at hand. Let's begin with my biggest pet peeves:
#1: Numerical Input:
Need: Should be Addressed Soon
Reason: Currently, changing something such as the size of the Advanced Building Tools are based by using...of all things...sliders. While this has been usable thus far, unfortunately, it is very difficult to use. My proposal is a simple one: the Textbox. By adding these to the sliders, players have a choice of utilizing sliders or simply inputting the number into the textbox. This would also be a simple matter to code, so it wouldn't be hard to address.
#2: Docking Fix
Need: Should be Addressed Soon
Reason: Docking is one of the biggest pet peeves of many players. Currently, Docking is bulky, awkward, and unusual. It is hard to dock any form of vessel, but even more so with larger vessels. My idea is a simple fix, which would only require a few minor changes of code. The block currently known as the "Docking Enhancer" would become more of a hanger-area checker. It could be placed down, accessed with the interact (default: R) key, and then the players could set an area. This would be projected like the docking area, and would serve much of the same function: To ensure that the player does not place blocks in the area which will become the hangar or landing pad. The "Docking Module would loose this function, and would then be re-configured to emit a docking beam upon receiving a Logic Signal. To dock, there would need to be a clamp on the receiving end. This would then dock the two together, forming a bond which must be broken by removing the logic signal. The pros of this is that the need for a massive "docking area" to dock a massive ship is negated, but players still have the option for a docking area (at least, temporarily), to ensure that the ship can dock. What's more, inter-ship docking becomes much simpler, but still requires some planning and skill, as does undocking. This is, by far, the simplest, but most effective option.
EDIT: 3-24-2015
I have heard that Schema and the devs have their own ideas about this. While I hope I have stumbled upon their idea, only time will tell.
EDIT: 3-31-2015:
Check out the Dev Blog here.
I appear to have nailed it...sort of.
Docking will now be mass-based, but require you to link two docking points together...at least, that's what I've gathered from the post's descriptions. Essentially, Mass-based enhancers must be provided to dock larger vessels together. I have no idea if this works for all docking clamps or if each one must have it's own, but still an improvement, especially since the docking area will go away!
#3: Turret Control:
Need: Not As Important
Reason: Turrets have a tendency to...go wild...if left unattended. While this is sometimes the desired effect, it can often be an annoyance as well. my solution? If you don't want the turret to fire, link a control unit to it, which will tell the turret who is a friend, and who is an enemy, by accessing the faction's relations list, or by inputting player/faction names into the unit. This can also allow the turrets to identify "neutral" parties as enemies, or, force the turrets to ignore such parties without given orders. This would be easy to implement, and it would greatly improve the quality of the game.
#4: Rails:
Need: Not As Important
Reason: Rails are a great feature that is being added into the game, but how they should work is subject to speculation. My idea is quite simple, but works the best. The "Rail" Block simply serves as an framework for the transit, but actual motion is achieved by the "Wheel" (working title) Block, which connects to it. At points in the Rails, "Stop" blocks are placed, which can be named (to indicate locations at which the train/elevator should stop). All the locations connected by the rail network can be picked up by some form of Database on the train, linked to the wheels that will stop the train on the Stop Blocks. This allows the creation of items such as turbo-lifts (elevators that can also move from side-to-side), as well as automatic trains, or even potentially segments of rails to act as signals. It might be difficult to code, though.
EDIT: 3-24-2015: Again, the devs have their own ideas here. I hope this is the solution they implement, but I'm unsure.
EDIT: 3-31-2015:
Again, I refer to the dev blog here.
I again was close: With this system, the rail docking connector links to the rail, which travels in a certain direction. This does not require either ship to have mass modules (at least, I don't think so). Finally, the rails are like a powered conveyor belt, so you need only a logic block to make them go.
#5: Liquids under gravity:
Need: Might be Cool
Reason: This is just me thinking outside the box, but it seems to me that Liquids (like Water, and Lava) should be Fluid, and the player should be able to pass through them. This adds an interesting point: If Water and Lava flow, how, then, should they react in space? My solution: Water is non-flowing when outside of gravity. This means that all liquids in space (such as on asteroids) remain a single source block, while liquids under gravity would flow a certain distance. This would add realism to gameplay, as well as make things more exciting for oceanic splashdowns and the like, but the coding might be hard to implement
#6: Tubing:
Need: Might be Cool
Reason: kupu has recently indicated in his thread that there are new decoration blocks in the works as well. The post is here. One of the items mentioned a water conduit, and that has me thinking about how that conduit would be useful for transferring liquids from one point to another. Essentially, one end of the pipe would be placed near a liquid source, and the liquid would be pulled along the pipe to the other end, where a source block would be created at the other side. Again, the coding/visual effects would be difficult to implement.
#7: Chairs:
Need: Might be Cool
Reason: The idea for a block that you can sit in is not new. Schema added the feature to "sit" on slopes, but this is odd-looking without a block that looks like a chair. My idea adds in two main types: Seating chairs, and the Pilot's Chair, which acts as a seat AND a place from which to pilot the ship (and fire weapons). It would be interesting, and it would serve a function as well. Also, it's pretty easy to code.
#8: Visual Screens:
Need: Might be Cool
Reason: Using a visual screen and a camera to look at a view of other than where you are is a cool idea. Might be difficult to code though.
EDIT: 3-24-2015: Change that to "nearly impossible to code". This may not remain on this post, due to how cameras work, this is an almost impossible task, plus the lag would be unbearable.
#9: Spacesuits:
Need: Might be Cool
Reason: One of my annoyances is that there is only the helmet and the player. It just seems off in a game set in space to not have spacesuits. Of course, this would be tricky to code.
EDIT: 3-24-2015: It seems the devs have already thought of this, and I am interested to see what comes of it.
#10: Helm Console:
Need: Might be Cool
Reason: Long journeys in StarMade have a tendency to be...boring. You spend a ton of time in the ship core, because out-of-core navigation is impossible. The Helm block changes this by allowing the player to set coordinates and have the ship travel there under it's own power at a speed the player sets. While en-route, the ship will actively avoid all obstacles and will actively steer a wide berth around enemy ships and bases. It may be tough to code, however.
EDIT: 3-31-2015:
The devs are interested in a console like this...we'll just have to wait and see.
This is all I have thus far, and I will continue to modify this thread with updates as I think of more things that could be added/fixed during the course of the game's updates. Please, feel free to suggest your own ideas in the comments.
#1: Numerical Input:
Need: Should be Addressed Soon
Reason: Currently, changing something such as the size of the Advanced Building Tools are based by using...of all things...sliders. While this has been usable thus far, unfortunately, it is very difficult to use. My proposal is a simple one: the Textbox. By adding these to the sliders, players have a choice of utilizing sliders or simply inputting the number into the textbox. This would also be a simple matter to code, so it wouldn't be hard to address.
#2: Docking Fix
Need: Should be Addressed Soon
Reason: Docking is one of the biggest pet peeves of many players. Currently, Docking is bulky, awkward, and unusual. It is hard to dock any form of vessel, but even more so with larger vessels. My idea is a simple fix, which would only require a few minor changes of code. The block currently known as the "Docking Enhancer" would become more of a hanger-area checker. It could be placed down, accessed with the interact (default: R) key, and then the players could set an area. This would be projected like the docking area, and would serve much of the same function: To ensure that the player does not place blocks in the area which will become the hangar or landing pad. The "Docking Module would loose this function, and would then be re-configured to emit a docking beam upon receiving a Logic Signal. To dock, there would need to be a clamp on the receiving end. This would then dock the two together, forming a bond which must be broken by removing the logic signal. The pros of this is that the need for a massive "docking area" to dock a massive ship is negated, but players still have the option for a docking area (at least, temporarily), to ensure that the ship can dock. What's more, inter-ship docking becomes much simpler, but still requires some planning and skill, as does undocking. This is, by far, the simplest, but most effective option.
EDIT: 3-24-2015
I have heard that Schema and the devs have their own ideas about this. While I hope I have stumbled upon their idea, only time will tell.
EDIT: 3-31-2015:
Check out the Dev Blog here.
I appear to have nailed it...sort of.
Docking will now be mass-based, but require you to link two docking points together...at least, that's what I've gathered from the post's descriptions. Essentially, Mass-based enhancers must be provided to dock larger vessels together. I have no idea if this works for all docking clamps or if each one must have it's own, but still an improvement, especially since the docking area will go away!
#3: Turret Control:
Need: Not As Important
Reason: Turrets have a tendency to...go wild...if left unattended. While this is sometimes the desired effect, it can often be an annoyance as well. my solution? If you don't want the turret to fire, link a control unit to it, which will tell the turret who is a friend, and who is an enemy, by accessing the faction's relations list, or by inputting player/faction names into the unit. This can also allow the turrets to identify "neutral" parties as enemies, or, force the turrets to ignore such parties without given orders. This would be easy to implement, and it would greatly improve the quality of the game.
#4: Rails:
Need: Not As Important
Reason: Rails are a great feature that is being added into the game, but how they should work is subject to speculation. My idea is quite simple, but works the best. The "Rail" Block simply serves as an framework for the transit, but actual motion is achieved by the "Wheel" (working title) Block, which connects to it. At points in the Rails, "Stop" blocks are placed, which can be named (to indicate locations at which the train/elevator should stop). All the locations connected by the rail network can be picked up by some form of Database on the train, linked to the wheels that will stop the train on the Stop Blocks. This allows the creation of items such as turbo-lifts (elevators that can also move from side-to-side), as well as automatic trains, or even potentially segments of rails to act as signals. It might be difficult to code, though.
EDIT: 3-24-2015: Again, the devs have their own ideas here. I hope this is the solution they implement, but I'm unsure.
EDIT: 3-31-2015:
Again, I refer to the dev blog here.
I again was close: With this system, the rail docking connector links to the rail, which travels in a certain direction. This does not require either ship to have mass modules (at least, I don't think so). Finally, the rails are like a powered conveyor belt, so you need only a logic block to make them go.
#5: Liquids under gravity:
Need: Might be Cool
Reason: This is just me thinking outside the box, but it seems to me that Liquids (like Water, and Lava) should be Fluid, and the player should be able to pass through them. This adds an interesting point: If Water and Lava flow, how, then, should they react in space? My solution: Water is non-flowing when outside of gravity. This means that all liquids in space (such as on asteroids) remain a single source block, while liquids under gravity would flow a certain distance. This would add realism to gameplay, as well as make things more exciting for oceanic splashdowns and the like, but the coding might be hard to implement
#6: Tubing:
Need: Might be Cool
Reason: kupu has recently indicated in his thread that there are new decoration blocks in the works as well. The post is here. One of the items mentioned a water conduit, and that has me thinking about how that conduit would be useful for transferring liquids from one point to another. Essentially, one end of the pipe would be placed near a liquid source, and the liquid would be pulled along the pipe to the other end, where a source block would be created at the other side. Again, the coding/visual effects would be difficult to implement.
#7: Chairs:
Need: Might be Cool
Reason: The idea for a block that you can sit in is not new. Schema added the feature to "sit" on slopes, but this is odd-looking without a block that looks like a chair. My idea adds in two main types: Seating chairs, and the Pilot's Chair, which acts as a seat AND a place from which to pilot the ship (and fire weapons). It would be interesting, and it would serve a function as well. Also, it's pretty easy to code.
#8: Visual Screens:
Need: Might be Cool
Reason: Using a visual screen and a camera to look at a view of other than where you are is a cool idea. Might be difficult to code though.
EDIT: 3-24-2015: Change that to "nearly impossible to code". This may not remain on this post, due to how cameras work, this is an almost impossible task, plus the lag would be unbearable.
#9: Spacesuits:
Need: Might be Cool
Reason: One of my annoyances is that there is only the helmet and the player. It just seems off in a game set in space to not have spacesuits. Of course, this would be tricky to code.
EDIT: 3-24-2015: It seems the devs have already thought of this, and I am interested to see what comes of it.
#10: Helm Console:
Need: Might be Cool
Reason: Long journeys in StarMade have a tendency to be...boring. You spend a ton of time in the ship core, because out-of-core navigation is impossible. The Helm block changes this by allowing the player to set coordinates and have the ship travel there under it's own power at a speed the player sets. While en-route, the ship will actively avoid all obstacles and will actively steer a wide berth around enemy ships and bases. It may be tough to code, however.
EDIT: 3-31-2015:
The devs are interested in a console like this...we'll just have to wait and see.
This is all I have thus far, and I will continue to modify this thread with updates as I think of more things that could be added/fixed during the course of the game's updates. Please, feel free to suggest your own ideas in the comments.
Last edited:
