Oolite Bulletins

Posted: **Sun Jun 17, 2012 9:42 pm**

~~r5018~~ r5019: Experimental keyboard precision mode. Activated with holding down Ctrl while any of the flight arrow control keys, including yaw, is down. User adjustable by means of the .GNUstepDefaults key "flight-arrow-key-precision-factor". Precision factor default is ~~0.75~~ 0.5 and the less it is, the higher the effect.

Posted: **Sun Jun 17, 2012 10:01 pm**

another_commander wrote:
r5018: Experimental keyboard precision mode. Activated with holding down Ctrl while any of the flight arrow control keys, including yaw, is down. User adjustable by means of the .GNUstepDefaults key "flight-arrow-key-precision-factor". Precision factor default is 0.75 and the less it is, the higher the effect.

Oh, well done!

Posted: **Mon Jun 18, 2012 7:22 am**

another_commander wrote:
Experimental keyboard precision mode. Activated with holding down Ctrl while any of the flight arrow control keys, .....User adjustable by means of the .GNUstepDefaults key "flight-arrow-key-precision-factor".

I just want to confirm that this also works as intended on the mac. (The defaults are stored at a different place with the other Mac defaults).

There is just one, with damping related, bug on my mac. It is an old bug I noticed to be present for several years now:

Once in a while when entering a system, the controls are sluggish. Pitch , roll, yaw, react slow and damping is slow. Just as if I was playing at low FPS rate. But FPS could be over 50 and it still happens. And it only happens in full screen mode. When I switch back to windowed mode, the problems are over, and back to full screen it is back. And as I rarely play full screen, I see this bug rarely and I never could find a cause in the code. Have other players noticed this behaviour?

At least I hope this new key might help in those situations.

Posted: **Mon Jun 18, 2012 7:50 am**

Eric Walch wrote:
There is just one, with damping related, bug on my mac. It is an old bug I noticed to be present for several years now:

Once in a while when entering a system, the controls are sluggish. Pitch , roll, yaw, react slow and damping is slow. Just as if I was playing at low FPS rate. But FPS could be over 50 and it still happens. And it only happens in full screen mode. When I switch back to windowed mode, the problems are over, and back to full screen it is back. And as I rarely play full screen, I see this bug rarely and I never could find a cause in the code. Have other players noticed this behaviour?

I typically play in full screen mode but have never encountered it so far.

Posted: **Mon Jun 18, 2012 4:48 pm**

another_commander wrote:
r5019: Experimental keyboard precision mode. Activated with holding down Ctrl while any of the flight arrow control keys, including yaw, is down. User adjustable by means of the .GNUstepDefaults key "flight-arrow-key-precision-factor". Precision factor default is ~~0.75~~ 0.5 and the less it is, the higher the effect.

That works nicely, Admiral. If/when my 'stick finally gives-up the ghost, it'll be very handy.

Posted: **Wed Jun 27, 2012 5:23 am**

From https://bb.oolite.space/viewtopic.ph ... ls#p172767

Thargoid wrote:
Could something suitable be added to 1.77 please, for both materials and shaders? Presumably to dump out a dictionary of current settings, similar to what you'd feed back with setShaders/setMaterials if you wanted to apply them again?

r5033 adds two new shipEntity methods getMaterials() and getShaders() which return the current materialsDictionary or shadersDictionary respectively. The output can be modified and used as an parameter for setMaterials() and/or setShaders(). The output also provides a handy way to validate which shipset a ship comes from, which may be potentially useful to determine if the player has a replacement shipset installed.

An example of the usage of getShaders() and setShaders() in conjunction with a basic validation.

Code: Select all

var playerShader = player.ship.getShaders(); // get the current shader dictionary
var shaderKey = Object.keys(playerShader); // get the shader key from the dictionary.
if (shaderKey[0] && shaderKey[0] === "griff_cobra_mk3_mainhull_diffuse_spec.png") // true if the player is flying a griff cobra III from either the replacement or addition shipsets.
{
	playerShader[shaderKey].uniforms.PaintColor1 = {type:"vector", value:"0 0 0"}; // no colour
	playerShader[shaderKey].uniforms.PaintColor2 = {type:"vector", value:"0.5 -0.25 -0.5"}; // a nice deep red
	player.ship.setShaders(playerShader); // apply modified shader dictionary
}

Posted: **Mon Jul 02, 2012 5:42 pm**

A new feature in r5045: you can reposition the external view by script.

Code: Select all

player.ship.setCustomView(vector, quaternion);

The vector is the position of the camera relative to the player's ship, in the player ship's coordinate system. The quaternion is the orientation of the camera relative to the player's ship's orientation. (The same as those used in shipdata to specify external views, in other words)

Calling this function when the player doesn't have VIEW_CUSTOM selected gives an error.

This function does not overwrite the built-in custom views - it just temporarily replaces the current one. If the player presses 'v' they'll be taken to the "next" external view from shipdata as usual.

A short - and silly - example of how this works: Missile Camera. Fit it at a TL:8 station, and activate it with shift-n/n. Then, switch to external view and fire a missile (or fire the missile and switch to external view).

One of the bugs developing the missile camera exposed was that Oolite previously assumed that the camera was extremely close to the player ship such that the approximation distance_from_player ~= distance_from_camera was okay. You therefore get very odd effects in 1.76.x if you position the camera some distance from the player {1}, which I think are fixed now. Let me know if you spot anything unusual, though.

{1} More than about 1km and some noticeable oddities can occur, though if the view is pointed at the player ship you probably wouldn't notice anything major until around 5km.

Posted: **Mon Jul 02, 2012 6:42 pm**

Does this also need some form of adjustment or work-around concerning the laser linked to the custom view (ie the one that fires if you press the fire key)?

I seem to recall looking at distant custom views in the past and one thing that was odd was always ending up with a laser on the screen, even if the ship was a distance away. That of course may have separately been updated since 1.77.

Posted: **Mon Jul 02, 2012 7:43 pm**

Thargoid wrote:
Does this also need some form of adjustment or work-around concerning the laser linked to the custom view (ie the one that fires if you press the fire key)?

I seem to recall looking at distant custom views in the past and one thing that was odd was always ending up with a laser on the screen, even if the ship was a distance away. That of course may have separately been updated since 1.77.

I don't recall seeing anything odd with lasers while testing - I know Kaks put some changes in trunk a few months back to do with laser appearance, so maybe that's fixed it.

Posted: **Mon Jul 02, 2012 9:20 pm**

I was meaning that if your view is remote from your actual ship and you press fire, do you still get the laser appearing as you would if it were just a normal view?

An additional key that you can set to suppress such things may be nice (or the option to have "none" as the laser associated with a given view - I don't think that is currently possible in shipdata.plist).

Posted: **Mon Jul 02, 2012 9:36 pm**

Thargoid wrote:
I was meaning that if your view is remote from your actual ship and you press fire, do you still get the laser appearing as you would if it were just a normal view?

Yes. Whatever laser was associated with the external view before it was repositioned remains armed.

If you want to suppress this, you can temporarily remove the laser, of course.

Posted: **Tue Jul 03, 2012 5:29 pm**

Freaking fantastic cim!

Now that I've stopped bouncing off the walls with excitement I'm now absorbing the realization of this. Very cool! You Rock!

About the laser problem Thargoid is talking about here, the current sniper camera system oxp places the view to make the laser position at the center of the screen(zero parallax) to hide any potential problems. What I like about how you've implemented this, cim, is there is now no need to have custom views defined for each ship, just a script that can apply to any ship. Laser issue aside, this is going to be even better than I had hoped for.

Now to upgrade to r5045 so I can check your missile camera out and make a sniper laser for custom lasers oxp. hehe!

Posted: **Mon Jul 09, 2012 10:37 am**

another_commander wrote:
~~r5018~~ r5019: Experimental keyboard precision mode. Activated with holding down Ctrl while any of the flight arrow control keys, including yaw, is down. User adjustable by means of the .GNUstepDefaults key "flight-arrow-key-precision-factor". Precision factor default is ~~0.75~~ 0.5 and the less it is, the higher the effect.

It seems the Quick Reference Sheet in trunk needs to be updated to reflect this.

Posted: **Mon Jul 09, 2012 10:42 am**

Gimi wrote:
another_commander wrote:
~~r5018~~ r5019: Experimental keyboard precision mode. Activated with holding down Ctrl while any of the flight arrow control keys, including yaw, is down. User adjustable by means of the .GNUstepDefaults key "flight-arrow-key-precision-factor". Precision factor default is ~~0.75~~ 0.5 and the less it is, the higher the effect.
It seems the Quick Reference Sheet in trunk needs to be updated to reflect this.

Absolutely. Not only this, but probably other little things, too. A revision of the RS before the next release is definitely in order. It's just that nobody seems to have the time right now to work on this.

Posted: **Mon Jul 09, 2012 4:41 pm**

Thargoid wrote:
I was meaning that if your view is remote from your actual ship and you press fire, do you still get the laser appearing as you would if it were just a normal view?

An additional key that you can set to suppress such things may be nice (or the option to have "none" as the laser associated with a given view - I don't think that is currently possible in shipdata.plist).

@cim: Well, I've had a chance to do a little experimenting with this new ability to set the custom view and it's great! But, I would like 3 things to go with this. First, I would like an optional parameter attached to "player.ship.setCustomView(vector, quaternion)" to set the weapon associated with the view and defaulting to the last weapon defined like it is now. Second, something similar to what was done for the crosshairs like "player.ship.setCustomView = null" to restore the last player ship custom view that would normally be there, the last one seen from the player ship shipdata. It would seem that after having a little time to try some things and have a think on it, adding these optional parameters would eliminate the need for a workaround that I have thought of and allow 100% compatibility to be possible between most oxps from different authors.
Also, would like weapon positions to be readable from JS. This would be the cherry on the cake and would allow to automatically line up the weapon correctly with the scripted custom view and allow oxp weapons like the railgun to be positioned automatically at any weapon position. All of this together would eliminate the need to add script info or modify the player ship built-in custom views with a shipdata-override file.
Just so you have an idea of what I'm going to have to do without these extra scripting options, my current thought is to use a shipdata-override file in the custom lasers oxp to change the core player ship custom views to 4 different ones representing gun camera/zero parallax views each with one of the 4 weapon facings defined. I've devised a little script test that will work automatically to determine which of these 4 views has been selected by querying the player to press and hold the fire button and testing the result as the script switches the thargoid laser in and out of each position and checking if the laser temperature rises. At that point I can launch any scripting for the sniper camera knowing that the correct weapon is active and have cameras for all 4 directions. The exact camera position relative to the weapon position will be taken from script info also from the shipdata-overide file. As you can see here, I will be able to do it, but it is a complex workaround and I will still have the need to alter the specific player ships' custom views and add script info with a shipdata-overrides file and that means, again, it still won't work automatically with all ships which is what I would like to see. As it is, because I'm planning to have turrets as buyable equipment and possibly at the weapon position and one cannot add subentities by script, I will still need to use a shipdata-override file to enable this on specific ships. So, if it is not doable or possible to add these scripting features, no worries as I will need a shipdata-override file for some ships anyway for the turrets. After all, the custom lasers oxp is a workaround in itself to make lasers with scriptable properties so having to do more of a workaround is not a big issue for me. But, if these scripting features are added, probably most(but not all) of this kind of work by myself or others could remain compatible with each other, which is what I would like to see.

Thanks so much cim and the rest of the dev team for all the great features added so far. And thanks in advance for considering my additional request.

You and the rest of the dev team truly rock!

Oolite Bulletins

Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress

Re: Progress