Flashers on missiles don't work in 1.72.2 - FIXED

Screet · Post by **Screet** » Sun May 31, 2009 9:03 pm

Capt. Slog wrote:
Eric,
Think this might be my problem with Admiral hunting. Flashers broken - broken subentity definition "*FLASHER*, this will cause the entity not to exist?

If you're talking about the many log entries about flashers using the wrong number of tokens...maybe it's the simplest workaround to remove those flashers from shipdata.plist

Screet

Frame · Post by **Frame** » Mon Jun 01, 2009 1:49 am

just to let you know... I'm on to something... i got flashers on missiles working... however it also solves the problem with flashers on subentities.

but these (the flashers) are rotated incorrectly, so it looks stupid.. And I wouldn't be surprised if there where alot of ships with flashers on their Subentities...

It was the draw distance that was the culprit... it is checked incorrectly and for a 2nd time in ParticleEntity.m

Code: Select all

- (void) drawEntity:(BOOL) immediate:(BOOL) translucent;
{
	if (UNIVERSE == nil || [UNIVERSE breakPatternHide])  return;

	//if ((particle_type == PARTICLE_FLASHER)&&(zero_distance > no_draw_distance))	return;	// TOO FAR AWAY TO SEE
	//allready checked in drawSubEntity Frame...
	

	if (translucent)

here you can see it with my fix... there is no need for this check as it is alreadt done correctly in

Code: Select all

- (void) drawSubEntity:(BOOL) immediate:(BOOL) translucent
{
	if (particle_type == PARTICLE_EXHAUST)
	{
		if (translucent)
			[self drawExhaust2];
		return;
	}

	Entity *my_owner = [self owner];

	if ([self isSubEntity] && my_owner)
	{
		// this test provides an opportunity to do simple LoD culling
		
		zero_distance = [my_owner zeroDistance];
		if (zero_distance > no_draw_distance)
			return; // TOO FAR AWAY TO DRAW
	}

also I removed the while loop. like this in ParticleEntity.m

Code: Select all

if (particle_type == PARTICLE_FLASHER && [self status] != STATUS_INACTIVE)
	{
		Vector		abspos = position;  // in control of it's own orientation
		int			view_dir = [UNIVERSE viewDirection];
		Entity		*last = nil;
		Entity		*father = my_owner;
		OOMatrix	r_mat;
		OOMatrix	temp_matrix;	
		
		//while ((father) && (father != last))
		
		//{		orientation.w = -orientation.w;        //test
		        	r_mat = [father drawRotationMatrix];
		        	abspos = vector_add(OOVectorMultiplyMatrix(abspos, r_mat), [father position]);		        	
		  //      	last = father;
		  //      	father = [father owner];
		//}

that activates the flashers on subentities... what exactly is going on inside that loop is a bit out of my understanding..

Either it rotates the flashers in such a manner that they are practically invisible... which is what I think is happening.. Now if only i knew how to flip them...

here is a picture of the incorrect rotated flashers

Here is a picture of a correct flasher trailed by an incorrect one.. attached to a missile launched by the player ship. not spawned as submunition...

Post by **another_commander** » Mon Jun 01, 2009 6:22 am

Have you tried SVN2189? Cmdr James made a change that gives flasher to the missile when fired and all submunitions released in flight seem to carry flashers correctly now, too.

Frame · Post by **Frame** » Mon Jun 01, 2009 7:45 am

hmm nope, ill give it a try... i thought i had allready done an svn up... but appearently something went wrong..

doh i recall now... it said skipped.... seems i forgot to enter cd trunk

Frame · Post by **Frame** » Mon Jun 01, 2009 7:59 am

updated to the svn 2189, it works. but the flashers did'nt flash, they where just on as he wrote... so:

I made a minor alteration i commented out the 2nd draw no distance fix...

I think when it updated it ran into that check, therefore the flasher did not flash.. they where just on, as cmr james described ??

its a really simple ajustment...

Code: Select all

- (void) drawEntity:(BOOL) immediate:(BOOL) translucent;
{
	if (UNIVERSE == nil || [UNIVERSE breakPatternHide])  return;

//if ((particle_type == PARTICLE_FLASHER)&&(zero_distance > no_draw_distance))	return;	// TOO FAR AWAY TO SEE

The last line here being the one commented out, as this is allready done in drawSubEntity

should I update that to the trunk... and if so how ?? but others might as well do it for me

Frame · Post by **Frame** » Mon Jun 01, 2009 8:25 am

while we are at it.. Shouldn't flashers not be visible from far away ???

I made a specific check in the subEntityDraw function for if it where a flasher where it decides to draw or not draw... if a flasher, do always draw.. as long as the hierarchy top dog parent is drawn...

Of course on missiles it will disappear at 3-4 clicks because these are already small in size and will themselves disappear at that range.

but the flasher on witch point buoy is seen from beyond 25 clicks...

Post by **Cmdr James** » Mon Jun 01, 2009 8:34 am

Frame wrote:
while we are at it.. Shouldn't flashers not be visible from far away ???

Yes, but I tihnk it was you who changed it?

Frame wrote:

Code: Select all

	//if ((particle_type == PARTICLE_FLASHER)&&(zero_distance > no_draw_distance))	return;	// TOO FAR AWAY TO SEE
	//allready checked in drawSubEntity Frame...

Frame · Post by **Frame** » Mon Jun 01, 2009 2:09 pm

striked because one misunderstanding led to another

okay, this is me then... not understanding how all this works.. I did'nt think it would update on its own ????

I thought I had to invoke some sort of command... to do that... that means hands off approach for me.. because really. I do know about C++, i read some on Objective C, but all to little understand it...

good thing I left in a comment though..

Frame · Post by **Frame** » Mon Jun 01, 2009 2:22 pm

Cmdr James wrote:
Frame wrote:
while we are at it.. Shouldn't flashers not be visible from far away ???
Yes, but I tihnk it was you who changed it?
Frame wrote:
Code: Select all
	//if ((particle_type == PARTICLE_FLASHER)&&(zero_distance > no_draw_distance))	return;	// TOO FAR AWAY TO SEE
	//allready checked in drawSubEntity Frame...

ahh sorry you misunderstood... I have not send that to the trunk, and will not do so until someone "in charge" says its ok .

what you quoted is purely residing on my Harddrive I thought I had somehow updated the trunk with my modifications.
.

Post by **another_commander** » Mon Jun 01, 2009 2:28 pm

Frame wrote:
ahh sorry you misunderstood... I have not send that to the trunk, and will not do so until someone "in charge" says its ok .

what you quoted is purely residing on my Harddrive I thought I had somehow updated the trunk with my modifications.

Just to make things clear on how it works, only the persons listed on the Berlios' Oolite project membership page can make changes to trunk. All others have read-only access.

Frame · Post by **Frame** » Mon Jun 01, 2009 2:44 pm

another_commander wrote:
Frame wrote:
ahh sorry you misunderstood... I have not send that to the trunk, and will not do so until someone "in charge" says its ok .

what you quoted is purely residing on my Harddrive I thought I had somehow updated the trunk with my modifications.
Just to make things clear on how it works, only the persons listed on the Berlios' Oolite project membership page can make changes to trunk. All others have read-only access.

What I thought as with a former project i once was attached too...

A C.. links unusable though.. something messed up when I clicked that link

firefox wrote:

Code: Select all

Secure Connection Failed

An error occurred during a connection to developer.berlios.de.

You have received an invalid certificate.  Please contact the server administrator or email correspondent and give them the following information:

Your certificate contains the same serial number as another certificate issued by the certificate authority.  Please get a new certificate containing a unique serial number.

(Error code: sec_error_reused_issuer_and_serial)

The page you are trying to view can not be shown because the authenticity of the

received data could not be verified.
    *  Please contact the web site owners to inform them of this problem.

Post by **Cmdr James** » Mon Jun 01, 2009 2:58 pm

Yes, there is something messed up with the berlious key used for https. You can add an exeption for it, or you can use a webbrowser like IE that doesnt care.

Cmd. Cheyd · Post by **Cmd. Cheyd** » Mon Jun 01, 2009 8:10 pm

Actually, IE does care. The problem is Berlios is using a certificate signed by their own CA. That CA isn't in the trusted root CA lists for any OS.

Capt. Slog · Post by **Capt. Slog** » Mon Jun 01, 2009 9:54 pm

Screet wrote:

If you're talking about the many log entries about flashers using the wrong number of tokens...maybe it's the simplest workaround to remove those flashers from shipdata.plist

Screet

Yup simple, sounds like me, done it already but the mission still seems broken. I can destroy the ship, hyperspace out and back, and it regenerates.

Lestradae · Post by **Lestradae** » Tue Jun 09, 2009 12:38 pm

I am happy to announce that the trunk fix seems to have worked and OSE's Photon Torpedo now really does look photonic!

Thanks guys, you're brilliant

Cheers

L