tiny suggestions that don't justify a thread

[therimmer96]

we have no way of suggesting things that don't really justify threads, so lets have a mega thread instead

mine are

1. Rails need to be faster. Dave can move faster than the top rail speed when moving in just 1 direction, let alone all 3. i am willing to be the main reason we all wanted them was for lifts, and dave can fly faster. the default shift speed of buildmode feels like a good top speed

2. the build helper should have a way to move, If you miss placed a circle generator, its going to be a fuss to get it correct because you need to go through the fuss of getting the exact number you had

3. the build helper should remember previous settings. sometimes we want to build a lot of incrementally smaller circles and don't want to go through the fuss of getting the right size and direction

4. the bars in the build helper should be replaced with text boxes and arrows. you can build up to 2km radius circles with the helper, the is not accurate enough for that

post your own below. These are just the small things I want that would probably take a few minutes to implement and would just make the game nicer

 

[Magrim]

I hope you don't mind a shameless plug for a thread I started that is pretty much a compilation of simple ideas from all over the forum.

 

[jayman38]

Combination Friction/Rail blocks that can serve as "tires" to move across an unlinked entity. When active, this block will provide thrust for the host entity, relative to the unlinked entity that is in contact, but not linked. To simulate friction, maybe have the effect/speed dependent on a combination of thrust perpendicular to the surface, and mass/gravity combo, which is effectively another form of thrust.

Linking a passive effect, like pull or push, to a gravity block, so that the host entity is constantly pushed into a direction as if by gravity, to simulate gravity, anti-gravity, or friction thrusters. This keeps the "car" planted on the surface of the asteroid or space station so that the friction rail tires mentioned above will maintain contact and friction coefficient with the unlinked entity. This effect should be light, but can be used as a low-speed, always-on automatic cruise control for vessels.

Make links controllable by logic, so that you can control links between subsystems. (Logic Transistors)

Logic detector that links to an activation ring, that can determine if an entity (vehicle) has any thrusters. this can be used to ensure that vehicles only trigger race waypoints if they have tires, not thrusters. Allow it to link to different system block types to detect different block types on the detected entity.

Example: A detector is linked to a friction-rail block and to an entity detection block to provide a "True" signal if the entity has a friction-rail block on-board. Similarly, if the detector is linked to a thruster block and to the entity detection block, it provides a "True" signal if there is a thruster on board.

If you make it so that the logic detector can be linked to logic, which is in turn linked to storage blocks, you'd have a very powerful way to control what and how many block types are detected. For example, Maybe you only want to send a true signal if there is a grapple and one of the astronaut weapons on board. (To send an activation signal to the anti-astronaut defense system.) Another example: Maybe the racing entity needs to have at least 2 friction-rail blocks (tires) and no more than 1 thruster block.

Greater-than, Less-than logic blocks: Used with a storage block or between two storage blocks to provide a number range to a logic system. (E.g. if the number of true signals are between 2 and 8, send a true signal...)

 

[Magrim]

Combination Friction/Rail blocks that can serve as "tires" to move across an unlinked entity. When active, this block will provide thrust for the host entity, relative to the unlinked entity that is in contact, but not linked. To simulate friction, maybe have the effect/speed dependent on a combination of thrust perpendicular to the surface, and mass/gravity combo, which is effectively another form of thrust.

Linking a passive effect, like pull or push, to a gravity block, so that the host entity is constantly pushed into a direction as if by gravity, to simulate gravity, anti-gravity, or friction thrusters. This keeps the "car" planted on the surface of the asteroid or space station so that the friction rail tires mentioned above will maintain contact and friction coefficient with the unlinked entity. This effect should be light, but can be used as a low-speed, always-on automatic cruise control for vessels.

Make links controllable by logic, so that you can control links between subsystems. (Logic Transistors)

Logic detector that links to an activation ring, that can determine if an entity (vehicle) has any thrusters. this can be used to ensure that vehicles only trigger race waypoints if they have tires, not thrusters. Allow it to link to different system block types to detect different block types on the detected entity.

Example: A detector is linked to a friction-rail block and to an entity detection block to provide a "True" signal if the entity has a friction-rail block on-board. Similarly, if the detector is linked to a thruster block and to the entity detection block, it provides a "True" signal if there is a thruster on board.

If you make it so that the logic detector can be linked to logic, which is in turn linked to storage blocks, you'd have a very powerful way to control what and how many block types are detected. For example, Maybe you only want to send a true signal if there is a grapple and one of the astronaut weapons on board. (To send an activation signal to the anti-astronaut defense system.) Another example: Maybe the racing entity needs to have at least 2 friction-rail blocks (tires) and no more than 1 thruster block.

Greater-than, Less-than logic blocks: Used with a storage block or between two storage blocks to provide a number range to a logic system. (E.g. if the number of true signals are between 2 and 8, send a true signal...)

Man, this is a really neat idea. I think it would fit pretty well in starmade as well. What would you do about changes in elevation I wonder? Also, this is cool enough to warrant it's own thread :p

 

[Ithirahad]

Here's a suggestion. Large entities should be divided into several bounding boxes, if they aren't already. When two entities come near one another it shouldn't have to calculate collision stuff for ALL of both entities, and right now it seems that that is how it's structured.

 

[jayman38]

Man, this is a really neat idea. I think it would fit pretty well in starmade as well. What would you do about changes in elevation I wonder? Also, this is cool enough to warrant it's own thread :p

Well, your tires would need to be at least 2 blocks long. The outermost block would be a wedge in the direction of the edge of the vehicle, with thrust pushing the vehicle up. Then when the bottom-facing "tire" pushes you against a change in elevation (cliff, hillside, street, etc.), the front of the "tire" group would thrust the vehicle up, theoretically overriding the downward thrust of gravity and whatever else is holding down the vehicle. A wedge is needed as the forward tire block, to provide the vehicle with both upward and forward thrust, so that when it clears the "cliff", there's enough forward movement to get the vehicle's down-facing tires to propel it forward once more.

You could theoretically design a full block as the two-direction "tire", but a wedge would be more intuitive and could be built into a relatively round "tire" group.

 

[lazarus78]

Artificial horizon and controls to orient your ship in any direction. Something ive been wanting for a while.

 

[Awdred]

Glad I noticed this before making a thread.

I thought for my first post on the forum, I'd make a suggestion.
I think mobile bases should be possible. By this I mean, a ship that can do all of the basic survival stuff you need. I was building a ship, hoping to make it my base, but couldn't put factories. I've heard that you can't put a shipyard in them, which would be really cool, even if it was only big enough to make drones or turrets.

 

[therimmer96]

Glad I noticed this before making a thread.

I thought for my first post on the forum, I'd make a suggestion.
I think mobile bases should be possible. By this I mean, a ship that can do all of the basic survival stuff you need. I was building a ship, hoping to make it my base, but couldn't put factories. I've heard that you can't put a shipyard in them, which would be really cool, even if it was only big enough to make drones or turrets.

Schine is thinking about a capital ship system that would allow ships to have station systems on them, but at a severe cost to the ship, making it not feasible to be a usable ship in ordinary situations, but still mobile

 

[Awdred]

Schine is thinking about a capital ship system that would allow ships to have station systems on them, but at a severe cost to the ship, making it not feasible to be a usable ship in ordinary situations, but still mobile

Yea, something like that would work in my opinion.
Would we be able to mark them as faction home bases? The could be abused, but it would be good to have if I don't want a stationary base.

 

[GaeasSon]

Well, your tires would need to be at least 2 blocks long.

I don't think so... Let the"tire" be a visual effect projected outside the block, like the thruster plumes. The effect is a black opaque torus or cylinder centered on the bottom of the tire block
The default tire "1 block" projects a 1/2 block diameter tire, essentially it's a little roller that sticks out the bottom of the block.
Tire geometry is based on the shape of the block cluster:

• by default, the bottom most block (lowest y coordinate) in the group becomes the axle, just as the forward most block in a weapons group defaults as the emitter.
• The diameter of the tire is .5m*the x+y dimensions of the group bounding box.
• The width of the tire is .5* the z dimension of the group bounding box.

Game wise the tire works like this:

• The tire itself clips through and neither affects or is affected by the blocks of the structure to which it is attached.
• Several un-rendered collision blocks are created within the projected tire geometry.
• The cardinal edges of the tire (top, bottom, front, back) collides with other entities just as solid blocks do.
• other collision blocks that would be rendered on the edge of a tire of radius 5 or more do not collide solidly, but are just trigger areas that deflect the wheeled structure in whatever two dimensions are opposite from the quadrant of impact.

Other thoughts...

• A gravitational stabilizer, that tends to keep your structure oriented to whatever gravity you might be interacting with.
• Gravity blocks should double as gravity plates. Let them (by default) generate a trigger area in empty spaces at their top and bottom. Let them automatically attach any entity (npc,player or structure) that collides with the trigger area.

On a related note...
If you place a single tire block, wheel down, then place a bobby AI module on top of it, both blocks should disappear and be replaced by a robot NPC of your faction. Shhhh. this should be an undocumented feature.

 

[GaeasSon]

• On the circle build helper, there should be a check box or a button next to each angle slider that allows you to instantly set the slider for 90 180 or 270 degrees.
• Docked entities should be able to move along rails from one structure to another, allowing for systems like hangar/carrier elevators.

 

[jayman38]

I don't think so... Let the"tire" be a visual effect projected outside the block, like the thruster plumes. The effect is a black opaque torus or cylinder centered on the bottom of the tire block
The default tire "1 block" projects a 1/2 block diameter tire, essentially it's a little roller that sticks out the bottom of the block.

...geometry...

Game wise the tire works like this:

• The tire itself clips through and neither affects or is affected by the blocks of the structure to which it is attached.
• Several un-rendered collision blocks are created within the projected tire geometry.
• The cardinal edges of the tire (top, bottom, front, back) collides with other entities just as solid blocks do.
• other collision blocks that would be rendered on the edge of a tire of radius 5 or more do not collide solidly, but are just trigger areas that deflect the wheeled structure in whatever two dimensions are opposite from the quadrant of impact.

...secret mouse bot construction...

I am envisioning the tire circle going all the way around the placed block, like this:

By having the block entirely surrounded by "tire" effect, this not only creates a true, and rather nice-looking tire for the game, but could also addresses problems with encountering 1-block "cliffs" by letting the tire climb vertical surfaces in a more realistic fashion. This is natural when the vehicle is on a planet surface. I also need to think about odd-ball situations such as ceiling crawlers, so front/back tire surfaces should simply thrust in a direction opposite of the surface that the vehicle has been traveling on. So a regular car on a planet surface will naturally try to crawl up, if it encounters a cliff, while a ceiling crawler will try to move down if it encounters a cliff.

You could maybe have tire surfaces that don't completely encompass the block, but I don't think that would look as good.

And of course, there's the decoration possibilities. Maybe have a tire link-able to a light for different tire shader hues. Some people might want custom green, white, or purple tires on their vehicles. Maybe linkable to rail speed controllers for alterable top speeds.

Tire blocks would be a way to introduce round shapes to decoration, so color-linking would be even more important for that. One could create a round column by stacking side-ways-oriented tire blocks, as per your geometry ideas.

 

[zetacross]

- Middle-click to copy current block or select current block in inventory including rotation.
This will save every starmade building 30% of the time rotating a block or selecting what they want. . .

- A low intensity, high range light which helps brighten a big place but doesn't make it look like I nuked the insides of my ship.

- Hold down shift to run, hold down Ctrl to slow down

 

[decurr]

In the build helper, I would like to be able to just type in the number besides just using the sliders. Also for the circle portion, I would like to have a width and thickness option. To explain, assuming the current radius is the outer radius, thickness would say how many blocks would project into the center of the circle, and width would say how many blocks long the circle would be (which basically would turn it into a cylinder).