Not a member yet? Why not Sign up today
Create an account  

  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
v2.15 Released [all branches]

#1
As requested, making it easier to find.
(2018-02-01, 09:44 AM)Gladyon Wrote: v2.15:
- fixed possible slowdown when loading a ship with the avatar in the chair
- torpedo propellers can now be detected by passive sonars (same mechanism than the detection of missile thrusters, but with a halved distance and only one detection per second instead of 5)
- APS tracer trail size divided by 2
- 5th wireless channel in ACB bug fixed
- AMCCs now have priority again over the LWCs
- sails can now be retracted again (it was only a visual bug)
- most SubObjects are now painted along with the block (mobile detection equipment for example)
- in the modding GUI it is now possible to indicate if a SubObject must be painted or not along with the block
- in the modding GUI, the meshes and materials replacements are now working as they should
- plugins checks stronger, and mods completely disabled when the plugin has a problem

If you were using mods, you probably noticed a new window indicating some problems with the plugins.
That window has been added in order to display all the plugins that have a problem, including an error while loading the .dll or a wrong 'plugin.json' file.
That means that a faulty plugin will not be loaded anymore, and its associated mod will not be loaded either. That will reduce the probability of a mod corrupting FtD or other mods.

Note that a new plugin requirement is now mandatory (mods without plugin do not have to change anything as they do not use the 'plugin.json' file).
In the 'plugin.json' file, you need to specify the FtD version the mod is working with.
For now, the FtD version indicated must be exactly the same as the FtD version executed, it may be changed for a less rigid check in the future.
Example of new 'plugin.json' file:
{
name: "ProtecTechTools",
version: "1.5.1",
FtD_version: "v2.15",
filename: "ProtecTechTools.dll",
depends: [],
conflicts: []
}

Notice the 'FtD_version: "v2.15",' line, which is new and must contain the exact version of FtD currently running.
Be careful of the ',' character, it must be at the end of all lines except the last one (json standard).


As a modder, I know that's not a very good news, but this has been done because most of the bug reports we receive are coming from mods, which is normal because FtD has been modified a lot recently.
We had to find a way to redirect the bug reports towards the mods when the problem is coming from them.

For now the check isn't forgiving at all, it is planned to find a way to make it more forgiving in the (near) future.

2/15/2018

Game-related:
[fixed] Painting fixed for APS mantlet, pistons and display block
[fixed] various crashes
[fixed] angular velocity now correctly calculated for munition warners on stacked SubConstructs
[modified] the simple laser is now using the standard laser algorithm (range still limited to 500m), so it is now possible to counter it with smoke, laser shield and water
[added] hologram projector ('Decoration' tab), it can project a picture at the desired location (with alpha-transparency)
[modified] the new explosion algorithm has been re-activated
[added] configurable inaccuracy for the bomb chutes (by default it's 0, but you can now increase it if you want some dispersal)
[fixed] (well, I hope...) APS barrels shouldn't self-destroy in some situations (it should even work better when the barrel is repairing itself)

Mods-related:
[modified] more plugins-related errors detected
[modified] better logs to debug plugins when there's a problem at startup
[added] non up-to-date mods generate a warning (but still work)
[modified] obsolete mods (older than non up-to-date) generate an error an be automatically disabled
[fixed] disabling a mod now works at it should: the mod will not be loaded at all (except for the modding GUI), so it isn't necessaary anymore to delete a mod, disabling it is enough
[added] modders now have access to a new shader for the blocks, it provides a way to deal with alpha-transparency for textures (as the old light block shader)
[added] optional 'AfterAllPluginsLoaded()' callback for mods (must implement from 'FTDPlugin_PostLoad' in addition to the required 'FTDPlugin' interface
Reviewed FtD on steam yet? It's the #1 thing you can do to help FtD, please take the time!
Bug tracker - view, "upvote", comment on and add all bugs here.
Request tracker - Request new features here.
Support - Private portal to service desk.


Reply

#2
Thanks for posting the patch notes.
(2017-04-20, 06:54 PM)Hikari Wrote: I made something that has an impact of a type 1a supernova. The projectile already breaks laws of physics by going way past the speed of light.

2000mm HE Dakka Enthusiast
Reply

#3
Nice work.
Mod users who does not check version would be trouble, but how have we been possible to check it?
Reply

#4
I found a sorta bug, I understand that bomb chutes were changed a bit, and I believe that one result of the changes was that bombs should now follow a better path, like falling straight down, not shot forward.

I'm developing a bomber, with x11 2m CRAM bombs. During testings, on an attack run against a beached Bulwark, 11 bombs were fired. 1 bomb did not hit the plane. My plane. Yeah... The 1 bomb that made it took out half the Bulwark's laser system, but that wasn't worth it for the entire back half of my plane. I think the bombs fired straight forward. There is 2m of space in front of the chutes, but I don't think it was enough. The bombs used their time from impact fuses to make it a few beams back in the bottom of my plane, before exploding and destroying most of the CRAM components, the engine, and the jets. It dropped from the sky, but was able to get another shot off. I think that setting some firing restrictions, meaning it must fire at least 30 degrees down would fix it, but I think that the CRAM's behavior was not meant to happen anymore. BP and pics attatched.


Attached Files Thumbnail(s)
   

.blueprint   Technitium Heavy Bomber.blueprint (Size: 172.29 KB / Downloads: 20)
(2017-04-20, 06:54 PM)Hikari Wrote: I made something that has an impact of a type 1a supernova. The projectile already breaks laws of physics by going way past the speed of light.

2000mm HE Dakka Enthusiast
Reply

#5
(2018-02-04, 05:46 AM)MizarLuke Wrote: I found a sorta bug, I understand that bomb chutes were changed a bit, and I believe that one result of the changes was that bombs should now follow a better path, like falling straight down, not shot forward.

I'm developing a bomber, with x11 2m CRAM bombs. During testings, on an attack run against a beached Bulwark, 11 bombs were fired. 1 bomb did not hit the plane. My plane. Yeah... The 1 bomb that made it took out half the Bulwark's laser system, but that wasn't worth it for the entire back half of my plane. I think the bombs fired straight forward. There is 2m of space in front of the chutes, but I don't think it was enough. The bombs used their time from impact fuses to make it a few beams back in the bottom of my plane, before exploding and destroying most of the CRAM components, the engine, and the jets. It dropped from the sky, but was able to get another shot off. I think that setting some firing restrictions, meaning it must fire at least 30 degrees down would fix it, but I think that the CRAM's behavior was not meant to happen anymore. BP and pics attatched.

The bombs are now spawned 2.5m in front of the bomb chute, and they inherit only of 1/5th of the velocity of the vehicle.
That means that the bomb chutes must face downward and there must not be blocks that may hit the bombs when they are launched (as the vehicle will move faster than the bombs).

Here is a small drawing of the belly of the plane (dev drawing...), the '-' are blocks, and the 'C' is the downward facing bomb chute.
---C---

If you do something like that:
---C--- (direction of the plane: -->)
---
In that case, the bomb may hit the blocks just under and back the bomb chute.


Here are 2 bombers with bomb chutes that never (or more exactly, nearly never) hit themselves:

.blueprint   Crystal MkII - Bomb Chutes.blueprint (Size: 87.87 KB / Downloads: 32)
.blueprint   Iron MkII - Bomb chutesa.blueprint (Size: 449.5 KB / Downloads: 33)
Reply

#6
I'll do some testing, remove the block behind the chuts, and set some restrictions, then I'll see if it still works.

I was using a failsafe set to the default value for all the bombs. It may just do very poorly tracking the vehicles's movement, or it may be an issue of it not calculating correctly, or a bug.

Beautiful drawing.
(2017-04-20, 06:54 PM)Hikari Wrote: I made something that has an impact of a type 1a supernova. The projectile already breaks laws of physics by going way past the speed of light.

2000mm HE Dakka Enthusiast
Reply

#7
So the modifications doesn't work as intended (first time shooting forward to banace forward movement, now dropping backward because the speed difference).
Wouldn't be beautiful, if we could attach additional barrels after the chute - to be able to make safe, but protected chutes? Wink
From the Depths english playlist starts here, before that it's hungarian:
https://youtu.be/Ltdx0yVI9cA?list=PLImar...ZokVtdBa73
MULTIPLAYER!

[Image: 6yFiDvF.jpg]
Reply

#8
(2018-02-05, 09:42 AM)Normal69 Wrote: So the modifications doesn't work as intended (first time shooting forward to banace forward movement, now dropping backward because the speed difference).
Wouldn't be beautiful, if we could attach additional barrels after the chute - to be able to make safe, but protected chutes? Wink

The bombs cannot drop backwards because they inherit part of the velocity of the vehicle and have an additional 40m/s of muzzle velocity.
Could you post the blueprint?
Reply

#9
Inheriting vehicle speed could also help as long as your chutes are vertical and eject bombs at high enough speed 5m/s would be enough if your evasive pattern is not vertical.
Reply

#10
(2018-02-05, 10:57 AM)Fernir Wrote: Inheriting vehicle speed could also help as long as your chutes are vertical and eject bombs at high enough speed 5m/s would be enough if your evasive pattern is not vertical.

Yeah, it's obvious that the bomb chutes must be pointing downward.
If they point forward then the bomb will have about 100% chances to hit the plane launching them.
I haven't tried backward, that may work.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)