[1.8-1.12] Ferram Aerospace Research Continued: v0.16.0.5 "Mader" 03/04/22

[kcs123]

After crashing craft in Kerbin (one of first rockets on starting career) I got a lot of error log spam:

[LOG 17:55:51.300] [F: 62003]: basicFin collided into Kerbin Zn300101011 - relative velocity: 213.5555 - momentum: 11300325159045400000000000.0
[LOG 17:55:51.300] [Explosion] Combined.
[LOG 17:55:51.300] basicFin Exploded!! - blast awesomeness: 0.1
[LOG 17:55:51.300] [basicFin]: Deactivated
[LOG 17:55:51.307] kOS: Breaking Execution Automatically Contexts: 2
[LOG 17:55:51.307] kOS: Popping context 2
[LOG 17:55:51.307] kOS: Removed Context File                 Line:Col IP   label   opcode operand
[LOG 17:55:51.307] kOS: Deleting 0 pointers and restoring 0 pointers
[LOG 17:55:51.308] kOS: New current context File                 Line:Col IP   label   opcode operand
[LOG 17:55:51.308] kOS: Popping context 1
[LOG 17:55:51.308] kOS: Removed Context File                 Line:Col IP   label   opcode operand
[LOG 17:55:51.320] 1 explosions created.
[ERR 17:55:51.329] [FAR v0.15.10.1] API Error: vessel does not have FARVesselAero aerocomponent for simulation

[ERR 17:55:51.329] [FAR v0.15.10.1] API Error: vessel does not have FARVesselAero aerocomponent for simulation

[ERR 17:55:51.330] [FAR v0.15.10.1] API Error: vessel does not have FARVesselAero aerocomponent for simulation

And last line is repeated numerous times, until I quit scen and return to space center. Probably harmless message that does not cause any additional issue except of increasing log size. KSP 1.7.1. Let me know if you need full log.

[dkavolis]

On 6/1/2019 at 5:31 PM, kcs123 said:

After crashing craft in Kerbin (one of first rockets on starting career) I got a lot of error log spam:

[LOG 17:55:51.300] [F: 62003]: basicFin collided into Kerbin Zn300101011 - relative velocity: 213.5555 - momentum: 11300325159045400000000000.0
[LOG 17:55:51.300] [Explosion] Combined.
[LOG 17:55:51.300] basicFin Exploded!! - blast awesomeness: 0.1
[LOG 17:55:51.300] [basicFin]: Deactivated
[LOG 17:55:51.307] kOS: Breaking Execution Automatically Contexts: 2
[LOG 17:55:51.307] kOS: Popping context 2
[LOG 17:55:51.307] kOS: Removed Context File                 Line:Col IP   label   opcode operand
[LOG 17:55:51.307] kOS: Deleting 0 pointers and restoring 0 pointers
[LOG 17:55:51.308] kOS: New current context File                 Line:Col IP   label   opcode operand
[LOG 17:55:51.308] kOS: Popping context 1
[LOG 17:55:51.308] kOS: Removed Context File                 Line:Col IP   label   opcode operand
[LOG 17:55:51.320] 1 explosions created.
[ERR 17:55:51.329] [FAR v0.15.10.1] API Error: vessel does not have FARVesselAero aerocomponent for simulation

[ERR 17:55:51.329] [FAR v0.15.10.1] API Error: vessel does not have FARVesselAero aerocomponent for simulation

[ERR 17:55:51.330] [FAR v0.15.10.1] API Error: vessel does not have FARVesselAero aerocomponent for simulation

And last line is repeated numerous times, until I quit scen and return to space center. Probably harmless message that does not cause any additional issue except of increasing log size. KSP 1.7.1. Let me know if you need full log.

That's just a mod trying to simulate a vessel without a FARVesselAero component, currently it's only log spam. The API method should return a status indicator so that the mod could clean itself up but changing API signature is not as straightforward as internal methods.

[kcs123]

3 minutes ago, dkavolis said:

That's just a mod trying to simulate a vessel without a FARVesselAero component, currently it's only log spam. The API method should return a status indicator so that the mod could clean itself up but changing API signature is not as straightforward as internal methods.

Thanks for clarification. It does not hapen so often, so logs should be able to hold additional spamm, I hope.

[Rocketing Racer]

On 1/9/2019 at 9:37 PM, theonegalen said:

Here you go! I wasn't able to figure out how to do the leading Edge flaps or the Krueger flaps, but this should be the other APP Wings and elevons.

https://www.dropbox.com/s/lzlkz02002bun3f/APP-FAR.cfg?dl=0

Thank You!

[Svm420]

@dkavolis

I have a request. Would you add a Q readout on the Data+Stability page of the analysis AKA pg 2. I can post the request to github if that's preferred if this could be added. Maybe static pressure too? I don't know that I need it, but just another idea. Thank you

[dkavolis]

1 hour ago, Svm420 said:

@dkavolis

I have a request. Would you add a Q readout on the Data+Stability page of the analysis AKA pg 2. I can post the request to github if that's preferred if this could be added. Maybe static pressure too? I don't know that I need it, but just another idea. Thank you

Sure, I'm rebuilding the UI at the moment but it's going to be a while. I'll be able to add a lot more stuff to the UI once it's done.

 

[entropy--]

I'm playing with Near Future Launch Vehicles, and FAR seems to get the vertices wrong for some of those parts. The screenshot below shows a 5m rocket that has a visually invisible but aerodynamically very detrimental "band" around the "N50-2 Cargo Bay" part.

Any idea how to fix this?

[navot]

I've been trying to make my mod Decoupler Shroud work with FAR, but had little success so far.

I looked at how Procedural Fairings / Parts solved this, and at the moment I am calling:

part.SendMessage("GeometryPartModuleRebuildMeshData");

but it does not seem to detect the shroud mesh (Image).
What does the GeometryPartModuleRebuildMeshData function need to generate the Voxels?
Do the GameObjects need to be laid out in some specific way? Does it need colliders, or generate from the visual mesh? Do you have to register the mesh with FAR in some way?

The code that is calling the function is in this file, if you want to take a look.

Thank you

[dkavolis]

44 minutes ago, entropy-- said:

I'm playing with Near Future Launch Vehicles, and FAR seems to get the vertices wrong for some of those parts. The screenshot below shows a 5m rocket that has a visually invisible but aerodynamically very detrimental "band" around the "N50-2 Cargo Bay" part.

Any idea how to fix this?

Try patching GeometryPartModule on those parts with

%forceUseMeshes = true
%ignoreIfNoRenderer = true

 

12 minutes ago, navot said:

I've been trying to make my mod Decoupler Shroud work with FAR, but had little success so far.

I looked at how Procedural Fairings / Parts solved this, and at the moment I am calling:

part.SendMessage("GeometryPartModuleRebuildMeshData");

but it does not seem to detect the shroud mesh (Image).
What does the GeometryPartModuleRebuildMeshData function need to generate the Voxels?
Do the GameObjects need to be laid out in some specific way? Does it need colliders, or generate from the visual mesh? Do you have to register the mesh with FAR in some way?

The code that is calling the function is in this file, if you want to take a look.

Thank you

FAR is probably trying to voxelize based on colliders (less triangles so quicker). Try patching GeometryPartModule the same way as above.

Edited June 4, 2019 by dkavolis

[entropy--]

1 hour ago, dkavolis said:

Try patching GeometryPartModule on those parts with

%forceUseMeshes = true
%ignoreIfNoRenderer = true

 

Great, will try it a bit later and report back.

[Wronk]

8 hours ago, dkavolis said:

Try patching GeometryPartModule on those parts with

%forceUseMeshes = true
%ignoreIfNoRenderer = true

 

I had the same problem with some parts from the Airplane Plus mod and this fixed it:

https://imgur.com/gallery/RvYPn8y

Here's the MM patch config if anyone wants a template to edit/add other badly behaving parts: 

https://www.dropbox.com/s/pr7wp3phxd8jeow/miscpartsAPP-FAR.cfg?dl=0

[kcs123]

APP mod might have more parts with same issue. Some are cockpits, but IIRC long time ago, I think that I found some tail part or fuselage part that was having same issue. I'm no longer sure, but could be worthwile to check other APP parts too.

[Vurucore]

On 5/31/2019 at 7:49 PM, dkavolis said:

Yeah, FAR doesn't handle animated parts well. What makes it even harder, robotic parts do not actually use animations but move mesh transforms and do not have any API hooks to detect the events (at least I have not found any yet). So just assume that robotic parts are unsupported in FAR and no ETA when they will be, if ever.

If FAR doesn't play well with the robotic parts then is there some way to make FAR just ignore the robotic parts?

I'm having the same problem he has.

[entropy--]

11 hours ago, entropy-- said:

%forceUseMeshes = true
%ignoreIfNoRenderer = true

This worked well, and solved my problem. I added it to all Near Future Launch Vehicles Cargo bays via this patch:

// Fix for making FAR work with some NearFuture parts that othewise have wacky vertices.
// TODO: Apply this fix to the other NearFuture parts in need of it (there are more).
@PART[cargo-5-*]:NEEDS[NearFuturePropulsion]:AFTER[FerramAerospaceResearch]
{
	@MODULE[GeometryPartModule]
	{
		%forceUseMeshes = true
		%ignoreIfNoRenderer = true
	}
}

 

[spectre007x]

Quote

@theonegalen where do you cfg files go to fix app with far,thank you for any advice.

 

 

[Wronk]

3 hours ago, spectre007x said:

 

MM patch .cfg files just go straight in the KerbalSpaceProgram/Gamedata folder on their own, or if you have a bunch you could make a new folder in gamedata, call it whatever you want like 'MM Patches', and put them in there.

[Jognt]

@dkavolis

Would forcing FAR to use the meshes make it work with robotics? If so, how much would the performance impact be of using these more expensive calculations?

Edit: How much is the performance impact regardless? (guessing there's a good reason it's not the default way)

Edited June 5, 2019 by Jognt

[dkavolis]

4 hours ago, Jognt said:

@dkavolis

Would forcing FAR to use the meshes make it work with robotics? If so, how much would the performance impact be of using these more expensive calculations?

Edit: How much is the performance impact regardless? (guessing there's a good reason it's not the default way)

No, the problem is FAR cannot currently detect when robotic parts start/stop moving.

[navot]

On 6/4/2019 at 9:58 AM, dkavolis said:

Try patching GeometryPartModule on those parts with

%forceUseMeshes = true
%ignoreIfNoRenderer = true

 

FAR is probably trying to voxelize based on colliders (less triangles so quicker). Try patching GeometryPartModule the same way as above.

I tried this, but it sadly hasn't fixed the issue:

@PART[*]:NEEDS[DecouplerShroud]:AFTER[FerramAerospaceResearch]:HAS[@MODULE[ModuleDecouplerShroud]]
{
    @MODULE[GeometryPartModule]
    {
        %forceUseMeshes = true
        %ignoreIfNoRenderer = true
    }
}

Are there specific things one has to look out for with procedurally generated  or concave meshes?

 

[kcs123]

15 minutes ago, navot said:

I tried this, but it sadly hasn't fixed the issue:

@PART[*]:NEEDS[DecouplerShroud]:AFTER[FerramAerospaceResearch]:HAS[@MODULE[ModuleDecouplerShroud]]
{
    @MODULE[GeometryPartModule]
    {
        %forceUseMeshes = true
        %ignoreIfNoRenderer = true
    }
}

Are there specific things one has to look out for with procedurally generated  or concave meshes?

 

Have you tried with this:

@PART[*]:NEEDS[DecouplerShroud]:AFTER[FerramAerospaceResearch]:HAS[@MODULE[ModuleDecouplerShroud]]
{
    %MODULE[GeometryPartModule]
    {
        %forceUseMeshes = true
        %ignoreIfNoRenderer = true
    }
}

Using "%" instead of "@" would insert new module if same does not exist for part. Your example would only edit existing module. In other words, if part does not already have "GeometryPartModule" included in config file, using "@" will not create new one and it would behave like you didn't wrote anything at all.

[Jognt]

25 minutes ago, navot said:

I tried this, but it sadly hasn't fixed the issue:

@PART[*]:NEEDS[DecouplerShroud]:AFTER[FerramAerospaceResearch]:HAS[@MODULE[ModuleDecouplerShroud]]
{
    @MODULE[GeometryPartModule]
    {
        %forceUseMeshes = true
        %ignoreIfNoRenderer = true
    }
}

Are there specific things one has to look out for with procedurally generated  or concave meshes?

 

I may be wrong, but are you sure the patch goes through? Reason I ask is because of the HAS block after the NEEDS/AFTER block.
To check, you can open your modulemanager.configcache file and do a search for "forceUseMeshes = true" or the module itself.

[dkavolis]

40 minutes ago, navot said:

I tried this, but it sadly hasn't fixed the issue:

@PART[*]:NEEDS[DecouplerShroud]:AFTER[FerramAerospaceResearch]:HAS[@MODULE[ModuleDecouplerShroud]]
{
    @MODULE[GeometryPartModule]
    {
        %forceUseMeshes = true
        %ignoreIfNoRenderer = true
    }
}

Are there specific things one has to look out for with procedurally generated  or concave meshes?

 

You can also try replacing the FAR DLLs in your GameData with Debug versions from github, they have additional logging enabled and will log which mesh/collider transforms were used to voxelize each part.

[kcs123]

1 hour ago, Jognt said:

I may be wrong, but are you sure the patch goes through? Reason I ask is because of the HAS block after the NEEDS/AFTER block.
To check, you can open your modulemanager.configcache file and do a search for "forceUseMeshes = true" or the module itself.

Yep, I missed that upper filter, it is wrong too.

[Drew Kerman]

2 hours ago, navot said:

I tried this, but it sadly hasn't fixed the issue:

one more tip - if you make a MM patch and nothing seems changed be sure to check the .configcache file to see if the changes were even implemented as you expected

[spectre007x]

On 6/4/2019 at 10:23 PM, Wronk said:

MM patch .cfg files just go straight in the KerbalSpaceProgram/Gamedata folder on their own, or if you have a bunch you could make a new folder in gamedata, call it whatever you want like 'MM Patches', and put them in there.

 

Thank  you.