Oolite Bulletins

For information and discussion about Oolite.
It is currently Tue Sep 26, 2017 5:58 pm

All times are UTC




Post new topic  Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Tue Sep 12, 2017 2:30 pm 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 490
The implementation seems to allow the delegation of the "mass-unlocking" to a script, but it doesn't seem to provide a way to force a masslock. I was looking into this precisely because I was considering having asteroids to masslock players, or ever have a planetary masslock that extends to the WP (with compensations like fuel-free injectors with downsides, but that's another topic).

I'd like to suggest to implement the feature offered by the "variable masslock OXP" directly, that is give every entity a masslock radius; perhaps with special values like 0=never masslock and -1=always masslock at scanner range. If the property is read/write it should allow other use cases (including tricks like setting the player's ship masslock radius to -1 in order to force a permanent masslock).
It seems to me that it could also simplify the code with the right defaults for special cases (beacons, planets, asteroids, ...).

BTW I'm not too familiar with Objective-C and I'm wondering why do updateAlertConditionForNearbyEntities() and loseTargetStatus() make a local copy of uni_entities[]?


Top
   
PostPosted: Wed Sep 13, 2017 2:14 pm 
Offline
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral

Joined: Wed Feb 28, 2007 7:54 am
Posts: 4947
Quote:
BTW I'm not too familiar with Objective-C and I'm wondering why do updateAlertConditionForNearbyEntities() and loseTargetStatus() make a local copy of uni_entities[]?
Looking at it, it might be that there is one local copy too many (edit after looking some more - I think it's correct as-is). However, note that the code you see here is the result of more than eight years of revisions and at least one of the two cases you mention was located in the HeadUpDisplay class in the past and was transferred over to PlayerEntity at some point. Back then, there could be indeed a very valid reason for doing it this way, which may or may not be applicable now. In fact, there is a comment in the old HeadUpDisplay code (rev. 3f091ec), just when it is about to set the uni_entities, saying: "// use a non-mutable copy so this can't be changed under us." so that must have been the reason back then and the code survived in this form until now.


Top
   
PostPosted: Thu Sep 14, 2017 12:54 pm 
Offline
---- E L I T E ----
---- E L I T E ----

Joined: Sun Jul 21, 2013 12:26 pm
Posts: 490
I guess I could try to do the optimization in my local copy and see what happens. Except I smell thread issues (*) so that the fact in works fine here and now doesn't mean it is bug-free. And the optimization may not be worth the risk. I'm know the difficulties of maintaining "legacy" code, I'm in a similar situation at $dayjob.


(*) If my guess is correct then the copy loops should be in some sort of critical section though.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 3 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron
Powered by phpBB® Forum Software © phpBB Limited