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)

#21
(2018-04-04, 09:06 PM)Gladyon Wrote: 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.

Think I got it fixed. Will have to do some testing, and see if I can snip away some of the inherited classes - but it compiles and works in-game, so it looks good. For the most part just needed to set target gramework (.NET 4.6 worked ), fix the references, take the CommonPropulsionBlock into inherit chain, and remove the redundant abstract classes.

Thanks for pointers.

-- edit --

There seems to be a problem still, but I'm a bit confused about it. I have a particular ship (that uses components from the mod), that seems to always freeze-crash the game when I load it. The ship loads normally, but when I click "resume", the game freezes - then windows informs it's stopped working. The only thing in log from loading the ship is:

Code:
(Filename: C:\buildslave\unity\build\artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Force deleted: raft

(Filename: C:\buildslave\unity\build\artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Fleet (raft)([Faction 783346167,Design 1019229032]) destroyed

(Filename: C:\buildslave\unity\build\artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

We have totally failed to find the target of the tractor beam after loading it

(Filename: C:\buildslave\unity\build\artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

The "raft destroyed" is from deleting the original "raft" that comes with designer, after that loading the ship.. the only error is about failing to find tractor beam target. I think the ship had a sub vehicle, but I can't load it so can't make sure of it. At the time the game freezes, engine power is at 0, might be that the game fails to initialize it's engine system (which is from the mod too.. but works fine on other ships I tested, including earlier version of that same ship).

-- edit 2 --

It seems to be connected to sub object. I loaded previous version of the ship, and did a retrofit in designer. It didn't crash the game immediately, rather the building proceeded for a while, and this time log had a bit more stuff before the crash. I'll attach it. I'll also attach the offending blueprint. It uses VW components heavily, so obviously won't really work without the mod - but maybe it's useful anyway.

-- edit 3 --

There's "piston on piston" construct on that ship, but removing it on 216 and then trying to load again in 217 gave same result - crash. Also removed the tractor beam from the ship in 216 and tried to reload, but game still crashes, just without the error message about tractor target. So, in the end I have no idea what's going on. No error message, just crash, so I have nothing to go on with.

-- edit 4 --

One more note: it seems that even if I disable voidware mod, and try to load that blueprint (all VW blocks replaced to wood blocks, the cost of the ship also reduces so I'm assuming it really does try to load it that way), the game still seems to crash the same way. So I suppose loading that BP even without VW installed should still crash the game. Also 217 version of FTD doesn't seem to close cleanly - if I alt-F4 out or close the window, the game hangs instead of closing. 216 didn't have this issue.


.zip   output_log.zip (Size: 20.17 KB / Downloads: 12)

.zip   Levi3.zip (Size: 83.08 KB / Downloads: 14)
Workshop: Voidware, INARI and more.
Reply

#22
(2018-04-05, 06:22 AM)Kiriko Wrote: [edits]...

One more note: it seems that even if I disable voidware mod, and try to load that blueprint (all VW blocks replaced to wood blocks, the cost of the ship also reduces so I'm assuming it really does try to load it that way), the game still seems to crash the same way. So I suppose loading that BP even without VW installed should still crash the game. Also 217 version of FTD doesn't seem to close cleanly - if I alt-F4 out or close the window, the game hangs instead of closing. 216 didn't have this issue.

Glad you can make your mod working again.

As you saw, I made a common propulsion class, as most code could be shared (I could probably share more probably...) and as I needed it for the ACB to control all propulsion in one line of code instead of 2.
It shouldn't be a real problem for you, just changing the inheritance should be OK.

The exiting problem is known, Nick is on it.

I am investigating your blueprint, I managed to load it, and I have a lot of wood blocks... When you create a huge ship, you don't do things by half!
I think I know the cause of the problem, there's a stack overflow exception. Unfortunately I do not know who caused that exception as the stack isn't complete...
But I bet that it must be you PAC, as I can see that it's real huge.
Try to cut it down and see if it solve your problem.
Reply

#23
(2018-04-05, 09:47 AM)Gladyon Wrote:
(2018-04-05, 06:22 AM)Kiriko Wrote: [edits]...

One more note: it seems that even if I disable voidware mod, and try to load that blueprint (all VW blocks replaced to wood blocks, the cost of the ship also reduces so I'm assuming it really does try to load it that way), the game still seems to crash the same way. So I suppose loading that BP even without VW installed should still crash the game. Also 217 version of FTD doesn't seem to close cleanly - if I alt-F4 out or close the window, the game hangs instead of closing. 216 didn't have this issue.

Glad you can make your mod working again.

As you saw, I made a common propulsion class, as most code could be shared (I could probably share more probably...) and as I needed it for the ACB to control all propulsion in one line of code instead of 2.
It shouldn't be a real problem for you, just changing the inheritance should be OK.

The exiting problem is known, Nick is on it.

I am investigating your blueprint, I managed to load it, and I have a lot of wood blocks... When you create a huge ship, you don't do things by half!
I think I know the cause of the problem, there's a stack overflow exception. Unfortunately I do not know who caused that exception as the stack isn't complete...
But I bet that it must be you PAC, as I can see that it's real huge.
Try to cut it down and see if it solve your problem.

I guess I should have suspected it. It works fine in 2.16, but it's built close to limit - 2.16 can handle about 1000 particle tube pieces per "arm", but I guess 2.17 has tighter limit for some reason.

Yeah, without VW most of the ship is probably wood blocks - hull is built from capital blocks, power source is antimatter drive, thrusters are quantum jets, detection gear is from VW, lasers are built mostly from VW laser generators to save block count.. I think by now there's not much in that ship that is -not- from that mod. Heh.

I'll try to do some testing to check how long PPC tubes 2.17 can run. But given that you really do need to build -long- PPC tubes to get decent damage at about 2km range, it might be useful to at least have 4m straight PPC tube pieces.
Workshop: Voidware, INARI and more.
Reply

#24
(2018-04-05, 12:35 PM)Kiriko Wrote: But given that you really do need to build -long- PPC tubes to get decent damage at about 2km range, it might be useful to at least have 4m straight PPC tube pieces.

It would be better to avoid having a recursive algorithm...


[edit] Also, I managed to make AC's plugin work again, so I think that all mods which are not using ProtecTechTools will be OK in v2.17.
Reply

#25
(2018-04-05, 12:45 PM)Gladyon Wrote:
(2018-04-05, 12:35 PM)Kiriko Wrote: But given that you really do need to build -long- PPC tubes to get decent damage at about 2km range, it might be useful to at least have 4m straight PPC tube pieces.

It would be better to avoid having a recursive algorithm...


[edit] Also, I managed to make AC's plugin work again, so I think that all mods which are not using ProtecTechTools will be OK in v2.17.

Results from quick test: maximum length has gone from under 1000 to under 500. Well a little over 500, it was handling 514, the next test would have taken to somewhere 550-ish, but that crashed the game. Recursive.. mh... I haven't looked into it, but if it recurses a function call for each piece on the tube... yeah.. that would not be.. optimal. Huh
Workshop: Voidware, INARI and more.
Reply

#26
(2018-04-05, 12:55 PM)Kiriko Wrote: Results from quick test: maximum length has gone from under 1000 to under 500. Well a little over 500, it was handling 514, the next test would have taken to somewhere 550-ish, but that crashed the game. Recursive.. mh... I haven't looked into it, but if it recurses a function call for each piece on the tube... yeah.. that would not be.. optimal. Huh

Divided by 2 isn't a good thing, we'll have to do something.
Reply

#27
(2018-04-05, 01:06 PM)Gladyon Wrote:
(2018-04-05, 12:55 PM)Kiriko Wrote: Results from quick test: maximum length has gone from under 1000 to under 500. Well a little over 500, it was handling 514, the next test would have taken to somewhere 550-ish, but that crashed the game. Recursive.. mh... I haven't looked into it, but if it recurses a function call for each piece on the tube... yeah.. that would not be.. optimal. Huh

Divided by 2 isn't a good thing, we'll have to do something.

It's not just PPC either. I managed to crash laser system (with just vanilla components) at somewhere around 3000 pieces - when it's supposed to allow 10,000. I imagine it might apply to other similar systems too then. Exhaust piping? APC? Steam engines?
Workshop: Voidware, INARI and more.
Reply

#28
(2018-04-05, 01:33 PM)Kiriko Wrote: It's not just PPC either. I managed to crash laser system (with just vanilla components) at somewhere around 3000 pieces - when it's supposed to allow 10,000. I imagine it might apply to other similar systems too then. Exhaust piping? APC? Steam engines?

All multi-blocks systems uses the same recursive algorithm.
It's a problem when the blocks are in the same 'line', so PAC are the first to be hit, and long laser setup also.

I managed to change it to an iterative algorithm for a part of the fuel exhausts algorithm (the part that is looking for the exit point, it was reaching the stack very fast).
But I failed for the main algorithm. We are trying again with a different approach.
Reply

#29
(2018-04-05, 01:45 PM)Gladyon Wrote: All multi-blocks systems uses the same recursive algorithm.
It's a problem when the blocks are in the same 'line', so PAC are the first to be hit, and long laser setup also.

I managed to change it to an iterative algorithm for a part of the fuel exhausts algorithm (the part that is looking for the exit point, it was reaching the stack very fast).
But I failed for the main algorithm. We are trying again with a different approach.

Good luck Cool

Hm.. first approach that comes to mind would be.. giving the components a function that returns the directions and types of connections it sends out, and the "feeler" maintaining a queue of those connections, going through them in iterative loop. Another function perhaps to define the connections it accepts inwards ("Do you accept connection type 2 from west?", return T/F).

So a feeler triggers on specific coordinates, finds component that returns "I send type 2 to N with step 1, and type 3 to E and W with step 2. Feeler would queue 2N1, 3E2 and 3W2, then pick the first in queue to test for component that matches type 2 from 1 position "N" from original. Well the queue would need to have actual coordinates for the test of course.. but anyway. Probably would also need to maintain internal list of blocks that have already been processed to avoid multiple passes on same block.

Feeler could probably be set to process up to N blocks per frame, to spread huge systems across multiple frames - although it would mean initializing the system could take a moment.
Workshop: Voidware, INARI and more.
Reply

#30
(2018-04-05, 01:45 PM)Gladyon Wrote: All multi-blocks systems uses the same recursive algorithm.
It's a problem when the blocks are in the same 'line', so PAC are the first to be hit, and long laser setup also.

I managed to change it to an iterative algorithm for a part of the fuel exhausts algorithm (the part that is looking for the exit point, it was reaching the stack very fast).
But I failed for the main algorithm. We are trying again with a different approach.

I have no idea what the algorithm looks like, but you could see if it's viable to use tail-end recursion instead. That way you *should* be using only one stack frame, if the compiler optimizes it properly.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)