-
Posts
1,540 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Events
Posts posted by Lurkily
-
-
For autonomous completion, what would your directional sensors that are gravity-tuned point to? Center of the play area?
-
59 minutes ago, Alpino_WILL_STEAL_ oats! said:
We could create a separate part for this problem one that has the property of only passing inputs on to things it’s connected to.
That's what Entity's transceiver block suggestion would be good for. I also, though, want to be able to enable/disable splitter blocks and wireless transmitters.
-
Pathfinding for this isn't too intensive; orient toward the target, move laterally. It would have trouble dealing with terrain, but then, every enemy extant has trouble with terrain.
-
Not a great fan of messing with sensors. It's like messing with logic; intelligent behavior relies on sensors and awareness as much as it does on logic.
-
I think it doesn't solve the issues that having multiple connected pieces creates. This was tried out before the closed beta, as told to us by -- I want to say Micah said it? -- and it apparently made physics calculations very consumptive.
-
21 hours ago, ManTheMister said:
Logic splitters/joiners are already in the game, and work similarly to what you say.
I have to agree that splitters and transmitters in their current form are kind of limited; you either get all or nothing, and you can't change it when circumstances change.
-
I think changing the snap grid would be rather weird and messy, and introduce a lot of problems with forgetting the grid orientation and accidentally messing up your design so you have to fix it.
-
Wind should be a CW or CCW thing, rather than a left or right thing, given the radial nature of planets and gravity here.
-
What Mister means is that parts have a parent-child relationship. Permitting 'orphans' without parent parts would make more complicated in terms of code, and the handling of those complications would introduce opportunities for glitches and crashes.
Other solutions might present the same opportunities, though. A 'select children only' hotkey or button that would let you drag children to a new parent, then connect and orient them.
-
I think as the game's refined, mission types for Plasma and Bio will probably crop up. I agree with a damage that wouild damage terrain, but I don't think Plasma should be it. With terrain effects (like freeze or fire) possibly being applied to terrain, I think something new should be devised with effects largely directed at terrain removal. (Preferably without damaging ore.)
Bio is something I'm conflicted on. I've never had a use for adding terrain, and beyond mission objectives, I don't see a use for it emerging.
-
This goes back to categorization suggestions; I'd like to have tabs on the drone list, and a drop-down on each drone to assign it to a tab, and each tab can be marked as having its listings available for sumo, for missions, or for mission types - collection missions, freeze missions, combat missions. That seems like the most basic possible way to handle it without having to rebuild the UI.
Implementation of a directory tree would be nice, and implementation of it is pretty well-explored, but in the end, I'd like the option that leaves the most development time for gameplay features.
-
8 hours ago, notsew93 said:
This is also why i suggested Dirt as an alternative. If we are going to power anything with a non-renewable energy source, it has got to be convenient.
119 minutes ago, CyrusDaSquid said:Great idea, but maybe not resources. They’re just too rare to be used as fuel for parts.
What about my other suggestion; using green ore soley as a consumable fuel for certain parts? Regardless of commonality, consumption can be tempered to make it more or less valuable.
-
I think Nimbatus thrives in simplicity; simple parts working together for something more complex. That's why a veteran of 3-D shooters can pick this up, and make a drone that can turn to face and enemy, and shoot at it.
All I need from distance sensors - and implementable without such a serious code/UI rework and without increasing the learning curve - is more options for targets.
- Nearest Enemy
- Nearest non-ore terrain
- Nearest ore
- Nearest enemy projectile
- Nearest object. (Barrel, meteor, broken ship part)
- Hopper
- Specific drone part
- And of course, gravity/sumo center, and cursor.
Get me distance sensors (similar to altimeters) that do the same thing, and I'll be happy as a pig in . . . well.
-
What about unlocking editor parts this way?
-
1
-
-
Also, I edited the earlier post slightly; thought I might ninja it in, but I guess not. Just FYI.
-
No, didn't like Terrarria. It was one of the old FF games, 1 or 2 US, which means . . . . . what, 4 or 6 in the original numbering? One of the characters was a gambler that could basically buy damage.
-
I guess I'm just not certain that resource consumption is really the key. Anytime a game has an ability fueled by a barrier to progress, (like guns that shoot gold, or abilities that throw coins for damage (Was that FF6?) ) it just doesn't exist to me. Advancement always trumps the temporary gain.
What if the green resource was NOT used in progress and tech trees? That can be exclusively for drone consumption by parts.
Later, you can convert other resources to it, so that you can still use it to sink excess once you complete progression.
-
1
-
-
I wouldn't be fully opposed to a momentary invulnerability that also completely disabled you. Blindness is too much. Blackness on a screen is like silence on radio - you just can't have it.
I also, though, think i would prefer specifically tailored shields to specific damage types; blast shields that nullify AOE is a good one. Collision shields that collide with terrain, objects, and enemies (as long as it doesn't transmit the full impact to the shield generator on your ship, ouch,) might be nice, too.
-
2
-
-
I think I meant something different by one required use; I remember saying it, but not the exact context. I think it was about being useful only in very specific situations;
What I was aiming for there was more about implementing an actual weaponry infrastructure beyond just running everything on energy. I actually don't think making a complex weapon infrastructure is necessary, but when it comes up, I always try to put a couple of cents in.
-
1
-
-
My favored solution is to either start things unprinted, and not to print beyond another factory; that means stacks of factories would have to print down the line section by section.
I also like the idea of having it print direct children first, then grandchildren parts, then great grandchildren, building out from the source.
-
Wait, I didn't? Crap.
EDIT: Yes, yes i had.
-
20 hours ago, Alpino_WILL_STEAL_ oats! said:
You could do the exact same thing with a directional sensor and thrusters
While you ARE correct, I would love a hinge that's able to follow directional sensor targets. When and if we get things like nearest enemy/nearest ore/hopper/etc, this may go a long way to helping drones react fluidly and intelligently. Directionals are too big to go on most hinged assemblies, and the shake in any hinge with clearance around it also distorts the directional sensor's reading.
-
Other modes will mostly be impacted by enabling cleaner, more compact design, and better organization and protection of logic.
-
I suggested just this in closed alpha, harped on it almost.
I would kill someone for this kind of hinge functionality. I'd also kill a second person to have directional-sensor follow targets.
-
1
-
Random Ideas
in Feature Requests
Posted
To explain why, these posts are presented as a feature-tracking system, so people can vote them up and down, and devs can gauge the community's need for a feature, and mark a feature as complete or implemented. This is not a discussion forum.
To post these suggestions together makes the votes useless to the devs, as they can't judge what is valued when a vote is counted. The post is also useless as a focus group because there are a number of mixed ideas in discussion.
Lastly, it can't be used to track completion, either, because to mark it complete would mark unrelated ideas complete, which might not be implemented.
In short, mixing many ideas in a post makes the post useless to the devs for the purposes of exploring and possibly implementing them.