Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Lurkily

  1. 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.

    • Like 1
  2. 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.

  3. 8 minutes ago, Lurkily said:

    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.

    1

    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.

     

  4. 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.

  5. 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.

  6. 5 hours ago, Garheardt the Black said:

    I noticed a while back that combining some existing parts with a little creative design resulted in drones impervious to any projectile subject to physics. It took some work to do the first time, but after I got it , it wasn't cosmic.

     That sounds more like a problem to be solved than a design feature justifying new design features. 

  7. 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. 

  8. 6 hours ago, Garheardt the Black said:

    Were you referring to an inability to adjust a motorized hinges movement speed during a mission? 

    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. 

    • Like 1
  9. 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. 

  10. 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.

    • Like 1
×
×
  • Create New...