Jump to content
Stray Fawn Community
Philo

Development WIP

Recommended Posts

Also, I just want to give props to Markus here for reacting to all the development-related stuff that goes up.  It actually helps a lot knowing that something we brought up didn't just sail by unnoticed.  As people trying to, in a limited way, participate in development, the divide between what we want and what you guys know about what we want is often pretty foggy and mysterious.

  • Like 2

Share this post


Link to post
Share on other sites
5 minutes ago, Markus said:

If I got that right (from what Micha said, haven't tested it yet): There are as many trackers as you want. You can activate or deactivate trackers. The directional sensor (or VTOL thruster) will automatically choose the closest of all active thrusters to point towards.

Maybe not the ideal behavior (as you might want to permanently point towards a specific target), but that might come at a later time (meaning, if Micha has time to simply build it without telling anyone ;) )

Not perfectly ideal, but better than we had.  Along with the tracker, I also have the core as a uniquely tracked ship part. This should be enough for me to get my ship with companion weapon-pods working.  Once it is, switching weapon systems by discarding those pods and having new ones fly to my is just a step away.

 

It isn't ready for micro-fleets, though.

  • Like 1

Share this post


Link to post
Share on other sites

Yes the sensors point towards the nearest active tracker or the drone core if none is available.

I also made the distance and proximity sensor round now, so we can rotate them better :)

  • Like 2

Share this post


Link to post
Share on other sites
7 minutes ago, Micha said:

I also made the distance and proximity sensor round now, so we can rotate them better :)

Awwww!  You guys WERE listening!  Thanks for all of this, we much appreciate it.  I noticed at 360 degrees, the proximity sensor had a maximum range of 15 - I'm assuming that's from forum suggestions to reduce range as you increase angle?  While you're monkeying with them, maybe we could have an increased maximum range when they're at a 0 degree angle? (Their current usage doesn't always have sufficient range for my liking.)

 

EDIT: I know it's not relevant to racing and the new obstacles, but I figured as long as you were digging into them, it might be trivial.

  • Like 1

Share this post


Link to post
Share on other sites

You cannot set it to 0 degree (The way I implemented them does not make sense for such small angles), for that reason you can use a distance sensor with a higher range.

I'm open to feedback about the range when we release the preview version next week. I just set it to something I found reasonable.

 

  • Like 1

Share this post


Link to post
Share on other sites

I'm just seeking a longer range than the previous 1D line could achieve.  I'll wait for the preview to comment further.  Thanks again for all the new toys.

  • Like 2

Share this post


Link to post
Share on other sites
11 hours ago, Lurkily said:

Nimbatus is great for guys with a toolshed full of half-finished projects. :) 

Haha, or coders who've never actually completely finished a project like me ;)

  • Like 3

Share this post


Link to post
Share on other sites

It's a great game for gals, too.

Also, these thruster and sensor might be enough to direct manually a small flock of identical drones with very little logic on board. Kind of like these funny simulations of basic individual behaviours making complex hive minds. Well, I suppose it is possible to do right now, too, but with a little more weight and conundrum.

  • Like 2

Share this post


Link to post
Share on other sites

Hum.  I'm thinking of Swarm drones.  The simulation to replicate swarming behavior (birds, bats, etc) is surprisingly dictated by a very simple ruleset.  

1: Move in the average direction of the swarm.

2: Try to keep close to the average center of the swarm.

3: Keep a minimum distance from any other swarm member.

3 is easy.  Four proximity sensors, 90 degree sweep, maybe more  for diagonal avoidance and to eliminate gaps.

1 and 2 are harder.  You could make the core, or a tracker, the swarm center.  But average direction . . . . I'll have to think.  You might just keep the planet core on the right, and make the average direction 'clockwise, but that would diminish the resemblance to swarming behavior.

  • Like 1

Share this post


Link to post
Share on other sites

1.) Have one "main drone" with a position tracker and slap some vtol thrusters on the other drones

2.) Maybe have a fast drone with a tracker that you control yourself to guide the swarm (unless you want it to be fully autonomous)

  • Like 1

Share this post


Link to post
Share on other sites

Nice! I built something similar a while back that used spinning clones that tracked my mouse cursor. They moved like a school of fish because of the interaction between their constantly adjusted minimum spacing and the need to all travel to the same point. The practical problem was the huge number of sensors it took to prevent them all from flying into whatever you looked at. These sensor changes will make them much more viable. 

While you're editing the proximity sensor, would it be possible to give each sensor criteria it's own detection event? Something similar to how batteries can send both an "empty" or a "full" signal event. That would allow a drone to respond to different stimulus differently with a single sensor. 

Great work guys!

  • Like 1

Share this post


Link to post
Share on other sites
10 hours ago, Micha said:

1.) Have one "main drone" with a position tracker and slap some vtol thrusters on the other drones

2.) Maybe have a fast drone with a tracker that you control yourself to guide the swarm (unless you want it to be fully autonomous)

Full autonomy would be ideal, but probably unachievable.  The VTOL thrusters only point TOWARD the sensor criteria, right?  Even if you can flip them, we need some sensors so the drones don't crowd - they have to push away from neighbors, and cut off opposing thrust so they don't sit stationary when they try to keep their distance. (Or, if the vectors are weaker, just overpower them by using normal thrusters for avoidance.

A "Master" drone is one solution to centering, and is sometimes used, but to be really swarmy, even the master uses an average center as a criteria.  

#1 is the real brutal one.  It would take a ton of logic just to get each drone to return vector data, but to average it would be ridiculous.

3 hours ago, Garheardt the Black said:

While you're editing the proximity sensor, would it be possible to give each sensor criteria it's own detection event? Something similar to how batteries can send both an "empty" or a "full" signal event. That would allow a drone to respond to different stimulus differently with a single sensor. 

I support this whole-heartedly.

  • Like 2

Share this post


Link to post
Share on other sites
6 hours ago, Garheardt the Black said:

While you're editing the proximity sensor, would it be possible to give each sensor criteria it's own detection event? Something similar to how batteries can send both an "empty" or a "full" signal event. That would allow a drone to respond to different stimulus differently with a single sensor. 

My issue with this would be intuitivity. How would one make a UI for that that isn’t confusing to new players?

Also I feel that having different detection criteria for different detectables in one part is a bit... off. I think that multiple sensors should be necessary if you wanted to do that.

  • Like 1

Share this post


Link to post
Share on other sites
9 minutes ago, ManTheMister said:

My issue with this would be intuitivity. How would one make a UI for that that isn’t confusing to new players?

Add a selection criterion, and "Enemy unit," with the settings for that criteria, appear in the part settings.  Add 'terrain,' and a 'terrain' heading appears, with outputs for that detection event.  Scrolling may be necessary but can be mitigated by permitting the user to collapse each heading to hide the outputs once they've set them to satisfaction.  Alternately, tab each criterion.

This is, however, unlike any other part UI, and would require some UI layout, design, and coding work.  UI work can get notoriously choppy, so I wouldn't expect it yet.

Micah has publicly expressed that he'd like to shift to a UI that allows you to freely add inputs and outputs, so that you could have an if gate that would trigger on two possible criteria, for instance.  And here, we have one sensor carrying multiple criteria.  With this apparent intent of making sensors and logic more powerful, I'm less inclined to oppose (As I have done in the past) the idea of one sensor being able to handle multiple criteria, with per-criteria outputs.  A week ago I might have shied from the idea, but this update seems to show an intent that isn't incompatible with logic/sensor parts that can do more than one thing.

  • Like 2

Share this post


Link to post
Share on other sites

 

I agree. I shy away from ideas that would reduce creative thinking, such as suggestions to make stable structures significantly easier to build. I've enjoyed learning quite a bit about modern engineering by teaching myself how to methodically plan drone structures from the bones on up. I like the sensor changes, because I think they'll actually increase people's creativity by giving them more tools to create with rather than easy solutions to problems that have already been solved. 

  • Like 2

Share this post


Link to post
Share on other sites
8 hours ago, Garheardt the Black said:

I like the sensor changes, because I think they'll actually increase people's creativity by giving them more tools to create with rather than easy solutions to problems that have already been solved. 

I should add that it will reduce the punishment inherent in making smart drones for autonomous, competitive challenges, to require fewer sensors.

  • Like 1

Share this post


Link to post
Share on other sites

Created some emblems for the race tracks ^^

1195406186_ScreenShot2019-01-29at14_25_50.thumb.png.31f5815c646d2643f7d56ca9f65b6a52.png

  • Like 3

Share this post


Link to post
Share on other sites

Eventually, people will want to import emblems, too. 

  • Like 2

Share this post


Link to post
Share on other sites

All flyers. No swimmers? 

Regardless, they are beautiful work. 

  • Thanks 1

Share this post


Link to post
Share on other sites

The emblems are not collectables. They are the Logos of the time trial race tracks.
@Lurkily The one on the right is a swimmer, indeed. Looks a lot like a chinese dragon but it's supposed to be a hydrus (which is often drawn just very similar to a dragon). We named the tracks after star constellations :)

  • Like 2

Share this post


Link to post
Share on other sites

Ah, so these emblems are for the tracks, not the racers.  I was thinking they might be identifying marks for the participants' crafts.

Edited by Lurkily
Edit: Which, looking back, I see Philo said explicitly, and I overlooked. Oh well.
  • Like 2

Share this post


Link to post
Share on other sites

Hey, guys.  I was thinking that now that we have preview builds, what are the chances of trying more experimental tweaks in the preview builds?  For instance, though it's unrelated to racing, trackers kind of beg for some kind of rangefinder, which the altimeter already kind of does.  It would need non-percentage settings for targets other than altitude, though, but it's the kind of low-effort experiment we might be able to give feedback on in the preview builds.

A lot of things that might also be tried out here, like consuming fuel or resources for factories, or anything else that might low-effort to test-run without the same level of exacting care you'd want for a public release.

Any thoughts or feelings on that?  It would be interesting to see and give feedback on more ideas, and those of us in the preview build are less concerned about a stable, evolving experience from upgrade to upgrade.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Interesting idea with the rangefinder/tracker combi. I looked through all targets for the directional sensor/VTOL and for all I could imagine a use-case in which a distance threshold would be useful. Imagine a new setting for those which is called "Detect Distance" which accept float values and a output key called "Within detect distance". If a directional sensor/VTOL thruster is closer to the selected target than the chosen "detect distance", the output key "within detect distance" would activate.

@Lurkily do you think this would fulfill your need?

Personally I also think Factories are overpowered in VS modes. The possibility space for exploitation is just so huge that it's very difficult to balance right. I'm not sure what the current state about this topic is. Will talk with Micha about it today/tomorrow. Also a new test build will come very soon (as soon as the camera is fixed :) )

It would be possible that we would release semi-internal preview-versions more often, but we have to check if it makes sense to us with our current way of developing. We talked about it a few weeks ago so this is something which might change in the future. We'll keep you up to date.

  • Like 1

Share this post


Link to post
Share on other sites

With regards to the rangefinder, that would do it; it would be a departure from the simplicity of most parts, though, getting into more granular criteria in a single sensor.  Is that a direction things might go?  I know I've seen Micha talk about adding multiple criteria with their own input/output to single sensors (so a directional sensor could have many ranges, for instance),  and the multiple criteria on offer for sensors also seem to be going this direction.

I feel that a lot of the quality-of-life fixes tend to wait for grand upgrades where careful testing is done, even though a lot of them seem trivial, on the surface, to implement.  I feel like the preview builds are a chance to try these out, get more widespread feedback, and they can be walked back for the public release if they don't help the way we wish they would, or if they are more complicated/bug prone than they appear.

I wouldn't suggest an approach like that for big changes; those you should commit to before beginning, and pursue hard.  Changes with widespread implications aren't the kind of thing you can walk back easily.  You might end up redoing the whole build minus that one big feature, because it ties into so many things that you can't just remove it, and then when it comes time to really drill down on it, you can't just fall back on the work you did before, because it's an old version, with problems you don't want to re-fix and without improvements that you don't want to re-develop.

As developers I'm sure you already know what I'm talking about; I'm being a bit explicit about the reasoning behind it for the sake of others who might read through the thread.

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...