Jump to content

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


dkavolis

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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 :)

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

qUbahZf.jpg

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 by dkavolis
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
	}
}

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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 by Jognt
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...