[Beta] Release of Telescope 2.0

[cag]

What started as frame rate optimization has turned into a full re-write! (I kept breaking things )

I ended up creating not one but two additional oxp's <sigh> (when I go off on a tangent, I can become obtuse )
There's fps_monitor, which I use to mimimize impact by scaling operations based on the PC's current frameate. (25 kB)
https://www.dropbox.com/s/msqb9tdg7fo8 ... .oxz?dl=0
Edit Nov.26/21: no longer required as now built into Telescope 2.0; link still viable

There's also Station Options. Telescope has over 40 user options to play with and I needed simple, accessible interface. With this, I can break up the options by subject into pages (ie. screens) and have over 20 single click options per page, unlimited options/page as it can scroll. It supports 7 types plus an optionless text which I used for the readme, so there's no reason a player has to open the oxz! Clicking on an option opens up its own page and those support scrolling text too. (35 kB)
https://www.dropbox.com/s/dzz9ayq1e0jh ... .oxz?dl=0
These are both required oxp's for Telescope. This is reqired for Telescope 2.0
Edit Nov.26/21: new link to latest version

Anyway, I need some guinea pigs intrepid pilots to test fly this new version. Especially important is testing with oxp's that require telescope compatibility.
I believe I have preserved compatibility w/ Rescue Stations, Stealth, Vector, Planetary Compass, Q-charger & TorusToSun (I'm not that familiar with them) but may have missed some. (257 kB)
https://www.dropbox.com/s/swfwx5klha3d ... .oxz?dl=0
Edit Nov.26/21: this link still works

The Extender was also updated. (6 kB)
https://www.dropbox.com/s/oq331u061tuc ... .oxz?dl=0
Edit Nov.26/21: new link to latest version

This new version is about 35% faster than 1.13 (14% faster than 1.15) but I gave up 8% of the gain over 1.15 to reduce the amount of garbage produced, to lessen the frequency of 'stutter's.

Garbage production was decreased by over 70% vs 1.15 (1.13 & 1.15 have similar rates) causing a stutter once every 2 min vs twice/min.

features changed:

- direction marker now have emphasis, eg. with heading of 65° ^>, you only knew which quadrant to steer into. Now you'd get 65° ^^> if it mostly up, 65° ^>> if mostly right.

- FarStatus now requires scanner detection before showing offender status; status will be retained until no longer detectable

- the gravity scanner now required for detection through planetary objects (gravity waves travel through planets like neutrinos); detection of beacons (radio waves) & planetary bodies (intergalactic space almanac) is unaffected
(I detect whether line of sight is obscured by a planet, moon or station)

new features:
- Telescope now has over 40 options and they are now all available when docked at a station (F4). There you will also find the documentation (readme, quick start, etc.), so there is no need to crack open the oxz!

- the extender now captures cargo pod data for extended detection
- pods must first be detected normally, then are tracked from 0-16 km beyond scanner range (filtering ambient noise & employing backscatter analysis and advanced AI trajectory prediction \_0_/); if contact is lost, it must be re-aquired in normal scanner (errors grow exponentially if data is not constanly updated, so it all gets purged from the telescope's db).

- filtering added for MFD (limit targets displayed based on 16 characteristics) plus an auxilary MFD, with its own filter
eg. miner/bounty hunter may set up one for rocks/criminals, one for defense,navigation
Pilots employing smart HUDs could use these to have a single MFD swap filters based on the situation.
If both MDF filters are identical, the auxilary MFD becomes a continuation of the primary.

- new option: can remove in-flight configuration options, leaving just 4 commands modes (this removes the 6 configuration modes)

- new options: masslock rings can be displayed based on alertCondition, weaponsOnline; restricted to any views

- new options: sniper ring & 3D model ring color can be set to better match your hud

- 3 new options to tailor console messages, that while useful during familiarization, can cause cluttering of console message display

[Norby]

Thank you for your enormous work! After checking through your code I realized that you created about 5 times more new lines to reach this level of updade than me in total anno in this oxp. If we would have a list of oxps ordered by js length or developing hours then I think that your project would jump into the top few. Nice job!

[cag]

Nice job!

Thanks.

version 2.0.1: added compatibility fixes for Carriers (thanks Rustem), EscortDeck & Towbar

[phkb]

I got these errors in my log file after installing Telescope 2.0.1:

Code: Select all

10:33:11.694 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "balloon" specifies non-existent model "balloon.dat".
10:33:11.910 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "griff_cobra_III_(alt)_subent_missile" specifies non-existent model "griff_normalmapped_cobraIII_missile.dat".
10:33:12.122 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "manta_wings" specifies non-existent model "dttmantawings.dat".
10:33:12.366 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_planet_express" specifies non-existent model "dtt_planet_express.dat".
10:33:12.639 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dttmanta" specifies non-existent model "dttmantabody.dat".
10:33:12.892 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "accessories" specifies non-existent model "accessories.dat".
10:33:13.167 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "griff_normalmapped_alt_cobra_mkIII_Multidecal_PLAYER_clean" specifies non-existent model "griff_normalmapped_cobra_III_(alt).dat".
10:33:13.405 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "griff_normalmapped_alt_cobra_mkIII_NPC_aft_gun_scuffed" specifies non-existent model "griff_normalmapped_cobra_III_(alt)_aftgun.dat".
10:33:13.623 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dttwraith_player" specifies non-existent model "wraith01.dat".
10:33:13.838 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_galaxy_liner" specifies non-existent model "dtt_galaxy_liner.dat".
10:33:14.055 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_heart_of_gold_player" specifies non-existent model "dtt_heart_of_gold.dat".
10:33:14.278 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_space_zeppelin" specifies non-existent model "gondola.dat".
10:33:14.496 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_space_zeppelin_player" specifies non-existent model "gondola.dat".
10:33:14.713 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_galaxy_liner_player" specifies non-existent model "dtt_galaxy_liner.dat".
10:33:14.950 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtttomahawk_player" specifies non-existent model "tomahawk.dat".
10:33:15.168 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_planet_express_player" specifies non-existent model "dtt_planet_express.dat".
10:33:15.396 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtt_heart_of_gold" specifies non-existent model "dtt_heart_of_gold.dat".
10:33:15.611 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dtttomahawk" specifies non-existent model "tomahawk.dat".
10:33:15.900 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dttmanta_player" specifies non-existent model "dttmantabody.dat".
10:33:16.220 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "griff_cobra_Mk3_alt_trader-NPC_scuffed" specifies non-existent model "griff_normalmapped_cobra_III_(alt).dat".
10:33:16.464 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "dttwraith" specifies non-existent model "wraith01.dat".
10:33:16.686 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "griff_normalmapped_alt_cobra_mkIII_Multidecal_PLAYER_scuffed" specifies non-existent model "griff_normalmapped_cobra_III_(alt).dat".
10:33:16.906 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "griff_cobra_Mk3_alt_pirate-NPC_scuffed" specifies non-existent model "griff_normalmapped_cobra_III_(alt).dat".
10:33:17.122 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "griff_cobra_Mk3_alt_trader-NPC_clean" specifies non-existent model "griff_normalmapped_cobra_III_(alt).dat".

(Although it says shipData, I actually think it's effectdata that's to blame)

[cag]

(Although it says shipData, I actually think it's effectdata that's to blame)

You're quite correct, it is the effectdata. If you look inside the oxz, there is an entire folder devoted to the subject (/effect data). The tl;dr version is that oolite cannot create visual effects from shipdata, so I have to supply the data for whatever oxp's you decide to load! This is to support the 3D model of your ship's target.

If it's just the error messages, they can be ignored or suppressed by setting

Code: Select all

shipData.load.error = no;

(near line 360) in your logcontrol.plist file, though that's not ideal for an author.

Otherwise, there are a number of sample effectdata.plist files included you can try and a Python3 script that will generate a customized version for your installed oxp's. There is also a 'effectdata.required.plist' file that has no shipdata, if you decide not to use the 3D model option. If you're on Windows, there is an executable version of that script (.exe) that you can download here:

https://www.dropbox.com/s/i2diyvg240hr5 ... a.exe?dl=0

(it's a separate DL as it almost 6 MB)

The Telescope oxz ships with the 'core, Griff & DTT ships' version installed in its Config folder and since you don't use all the Griff & DTT ship, you get errors.

[private_lock]

Hello cag,

Quite a few questions:

• What's the status of this rewrite?
• Is it already good enough for regular players to use it?
• Are there any known limitations?
• Is the transition between the regular 1.15 and your version smooth?
• What have you been up to lately?
• Have you seen the report of Milo?

If you've been playing this beta for a whole year now, maybe it's time you get it out into the ingame oxz manager ...

Thanx
private_lock

[cag]

[*]What's the status of this rewrite?

Stable, pending any evidence to the contrary

[*]Is it already good enough for regular players to use it?

I believe so, but with any Beta, you should backup your saved games, just in case. It should work fine going forward but if you decide to revert back to 1.15, I'm not so sure. I didn't test that much.

[*]Are there any known limitations?

Aside from the rash of "[shipData.load.error]" messages in the log mentioned above, I don't think so. They can be ignored, or turned off (see my prev. post) or, if you're not installing/uninstalling different ships all the time, you can use the utility I wrote to build a personalized ship data file. This only effects the graphics of the 3D model of the ship you're targeting, so if you don't use that option, it's a non-issue.

[*]Is the transition between the regular 1.15 and your version smooth?

It should be. The rewrite was mostly a proof of concept wrt performance (higher frame rate, less garbage collection pauses). I tried to stick to the original's functionality and have tested the other oxp's that interact with it. I did tweak a few things but nothing major.

[*]What have you been up to lately?

I've been up to my eyeballs in an unrelated project in Python (& tkinter ). Thankfully that's coming to an end and I look forward to getting back into space.

[*]Have you seen the report of Milo?

I read it. I experienced it too when I started flying and had to choose between the 2 oxp's; telescope won, no contest. They both have auto-steer, so were bound to clash. Besides, manual docking is fun! Do keep the ILS installed though; it speeds up traffic (the NPCs use it) and there's always the auto-dock.

If you've been playing this beta for a whole year now, maybe it's time you get it out into the ingame oxz manager ...

That would be premature for a couple of reasons. I need feedback from adventurous pilots to iron out the wrinkles (there are always wrinkles). Also, the project I mentioned monopolized my time and it wouldn't be right to publish and not be available to address any issues. That project is nearly done, so all I have to do is rewire my brain from Python to Javascript.

So, if you like using telescope, give 2.0 a try. Just remember to make backup copies of your saved games, in case you, um, mount it backwards and it melts your computer when you fly close to a sun.

[dybal]

[*]Have you seen the report of Milo?

I read it. I experienced it too when I started flying and had to choose between the 2 oxp's; telescope won, no contest. They both have auto-steer, so were bound to clash. Besides, manual docking is fun! Do keep the ILS installed though; it speeds up traffic (the NPCs use it) and there's always the auto-dock.

The problem goes beyond ILS and it's steering (I like manual docking too).

The autolocking makes getting a lock to a dockable to ask for docking clearance very hard, if not impossible, when there are other ships flying around/behind the dockable... the only option left is "speed docking" (Shift-c) for those with a docking computer, and pay the time penalty.

I have been using Telescope 2.0 for two weeks, and yesterday I noticed that I'm not seeing a sniper ring any more... should I?

[cag]

The autolocking makes getting a lock to a dockable to ask for docking clearance very hard, if not impossible, when there are other ships flying around/behind the dockable...

The autolock feature is part of telescope's 'Navigation Mode'; just toggle your weapons on ('_' key) and you leave navigation mode, which should fix the problem.

If you wish to remain in navigation mode (or it'd be unwise to enable weapons), another solution is to hit the ident key ('r') when the dockable becomes a target. That locks the target (temporarily suspends navigation mode in preparation for auto-steer on the next hit of 'r') - just don't hit that second 'r' for auto-steer, as it will release the lock once steering is completed.

I have been using Telescope 2.0 for two weeks, and yesterday I noticed that I'm not seeing a sniper ring any more... should I?

Next time you're in station, check out F4 - Telescope Options. Near the bottom of the 1st page, verify that your SniperRingSize is not zero and SniperRingColor is not all zeros (black). On the 2nd page, check the min/max range settings for the Sniper Ring. If they're equal or min > max, it shuts off. My min range is 5000, so I see the Sniper Ring every time I launch (and don't steer right away - the beacon gets targeted).

Also, the 1st item on the 2nd page, 'Keys', explains what I just wrote above in the 1st paragraph. FYI, the entire readme file is available on the 3rd page, in 5 sections.

P.S. the detection cones can be tweaked on the 1st page, see AutoLock, GravLock & IdentLock. The one for navigation mode is GravLock (not NavLock for example) for historical reasons (the option names are taken from the scripts variable names)

[Milo]

Below is a possible change to improve compatibility with SniperLock, making use of the variable provided in that OXP's script for this purpose:

In telescope.js, _initOxpVars, add (under the line for Towbar):

Code: Select all

		SniperLock = worldScripts.sniperlock;

In telescope.js, start_Steering, add (under the line for Towbar):

Code: Select all

			SniperLock.deactivate = "TRUE";                         // signal SniperLock to stop locking targets while we are steering

In telescope.js, halt_steering, add (under the line for Towbar):

Code: Select all

		SniperLock.deactivate = "FALSE";                            // signal SniperLock to resume its functionality

This isn't a perfect solution because if a third OXP also tries to toggle that switch while we are steering, we might signal SniperLock to resume before the other OXP is ready (not hypothetical: Reverse Control OXP uses the same switch already and we could be auto steering in the aft view), but that is a scenario that needs to be solved by SniperLock (for example, by redefinining its deactivate variable from a true/false value to a reference count that multiple OXPs could access in parallel [each other OXP could then increment it by 1 when they want SniperLock to pause and decrement it by 1 when they no longer need SniperLock to pause, and SniperLock would treat greater-than-zero the way it treats "TRUE" now]). Since the scripting engine in Oolite is single-threaded, we don't have to worry about collisions with two OXPs simultaneously modifying the variable.

As an alternative, instead of adding compatibility code in Telescope, SniperLock's script can be changed to introduce compatibility by checking for the frame callback that Telescope uses as a signal for other OXPs (currently Towbar) to detect auto steering.

In the SniperLock OXP, add this at line 34 of sniperlock.js (at the end of startUp):

Code: Select all

   this.wst = worldScripts["telescope"];// for detection of Telescope's auto steering

Then replace line 70 (what was line 69 before the above line was added) of sniperlock.js with this:

Code: Select all

   if( (!player.ship.target) || (player.ship.equipmentStatus("EQ_SNIPERLOCK") !== "EQUIPMENT_OK") || (player.ship.equipmentStatus("EQ_SCANNER_SHOW_MISSILE_TARGET") !== "EQUIPMENT_OK") || (this.deactivate === "TRUE") || 			(this.wst && isValidFrameCallback( this.wst.$TelescopeSteerFCB )) ) // don't lock while Telescope is auto steering

[Milo]

Telescope markers (the ship type, not the shadow type), which always stay at the edge of scanner range, have the unintended consequence of limiting Torus speed because the variable speed increase implemented in core only begins to increase Torus speed above the minimum 32x factor when the closest non-player entity is beyond 4x scanner range (PlayerEntity.m lines 3161 to 3242). Specifically, PlayerEntity.m line 3173 sets the conditions for which nearby entities limit Torus speed-up as follows:

Code: Select all

			if (scannedEntity != self && [scannedEntity canCollide])

I do not see any practical way for an OXP to make a ship-type entity cause the canCollide condition to return false. Telescope shadow markers, however, being visual effects, always return false for canCollide.

Ideally, I would modify the core line above as follows:

Code: Select all

			if (scannedEntity != self && [scannedEntity canCollide] && (![scannedEntity isShip] || ![self collisionExceptedFor:(ShipEntity *) scannedEntity])) // ignore ships that have been designated as collision exceptions (OXPs can do this)

That would let us use the already-available-to-OXPs addCollisionException method. Note that A.addCollisionException(B) automatically does the reciprocal B.addCollisionException(A) for you. I've confirmed in a local build that this solution works with the above core change implemented along with the following modification to the _manage_marker function in telescope.js, at lines 5086-5089:

Code: Select all

			if( mark_type === 'marker' ) {							// addShips(role, count, position, radius);
				marker = addShips( 'telescopemarker', 1, targ_posn, 1 )[ 0 ];
				marker.addCollisionException(player.ship); // tells core to ignore marker when calculating Torus speed based on distance to nearest entity
			} else													//replace the marker ship with visual effect shadow lollipop

Note that I also added braces because the if statement now applies to more than one line of code.

As a workaround until such a core enhancement is made, you can add several ps.torusEngaged checks to the _manage_marker method to make it always use shadow markers while Torus mode is active. I also tested the modification below and confirmed that it allows Torus speed to increase above 32x (note that if you had a far entity targeted before you engaged Torus drive, you must switch target once after engaging Torus to make the marker type change [e.g., point at the sun or a planet you don't currently have targeted and press the ident key]):

Code: Select all

	function _manage_marker( new_map, showName, caller ) {
		if( have_shutdown ) return;
		var ent, new_marker, ent_dist;
		var map = null;
		var index = new_map === null ? -1 : _Sighting_index( new_map, '_manage_marker' );
		var actual = curr_S.map || false;							// ? may have died, docked, jumped, out of range, etc., ?must remove telescopemarker
		// check we have a valid target (current or new)
		var still_alive = actual && actual.ent && actual.ent.isValid;// if he's ok, may have to just update marker position
		if( index < 0 && still_alive ) {							// no new target, fetch existing one
			map = actual;
		} else {													// get ready to switch targets
			map = index >= 0 && index < maplen ? mapping[ index ] : null;
		}
        if( !map ) return;		    								// nothing to do
        ent = map.ent;
        if( !ent || !ent.isValid ) return;    						// target died, jumped or docked, nothing to do
        var radius = ent.radius || false;
        if( map !== actual ) set_displayName( map, ent, true, radius );
		// determine if we keep current marker (reposition) or must create new one
		var marker = curr_S.marker || null;
		if( marker && !marker.isValid ) {
			marker.remove();
			curr_S.marker = marker = null;
		}
		var mark_type = curr_S.marker_type || '';
        // edge for near/far targets is .distanceTo === scannerRange, regardless of any radius (core tries for 25k)
        // core crosshair shows .distanceTo less cr of target
        // => marker should read _detect_distanceTo, ie. position.distanceTo - ent.collisionRadius
		let map_ent_dist = map.ent_dist;							// now updated every frame in reposition_effects
		ent_dist = map_ent_dist + ent.collisionRadius;			    // reverse adj from _detect_distanceTo, so it's .distanceTo
		new_marker = true;
		do {														// determine if we may need a new marker
			if( !marker ) break;
			if( ps.torusEngaged && mark_type !== '-shadow' ) break;	// switch to shadow (effect-type) marker during torus drive because ship-type marker limits torus speed
			if( ps.target === null ) break;							//  - had no target
            if( crossing_boundary( map, ent_dist, mark_type, radius,//  - ent has crossed scannerRange
                        '_manage_marker, via ' + caller ) )         //      will switch marker type
				break;
			if( mark_type === '' || marker === null ) break;		//  - launching or leaving witchspace
			new_marker = false;										// marker checks out ok, we can just move it
		} while( false );
		if( ps.torusEngaged ) mark_type = '-shadow';                // only use shadow (effect-type) marker during torus drive because ship-type marker limits torus speed
		else mark_type = ent_dist < scannerRange && !radius         // sun/planet/moon must remain far targets as core does not
                    ? '-shadow' : 'marker';                         //   allow ship to target them; esp a prob w/ small moons with
                                                                    //   collisionRadius << scannerRange
		if( ent.isWormhole ) {										// core requires user to manually target wormhole, we cannot
			if( curr_S.ent !== ent && ent.wscan_start !== undefined ) {
				_set_curr_Sighting( ent, '_manage_marker wormhole, via ' + caller  );
			}
			return;													// can't target a wormhole, only the user can
		}
		// do the actual updating of target & marker
        calc_marker_posn( map, map_ent_dist, radius );
		if( !new_marker ) {											// just move the existing telescopemarker, so marker & marker_type stay the same
			marker.position = targ_posn;
			marker.velocity = ps_velocity;							//keep target over Torus speeds in FarPlanets OXP
			if( mark_type === '-shadow' && curr_target !== ent )	// switch from one near target to another near one
				switch_PS_target( ent, map, showName, '_manage_marker, via ' + caller );
			else if( mark_type === 'marker' ) {						// have switched from a far target to a different far one, where
				if( curr_S.map !== map ) {							//   _switch_PS_target is not called for far targets (it's always the target marker)
					_set_curr_Sighting( map, '_manage_marker, via ' + caller );
                    if( showName ) {
                        init_headingView();
                        showTargetName( map );
                    }
					_showVShip( ent.dataKey );
				}
			}
// since re-using marker (& not chg'g ps.target), get no new 'ID locked' verbal msg
//  - no msg if browsing (!weaponsOnline) otherwise must hit ident key to chg far target, so do get verbal msg
		} else {													// create a new one (it gets remove()'d there)
			curr_S.marker_type = mark_type;
			if( marker ) {											// remove any existing marker/shadow
				marker.remove();
			}
			if( mark_type === 'marker' ) 							// addShips(role, count, position, radius);
				marker = addShips( 'telescopemarker', 1, targ_posn, 1 )[ 0 ];
			else													//replace the markership with visuall effect shadow lollipop
				marker = addVisualEffect( 'telescope-shadow', targ_posn );
            if( marker ) {
                marker.velocity = ps_velocity;						//keep target over Torus speeds in FarPlanets OXP
                curr_S.marker = marker;
                if( 	 mark_type === 'marker' )  switch_PS_target( marker, map, showName, '_manage_marker, via ' + caller );
                else if( mark_type === '-shadow' ) switch_PS_target( ent, map, showName, '_manage_marker, via ' + caller );
            } else {
                log('telescope', '_manage_marker, unable to create marker; shutting down telecope operations!' );
                _shutdown_Sightings();
            }
		}
	}

This workaround has the significant downside of making it impossible to target any far entities during Torus mode, although you can still see their light balls and mass lock circles and their names and distances still appear on the MFDs.

You might wonder why I didn't propose modifying the canCollide method in core. It is defined as follows in ShipEntity.m (lines 2070-2090):

Code: Select all

- (BOOL) canCollide
{
	int status = [self status];
	if (status == STATUS_COCKPIT_DISPLAY || status == STATUS_DEAD || status == STATUS_BEING_SCOOPED)
	{	
		return NO;
	}

	if (isWreckage)
	{
		// wreckage won't collide
		return NO;
	}
	
	if (isMissile && [self shotTime] < 0.25) // not yet fused
	{
		return NO;
	}
	
	return YES;
}

I considered checking for collision exceptions here, but collision exceptions are defined between two entities, and this method only operates on one entity (self). So it wasn't clear how to add a collision exception check here. We could make it check for player collision as a special case, but I haven't looked at everything else that calls canCollide to understand the impact of a change like that. The approach I proposed instead, checking for a collision exception in the exact line that controls the Torus speed, shouldn't have any unexpected side effects.

As a side note, although either of the above solutions remove markers from the equation, Torus speed will be limited by other nearby entities too. A single asteroid within 4x scanner range will keep Torus speed locked at the minimum (32x). Therefore, aim for empty space instead of staying on or near any of the populated lanes if you want your Torus speed to increase above the minimum...

Also, an unrelated question. Is the DebugMessages in the following line meant to be there still?

} else if( DebugMessages && ent.isMinable ) { // allows 'Abandoned Rock Hermit'

[cag]

Below is a possible change to improve compatibility with SniperLock, making use of
...

I've added it in and hope to have a maintenance release soon.

...
needs to be solved by SniperLock
...
As an alternative, instead of adding compatibility code in Telescope, SniperLock's script can be changed
...

I agree a reference counter in SniperLock would be a better solution but I don't believe it's being actively maintained.

[cag]

...
the unintended consequence of limiting Torus speed
...

Dybal had reported this earlier (in a PM; he's my sole beta tester) and I've not had a chance to investigate. Relative distances of scanner markers while in Torus are rather meaningless, only their direction matters. Making all markers 'shadow type' while Torus is engaged solves it nicely, so thanks for that. I'll see what can be done to allow targetting.

Also, an unrelated question. Is the DebugMessages in the following line meant to be there still?

} else if( DebugMessages && ent.isMinable ) { // allows 'Abandoned Rock Hermit'

It was at the time. I'm adding the detection of Abandoned Rock Hermits as a new capabilty of having added a dish (currently only speeds up the gravity scanner). I use ARH's a lot in testing, so what was a personal convenience has morphed into a marketing ploy!

[another_commander]

Ideally, I would modify the core line above as follows:

Code: Select all

			if (scannedEntity != self && [scannedEntity canCollide] && (![scannedEntity isShip] || ![self collisionExceptedFor:(ShipEntity *) scannedEntity])) // ignore ships that have been designated as collision exceptions (OXPs can do this)

That would let us use the already-available-to-OXPs addCollisionException method.

I think this has merit. Does anyone with experience in scripting see any reason why it should not go in the core?

[another_commander]

If there are no comments on this, I think I will be committing the proposed change in a couple of days or so. Milo, please check your PMs.