[WIP, Plugin, Parts] (2014-10-16) LaserDist 0.5 for KSP 0.9, Alpha

[Azimech]

Finally something I could use as a timing control for my internal combustion engine.

[Azimech]

Is there a way each laser can have an unique ID so KOS can use multiple values?

[Camacha]

I stuck nine of these to a beam and performance seems pretty decent. Scanning array time! Frames seem to drop the most when the lasers are encountering an infinite distance, with things closer up performance is really pretty great. Looks fancy too!

Is this already working within kOS and how do I query distance, for example?

Edited October 12, 2014 by Camacha

[Dunbaratu]

I stuck nine of these to a beam and performance seems pretty decent. Scanning array time! Frames seem to drop the most when the lasers are encountering an infinite distance, with things closer up performance is really pretty great. Looks fancy too!

Is this already working within kOS and how do I query distance, for example?

http://tweakers.net/ext/f/B0Af18ljEIc28Cz3PdMCZupq/full.png

Not already working with kOS, but I just was working kOS this morning, with the KSPFields update that would make it work. The current state is that I got it to *Read* the fields (is it enabled, is it visible, what is the current distance?) but the ability to set them (i.e. turn the laser off by setting its Enabled field to false) doesn't work yet.

This is all happening at the same time as some other overhauls to the core system by erendrake so getting it all merged together won't be that quick. But it is progressing.

The reason the performance is a LOT better when up close is that when close I can use Unity's raycast to solve "does this ray hit any polygons and if so which one?", which is actually implemented in hardware if the video card understands it. However, KSP only really fully loads the polygons that are within 10km or so of the ship. Any polygons farther away aren't really there for real, and I have to fall back on a numeric iteration algorithm that query's KSP's propietary altitude calculation algorithm at various sample points along the ray, finds the one that was underground, and then plays "binary search" from there to narrow down where the first point where the ray goes underground is. When you're not even aimed at a planet at all, it takes a while to exhaust all possible solutions before deciding there is no hit.

Edited October 12, 2014 by Steven Mading

[Camacha]

Not already working with kOS, but I just was working kOS this morning, with the KSPFields update that would make it work. The current state is that I got it to *Read* the fields (is it enabled, is it visible, what is the current distance?) but the ability to set them (i.e. turn the laser off by setting its Enabled field to false) doesn't work yet.

I see it already works using Action Groups, I have a little laser show going on. Great to hear things are progressing, as you can see I am eager to get my fingers on it.

[Dunbaratu]

I could get the performance more speedy if I could query KSP's API somewhere to find out what the maximum and minimm terrain height are for a planet. That would give me some bounding values to use to cut off the search to within just that narrow band. I could tell where the ray first enters this band and where it first leaves this band and narrow the search down to just that line segment. Right now it has to assume a mountain might exist somewhere that extends millions of miles into space and thus still gives a hit even though the ray is aimed nowhere near close to the planet's sea level. Being able to cut that search down would mean the difference between "Update age 20" and "Update age 3" or so.

[Azimech]

I want to use it for distances as close as 0.1m. I'm going to use it as timing control for my engine, it's like a distributor, sparking at the right moment. Only this time I use it to switch rocket engines on and off.

[Dunbaratu]

I want to use it for distances as close as 0.1m. I'm going to use it as timing control for my engine, it's like a distributor, sparking at the right moment. Only this time I use it to switch rocket engines on and off.

In principle that should work. It only rounds to the nearest 2 meters when its trying to solve numerically against the unloaded terrain that's very far away. When it actually has real polygons of nearby objects to collide with it gives much more accurate results.

The bigger problem you might run into is the course-grain timeslicing of kOS itself. It might be hard to make that engine go faster than a limited speed because kOS won't run fast enough to keep up with your queries if you want to make an engine that goes something like 1000 rpm. but keep speed down lower and in principle it should work.

[Markolise]

Just an idea and a question.

I was able to get KOs to recognize this as a sensor by adding this into the part cfg

MODULE {

name = ModuleEnviroSensor

sensorType = LASERDIST

}

Is there a way for your dll to talk to spit out the distance to the ModuleEnviroSensor module?

I've been looking it up but haven't been able to find the documentation like I used to.

[Azimech]

Here ya go, when the laser is finished it will fit nicely in this steampunk setting

http://forum.kerbalspaceprogram.com/threads/97042-WIP-Internal-Combustion-Engine-Construction-Kit-77-Industries?p=1482318#post1482318

[Dunbaratu]

Here ya go, when the laser is finished it will fit nicely in this steampunk setting

http://forum.kerbalspaceprogram.com/threads/97042-WIP-Internal-Combustion-Engine-Construction-Kit-77-Industries?p=1482318#post1482318

That thing looks awesome.

- - - Updated - - -

Just an idea and a question.

I was able to get KOs to recognize this as a sensor by adding this into the part cfg

Is there a way for your dll to talk to spit out the distance to the ModuleEnviroSensor module?

I've been looking it up but haven't been able to find the documentation like I used to.

I tried making LaserDist a subclass of KSP's built in sensor classes, but I couldn't manage to make that work.

[Dunbaratu]

Update.

v0.5 Faster Numeric approximater, laser varying animation, kOS usage doc

-------------------------------------------------------------------------

Fixed:

* CPUHOG slider had no effect. Now it does.

New:

* Sped up numeric approximation algorithm by using body.pqsController.radiusMin and body.pqsController.radisuMax to set upper and lower bounds on the possible distances at which a terrain hit can occur.

* [Added kOS usage doc](https://github.com/Dunbaratu/LaserDist/blob/master/doc/Using_in_kos.md) (Note, usage in kOS doesn't work yet. This is just the description of how it will be used when it's ready.

* Added simple laser animation effect that makes the beam picture fluctuate and flicker a bit.

I now figure it's good enough that I'd move this from the work in progress forum to the releases forum, but I'm just waiting for the kOS support before I do that so the two are ready together.

[Azimech]

Great! So in theory I could start to write a kOS script today. Now I just have to learn the language.

[Dunbaratu]

Great! So in theory I could start to write a kOS script today. Now I just have to learn the language.

sadly we hit a snag yesterday and the syntax had to be done a bit differently than in that documentation, i have to go back and change it

[EDIT: There I fixed it. You can go have a look at the URL now to see the updated doc.]

Edited October 17, 2014 by Steven Mading

[Dunbaratu]

Okay so I actually wrote a script to try using this and I ran into trouble because Unity's Physics.RayCast doesn't work right apparently if you try to call it from Update() to detect an object in motion. (Apparently the object gets moved asynchronously and the collider for it is still at the previous frame's position). The effect is that when trying to detect an object in motion, LaserDist will sometimes pass right through it. I never noticed before because all my testing was on stationary objects. I'll still have to look into this and see if I can reproduce it more reliably. It's intermittent.

[Dunbaratu]

So this is why I made this mod in the first place - things are starting to come together as shown in this teaser video:

[zilfondel]

Wow, this is amazing. Planning on using KOS in a future game, this would indeed help to make automated landings. Just hope it isnt available too early in the tech tree...

[drtedastro]

Thanks for a great part / mod.

Is there anyway possible to be able to have the laser range displayed on the screen without having to rmb on the part(s)?????

It would really be helpful, at least to me, to be able to access this via a toolbar for settings and such, and be able to select which laser units to display, if more than one, into a small simple text box or such.....

I use this all of the time now, but sometimes it is hard to hit the little part and screen gets way to cluttered having to have the rmb windows open.

again, thanks.

DrTedAstro.

[Dunbaratu]

Thanks for a great part / mod.

Is there anyway possible to be able to have the laser range displayed on the screen without having to rmb on the part(s)?????

It would really be helpful, at least to me, to be able to access this via a toolbar for settings and such, and be able to select which laser units to display, if more than one, into a small simple text box or such.....

I use this all of the time now, but sometimes it is hard to hit the little part and screen gets way to cluttered having to have the rmb windows open.

again, thanks.

DrTedAstro.

It's not a bad idea. As my original goal was just kOS integration getting it on the RMB menu was enough, but you're right, making it appear on the screen in a small window box is a good idea.

How about this interface:

RMB panel shows up, has a button on it labeled "toggle display". you click it on and a small window appears just big enough to hold the display number and that's it. You can drag and move it about to where you like on screen, and when you click "toggle display" again it goes away.

[Dunbaratu]

The current state of the raycasting to hit parts of the ship itself are not working well, due to some weird undocumented behavior of Unity's raycast function. (it keeps passing through the parts intermittently due to some picky rules about the timing of updates that I haven't fully nailed down yet). it works well for terrain, and it works on vessels that never move - but it's not working well for parts of vessels when the vessel is in motion.

[drtedastro]

It's not a bad idea. As my original goal was just kOS integration getting it on the RMB menu was enough, but you're right, making it appear on the screen in a small window box is a good idea.

How about this interface:

RMB panel shows up, has a button on it labeled "toggle display". you click it on and a small window appears just big enough to hold the display number and that's it. You can drag and move it about to where you like on screen, and when you click "toggle display" again it goes away.

That sounds great... Simple but has everything that i am looking for at this time.

I would appreciate anything like that you could do...

Later, if possible, we can work on being able to sort out the direction, bearing from craft and be able to work out some things like elevation is xxxx, yyyyy km's ahead and such....

perfect mod...

Thanks

[Dunbaratu]

Later, if possible, we can work on being able to sort out the direction, bearing from craft and be able to work out some things like elevation is xxxx, yyyyy km's ahead and such....

That actually sounds trivial for me to do. I already have the vector representing the ray of the laser, the coordinates of the start of the beam and the length of the beam to the hit point, so getting height diff is just a mater of taking the altitude above sea level of the start coord and the altitude above sea level of the end coord and taking the difference. (and once I have that, and I know the diagonal length already, then I've got 2 legs of a right triangle and I can get the horizontal difference from the simple Pythagorean formula.)

This all seems do-able without much effort, but be aware that I will likely not have the available time to work on the mod until Thursday.

If you like. you can show me a mock-up of what you'd like the display to look like for that little window. I may or may not follow it, but it will give me a basis to work from.

[drtedastro]

That actually sounds trivial for me to do. I already have the vector representing the ray of the laser, the coordinates of the start of the beam and the length of the beam to the hit point, so getting height diff is just a mater of taking the altitude above sea level of the start coord and the altitude above sea level of the end coord and taking the difference. (and once I have that, and I know the diagonal length already, then I've got 2 legs of a right triangle and I can get the horizontal difference from the simple Pythagorean formula.)

This all seems do-able without much effort, but be aware that I will likely not have the available time to work on the mod until Thursday.

If you like. you can show me a mock-up of what you'd like the display to look like for that little window. I may or may not follow it, but it will give me a basis to work from.

Sounds great... NO RUSH..... RL first and foremost....

I would suggest a very simple, easy to knock out display that can be moved on the screen...

I am looking forward to this for many applications..... I definitely can see times where multiple laser units will be on the craft and ability to get to (all) of the info will be stupendous...

Thanks,

DrTedAstro...

[Markolise]

I tried making LaserDist a subclass of KSP's built in sensor classes, but I couldn't manage to make that work.

I looked at the code for KOs, and the sensors are being pulled through a switch case, so the GRAV, Temp, etc, are all basically hard coded and un-editable unless you add it manually to KOs and recompile, which I haven't been able to do yet.

Sorry for the late reply.

[Azimech]

As I understand multiple laser sensors are being detected by kOS. What I have in mind for my project is the following:

Laser1 measures a distance < 0.2 meter - kOS activates action group 1 - Laser1 measures distance > 0.2 meter - kOS deactivates action group 1.

Can kOS run multiple of these processes at once? For example 8 lasers with 8 action groups all at different times?

For this one, I would need 7 lasers.

Edited October 26, 2014 by Azimech