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

  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
V2.17 (devtest only)

#11
(2018-04-04, 03:32 PM)Kiriko Wrote: So.. changes to ACB sound really good. I've been hoping for the AND logic in particular, and having both lower and upper limit - while that would work with AND logic, it's nice to have it in single ACB.

From modding standpoint...

What has changed?

2.17 wrecked voidware totally, "vanilla" blueprints work fine, but trying to load a ship that uses voidware will break the game to the point that even UI no longer works. I'm using only new components, so it shouldn't be direct compatibility issue with game objects, and the mod has nothing to do with ACBs.

I also don't apparently get any output log (output_log.txt is not generated at all) on 2.17. Any thoughts? This is with the VW version that was compiled to 2.16

I'm also in a bit of a bind - my PC went bleh, had to reinstall OS and the like, and I'm having troubles trying to get the project back up in reinstalled visual studio.

Currently target framework is in unity 3.5 .net full base class libraries, and referencing just assembly-csharp and unityengine from FTD directory.

-- edit --
It seems most of the classes on the mod work fine, and the problem is mainly with the thrusters - which copy the old ion thruster class, and modify stuff from there.

The version of Unity has changed to match the one used by FS. The logfile is now there:
macOS ~/Library/Logs/Unity/Player.log
Windows C:\Users\username\AppData\LocalLow\CompanyName\ProductName\output_log.txt
Linux ~/.config/unity3d/CompanyName/ProductName/Player.log

Most importantly, FtD now uses .Net 4.6 or something like that, I haven't yet looked into it.
That probably explains why all mods aren't working.
Rebuilding them should be enough, it may be necessary to change the target framework.
Reply

#12
(2018-04-04, 04:03 PM)Lman94 Wrote: you might be surprised what people can do with 'simple' tools. Just look at how simple Minecraft's redstone is, and what some people have done with it.

Well you only need AND and NOT gates to create any kind of logic system. Confused
Workshop: Voidware, INARI and more.
Reply

#13
(2018-04-04, 04:19 PM)Kiriko Wrote:
(2018-04-04, 04:03 PM)Lman94 Wrote: you might be surprised what people can do with 'simple' tools. Just look at how simple Minecraft's redstone is, and what some people have done with it.

Well you only need AND and NOT gates to create any kind of logic system. Confused

Look at that, it's very interesting:
The Wireworld computer

[Image: block.gif]
Reply

#14
(2018-04-04, 04:15 PM)Gladyon Wrote: The version of Unity has changed to match the one used by FS. The logfile is now there:
macOS ~/Library/Logs/Unity/Player.log
Windows C:\Users\username\AppData\LocalLow\CompanyName\ProductName\output_log.txt
Linux ~/.config/unity3d/CompanyName/ProductName/Player.log

Most importantly, FtD now uses .Net 4.6 or something like that, I haven't yet looked into it.
That probably explains why all mods aren't working.
Rebuilding them should be enough, it may be necessary to change the target framework.

Well that's a start. Found the output log.

Code:
MissingMethodException: Method 'StandardPropulsioModule..ctor' not found.
  at Voidware.QuantumThruster..ctor () [0x00021] in <c1d38653d2a5449192e0bbecc8fedb14>:0
  at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (System.Reflection.MonoCMethod,object,object[],System.Exception&)
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) [0x00002] in <c95265f74fdf4905bfb0d5a4b652216c>:0
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) [0x00014] in <c95265f74fdf4905bfb0d5a4b652216c>:0
  at System.RuntimeType.CreateInstanceMono (System.Boolean nonPublic) [0x000a8] in <c95265f74fdf4905bfb0d5a4b652216c>:0
  at System.RuntimeType.CreateInstanceSlow (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Threading.StackCrawlMark& stackMark) [0x00009] in <c95265f74fdf4905bfb0d5a4b652216c>:0
  at System.RuntimeType.CreateInstanceDefaultCtor (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Threading.StackCrawlMark& stackMark) [0x00027] in <c95265f74fdf4905bfb0d5a4b652216c>:0
  at System.Activator.CreateInstance (System.Type type, System.Boolean nonPublic) [0x00020] in <c95265f74fdf4905bfb0d5a4b652216c>:0
  at System.Activator.CreateInstance (System.Type type) [0x00000] in <c95265f74fdf4905bfb0d5a4b652216c>:0
  at ItemDefinition.SpawnBlock () [0x00083] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at ItemDefinition.GetClass () [0x00000] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at ItemDefinition.GetOneOffSemiConstructedClass () [0x0000d] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at BuildChecks.CheckWithBlockWhetherItCanBePlaced (ItemDefinition item, AllConstruct C) [0x00000] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at cBuild.SetMarkerStyleAndColorAndUpdateHUD () [0x0042b] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at cBuild.DoBuildModeComplex () [0x0015b] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at cBuild.DoBuildMode () [0x00064] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at cBuild.RunFixedUpdate () [0x00160] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at PlayerSetupBase.FixedRun (System.Single dt) [0x00043] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at (wrapper delegate-invoke) <Module>:invoke_void_single (single)
  at BrilliantSkies.FromTheDepths.Game.GameEvents.__FixedUpdate (System.Single t) [0x00015] in <bdb01c6067bf43a78a6f87bf95887344>:0
  at CLOCK.FixedUpdate () [0x0000b] in <bdb01c6067bf43a78a6f87bf95887344>:0

ILSpy shows on assembly csharp..

Code:
// Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

// Global type: <Module>
// Architecture: AnyCPU (64-bit preferred)
// Runtime: .NET 4.0

Changing the target framework from unity to .NET, whether it's 4.0, 4.6 or 4.6.1 results in over 100 errors, so that doesn't work by itself.

Using unity 3.5 target in visual studio -does- compile the mod just fine if I use stable branch (2.16) of FTD. Did the unity version change between 2.16 and 2.17?
Workshop: Voidware, INARI and more.
Reply

#15
(2018-04-04, 04:37 PM)Kiriko Wrote: Changing the target framework from unity to .NET, whether it's 4.0, 4.6 or 4.6.1 results in over 100 errors, so that doesn't work by itself.

I just checked in FtD, it's indicated framework 4.6.
If you need more specific information, Unity is currently trying that new framework (currently experimental, they announced it will become stable in a few months).
So you can find some official documentation about the exact version used by Unity.

Anyway, I will try to fix my mods, if I come up with a solution I'll post it.
Reply

#16
(2018-04-04, 04:48 PM)Gladyon Wrote:
(2018-04-04, 04:37 PM)Kiriko Wrote: Changing the target framework from unity to .NET, whether it's 4.0, 4.6 or 4.6.1 results in over 100 errors, so that doesn't work by itself.

I just checked in FtD, it's indicated framework 4.6.
If you need more specific information, Unity is currently trying that new framework (currently experimental, they announced it will become stable in a few months).
So you can find some official documentation about the exact version used by Unity.

Anyway, I will try to fix my mods, if I come up with a solution I'll post it.

That would help, thanks. I don't know if knowing the exact framework would help really. The only unity version that shows up for me as target in VS is 3.5, and I'm assuming if I change that to .NET target, I'll probably need to add a bunch of references to... somewhere. Eh. Currently there's just..

   
Workshop: Voidware, INARI and more.
Reply

#17
(2018-04-04, 04:53 PM)Kiriko Wrote: That would help, thanks. I don't know if knowing the exact framework would help really. The only unity version that shows up for me as target in VS is 3.5, and I'm assuming if I change that to .NET target, I'll probably need to add a bunch of references to... somewhere. Eh. Currently there's just..

It seems that Unity has decided to split their dll into a lot of them.
If you take a look, Unity.dll is now empty (only 52Ko), and there are a lot of Unity*.dll files.

'UnityEngine.CoreModule.dll' seem to be the new heart of Unity's dlls.
Reply

#18
OK, it seems that modders now have to include more than one dll from Unity, depending on what we use.
It is also necessary to go for the framework 4.6.
For ProtecTechTools I need to add these references in addition to the usual ones:
- UnityEngine.CoreModule This one seem to be the main one
- UnityEngine.IMGUIModule Needed for the GUI
- UnityEngine.PhysicsModule
- UnityEngine.Physics2DModule
- UnityEngine.AnimationModule
- UnityEngine.ParticlesystemModule

It is enough to compile, but not to work... continuing investigations...
Reply

#19
Some more information about the modding problem.

The new framework is using the local culture by default to translate numbers to string (and the opposite), which means that if you live in a country where the decimal point is not '.' (as France for example...), then you will experience some problems when loading variables with a decimal point from the '.item' files.

Also, ProtecTechTools may be broken for a bit longer than usual, as I have a problem while injecting IL code in FtD now.
I hope to be able to fix it, but for now I have no clue.


But mods which do not use ProtecTechTools IL injection and avoid loading numbers with decimal point from the '.item' files should be OK by using framework 4.6 and adding the relevant Unity dlls.
Reply

#20
(2018-04-04, 07:56 PM)Gladyon Wrote: OK, it seems that modders now have to include more than one dll from Unity, depending on what we use.
It is also necessary to go for the framework 4.6.
For ProtecTechTools I need to add these references in addition to the usual ones:
- UnityEngine.CoreModule This one seem to be the main one
- UnityEngine.IMGUIModule Needed for the GUI
- UnityEngine.PhysicsModule
- UnityEngine.Physics2DModule
- UnityEngine.AnimationModule
- UnityEngine.ParticlesystemModule

It is enough to compile, but not to work... continuing investigations...

It seems if I throw enough of those modules in, it'll get rid of most of the errors. It also seems like there's been a change in propulsion hierarchy? CommonPropulsionBlock - if I'm looking at this right, it looks like BlockWithPropulsion -> BlockWithControl was changed to BlockWithPropulsion -> CommonPropulsionBlock -> BlockWithControl. I think this may have been what made VW go splat.

I made duplicate of BlockWithPropulsion and inherited BlockWithControl, but the call for new StandardPropulsionModule passes first argument 'this', which no longer works - since it expects CommonPropulsionBlock, not BlockWithPropulsion - that's at least how I'm reading it. Think I'll just need to see how I need to change my class to inherit from CommonPropulsionBlock instead.
Workshop: Voidware, INARI and more.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)