-
Posts
1,540 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Events
Everything posted by Lurkily
-
V0.5.9 Screen shake/recoil on grenade/rocket use....
Lurkily replied to troynx01's topic in Discussion & Feedback
Not a big deal; I have a medication that works and keeps me stable. Seizure triggers vary widely; in some cases a sound or a smell can even trigger it, but often there are no clear triggers at all. It's more like a threshold, and certain conditions lower that threshold until you're in danger of seizing. The vast majority of photosensitive seizures are linked to frequency, though. This is why video games for a long time carried warnings about repetitive patterns of light; it's not the light that's wiggy, per se, but the repetition at set frequencies, linked to animation frame rates. -
I'm specifically referring to Entity's feature request, when I mention single-key transceivers.
-
V0.5.9 Screen shake/recoil on grenade/rocket use....
Lurkily replied to troynx01's topic in Discussion & Feedback
Light sensitivity is a migraine trigger, but epilepsy usually requires a filicker of a specific frequency. Source: Am epileptic, though not photosensitive. -
https://www.urbandictionary.com/define.php?term=Word
-
I think the single-key transceivers also did that - had a sending part and a receiving part. I may be mistaken.
-
1-directional logic transmitters/receivers.
Lurkily replied to ManTheMister's post in Drone Part Suggestions
I'm worried that disparate parts for separate wireless functions that are already a little confusing might be a bit much for an entry-level drone builder. I think I'd prefer transmitter-receiver parts. Set an input or an output, or both. Anything with an input set is a transmitter for that input. Anything with an output set is a receiver for that output. If you can be selective about what signals are transmitted, you don't HAVE to be selective about which direction signals are allowed to flow. And if you don't have to worry about which direction signals flow, wireless connectors don't have to split any signals, wireless or non-wireless. Connectors connect, splitters split, and there are no special cases. -
Actually . . . I think this might be a better solution. Receivers wouldn't impede anything. Splitters would be the only part to block signals, as their name implies, and wireless function would be consistent in every respect, and selectivity in the commands sent is built-in. You wouldn't need a separate part at all, just modify the connector into a transmitter/receiver pair instead.
-
I see how that would help . . . but I've got a few issues. Firstly, you still has a connector that acts to disconnect signals, and I don't think that's the way most people expect the connector to behave. Secondly, it's a very technical breakdown of wireless activity with subtle and confusing differences between the parts. Lastly, if we had single-key transmitters and receivers, I would actually argue for giving them an 'all signals' setting, and having all hubs fully mirror any non-splitter child hub so that wireless parts don't split any signals, not even wireless signals. If you can be selective with the signals you send, you don't need to be selective about which signals can cross.
-
Isn't that what a splitter already does? Parts behind a splitter do not have their signals added to the core, and instead are collected in the splitter's hub. I'm not sure how that would help the parent of a wireless part receive a signal from its children.
-
I would say provide an unranked version with as many opponents as you like; increase the initial size of the sumo ring to provide a minimum distance from the nearest drone. If you can handle the lagpocalypse, let the game give you as much mayhem as you can take.
-
. . . . . Yes. Absolutely yes. (Once logic performance being tied to CPU speed is worked out.) You might need to modify sensor criteria to NEAREST enemy drone core, though.
-
I'm not sure I see a need for reduced part counts, though ...
-
I do the same, but never seen this. Thing is, I don't always need to maneuver in test mode. I've overlooked thrusters for a solid hour going in and out of testing. Hope you figure it out, but I've never heard of it happening before, so it might have been a one-off.
-
...........huh. I could get behind that.
-
That sounds more like a problem to be solved than a design feature justifying new design features.
-
Welcome to the community, Zoura. Always nice to see a new face.
-
What new drone pieces do you want most?
Lurkily replied to ManTheMister's topic in Discussion & Feedback
Agreed with Garheardt. I'd like to see all sensors have multiple ranges available. Micah has mentioned publicly begging able to, instead of specifying the size of two ranges on a directional sensor, being able to add a range of a specified width. That would mean we'd be able to have limitless ranges and tolerances on one sensor. Granting that to every sensor would be a huge advantage in a drone's self - awareness. As mentioned above, I would also like the altimeter worked into a rangefinder, using absolute instead of proportional units of measure. -
Yes, input based adjustment; I seem to recall that being briefly available during the closed alpha. My ideal - which I expect to be too much of a UI overhaul to deliver - is to be able to add or remove actions to a hinge. Each action would rotate by x degrees, or rotate to a position of x degrees, at a speed unique to that action. The UI for adjusting parts right now seems to be one size fits all, and I think hinges are too demanding for that.
-
Connectors and splitters are already queried by their children - I suspect I'm not understanding your meaning. In short, I want non wireless signals to be able to cross a connector. I think a signal connector blocking signals is what's not intuitive, though I'm willing to listen if people disagree.
-
I don't think they need to query two hubs; the hubs just need to interact with each other differently. The splitter reads signals that are children of a connector, and a connector mirrors signals hosted by the splitter.
-
Someone must really like the phrase "Oh. Mai. Gawsh.", spelling and all.
-
Well, the connector doesn't generate a signal of its own - it doesn't even have a list of active signals of its own. As I understand, if an item queries the connector, it just gets a response from the drone brain, instead. A splitter should just be able to see all signals beyond a connector, add those to its list of active signals, and that's the end of the splitter's job. It doesn't have to exclude the connector, because there's not a real signal being generated there. (I think? I think the signals listed by the hubs are different. Maybe.) As for things beyond the connector reading parents of the connector, you're right; @Micha said it, too, but I was focused on signals going from the wireless segment to the split part, not signals from the split part going to the wireless segment. From the picture above, if the button were attached to the lower-left LED instead, it would need to light up the lower-right LED - the connector can duplicate a parent splitter's signals to accomplish that.
-
I do like the transceiver idea, though, it would make a number of things more straightforward.
-
I personally think having non wireless signals cross wireless parts is enough. By activating an if gate, you get that result; a select signal passes to the split segment, and the signal generated by the IF gate can convert it to a local signal the whole split section can see.