[1.4.3 <= KSP <= 1.12.5] KSP Recall - 0.4.1.0- 2024-0407

[zer0Kerbal]

@eightiesboi @Lisias +1

thank you for the heads up - will be diving into SYD/OHS soon -- and will be ripping out some unnecessary things.

[Krazy1]

13 hours ago, Lisias said:

send me this craft so I can take a look on it

Here's what it looks like after I alt-click copied the rear (left) hard points with wheels to the front (right). They're in mirror symmetry.

 

> craft file <

UPDATE: I did a little testing on the alt-click copy problem seems to involve node-less parts with children. The small hardpoint and GP-156 grip pad with children attached failed but then oddly the structural pylon did work OK... then I tried the small hardpoint again and it worked! What the... I'm doubting everything now. If you can't reproduce the problem, I'll try with a clean install. I do have about 50 mods.  Thanks for working these bizarre problems. Cheers

UPDATE 2: So if I build the the rover in the pic above vertically, without rotating the root FL-T800 part then it works normally. But if I rotate that tank, it doesn't work. And the structural pylon also has this problem. I changed the root part 1/2 through update 1... that's why it started working.

Edited February 21, 2022 by Krazy1
Update 2

[Lisias]

ANNOUNCE

KSP Recall 0.2.2.2 is on the Wild, featuring:

• Reworks:
  • #35 AttachedOnEditor is not working for SubAssemblies.

Handles some missing use cases that I let pass trough last release:

• Unleash the AttachedOnEditor's fury  into every surface attachment (only radial were being handled before)
• Also recovers the attachment's rotation
  • I'm not sure if it's needed, as I didn't managed to reproduce the problem - but I had reports that suggests this can fix their problem.

— — — — — 

---

This Release will be published using the following Schedule:

• GitHub, reaching manual installers and users of KSP-AVC first. Right now.
• CurseForge. Will not be updated.
• SpaceDock (and CKAN users). Will not be updated

The rationale is that I'm not convinced I really need to handle one specific use case, and want to check the solution first with the early adopters before releasing it into the wild.

0.2.2.3 was released, deprecating this one.

Edited March 8, 2022 by Lisias
0.2.2.3 was released, deprecating this one.

[Frostiken]

Can I ask why you didn't just roll back Recall to BEFORE the VAB totally broke? What exactly was whatever catastrophically broke in Recall here?

Edited March 6, 2022 by Frostiken

[Lisias]

On 3/6/2022 at 2:58 AM, Frostiken said:

Can I ask why you didn't just roll back Recall to BEFORE the VAB totally broke? What exactly was whatever catastrophically broke in Recall here?

Because otherwise add'ons that relies on the correct PartModule's life cycle to work will not work.

I think you are completely equivocated about the source of the problem. Editor Scene (VAB/SPH) is broken, not Recall. The problems Recall was getting was due trying to correctly FIX the Editor problem at hands, what took some time as more than one time I misdiagnosed the problem - it took time to finally understand where the major screw up was made on Editor's code.

Since you appear to be not familiarised with the problem, let me help you on the matter:

On KSP 1.9 development [EDIT: nope!!! See the notes on the foot of this post!] cycle something got royally screwed up on Editor. The parts' Position and (allegedly , as I have reports but didn't reproduced the problem myself) Rotation are not being initialised when loaded on Editor if the root part of a craft (or subassembly) is not a variant one, and it is followed by another part without variant.

When the root part has variants, nothing bad happens. When the root part does not have variants, but the part immediately after has, the problem does not manifest. But I'm guessing that whoever was in charge of fixing the problem never realised the root problem, because the solution Squad choose to implement was to simply OVERWRITE all the respective data using prefab as reference - completely screwing up everything and everybody that would be doing things right while changing these positions on a custom PartModule.

This overwrite happens after loading/duplicating the craft [outside the normal PartModule's Life Cycle], so there's no clean way to overcome the problem, and the net result is this stunt obliterating any Position (and maybe Rotation) related data processed by every OnLoad handler of every custom PartModule.

So, and this is another trick that cost me a lot of time to cook, the fix should not only inject back good and valid values while loading the craft (and so, PartModules' OnLoad handlers would have access to good, valid values), but also needs to inject back again these values on the first Update cycle - to overwrite back good values that were overwritten by the stunt after the craft was loaded.

The whole (painful) process for developing a proper solution, now implemented on KSP-Recall, can be found on the following issues:

• https://github.com/net-lisias-ksp/KSP-Recall/issues/32
• https://github.com/net-lisias-ksp/KSP-Recall/issues/34
• https://github.com/net-lisias-ksp/KSP-Recall/issues/35

Fell free to ask any questions about the problem, if the information above is not enough.

— — NOTES  2022-0926 — — 

It was (finally) realised on the current last release of KSP-Recall that the problem started to happen on KSP 1.4.3 (most probably on 1.4.2, but this one was so short-lived that for practical effects, 1.4.3 is the one) with the first implementation of the ModulePartVariants. It took me some time to respond on TweakScale, where I ended up forcing my hand on everybody else solving things my way. On KSP 1.9.0, another side effect of the same problem was detected on the new implementation of ModulePartVariants, and I wrongly understood it as a new problem.

Only recently I finally correctly diagnosed the root cause of the problem - and only even more recently I correctly understood the whole problem: ModulePartVariants is flawed since forever.

 

Edited September 26, 2022 by Lisias
NOTES  2022-0926

[Frostiken]

Well, I still can't get functional behavior here.

I use CraftManager, and my building strategy is to make everything very modular. Lifting templates in the VAB saves, payloads in the Subassemblies saves.

EVERYTHING was made with KSP-Recall, which you said you were able to fix if the subassembly had been made with old versions. I attached the craft files and you can see that they have AttachedOnEditor modules.

But loading the satellite from the in-game subassembly menu doesn't work. Loading the lifter from the CraftManager "load as subassembly" doesn't work.

The root part of the lifter will be the US2 decoupler which is attached to the AE-FF1 payload fairing base. The root part of the satellite is a Spark engine attached to a Restock Octo bus.

Craft file for satellite: https://drive.google.com/file/d/1qrUVE-qkuRL_qrfQlKWib_UWLLio8tc-/view?usp=sharing

Craft file for lifter: https://drive.google.com/file/d/1gPz2g1NwFDIlLAaWoTMmRCytVGiPKZ2F/view?usp=sharing

 

I don't get it. Did I miss something about what I need to do here? 

MORE:

I just made a brand new subassembly, right there. Saved it as a subassembly, and then immediately tried to load it. It's right over there on the left, 'unnamed'. And it's all still broken.

I replaced the US2 decoupler with a stock decoupler and it loads the subassembly. Reverted back to US2 and it's broken.

There is no AttachedOnEditor module for the US2 part in the .craft file.

Checking my satellite, I have 23 parts, but only 16 occurrences of 'AttachedOnEditor', and there's no US2 part, but there are Restock parts. Recall has NEVER and IS NOT applying AttachedOnEditor to modded parts.

So, what, is every single craft that uses modded parts irreparably broken and unusable now for subassembly loading?

Quote

When the root part has variants, nothing bad happens. When the root part does not have variants, but the part immediately after has, the problem does not manifest. But I'm guessing that whoever was in charge of fixing the problem never realised the root problem, because the solution Squad choose to implement was to simply OVERWRITE all the respective data using prefab as reference - completely screwing up everything and everybody that would be doing things right while changing these positions on a custom PartModule.

I wanted to say this in that last post, but I changed my post to try to fully understand the situation.

With all due respect, and I mean that sincerely: who, exactly would "everybody" in this situation be? I have never, ever heard of this problem. I have never, ever seen of any issues that were related to it. I've never seen anybody ever talk about it. I believe you discovered an actual problem that used a hacky fix, but I also believe that what you are doing to try to fix it is at this point causing vastly more damage than whatever 'problems' could have arisen from Squad's fix.

It's as if we have a table with a little wobble in it, and you didn't like that we just shoved a napkin under the leg to even it out, so you disassembled the table and are chopping at it in your workshop and at now the table wobble is gone, but the table is a foot shorter, half its size, and sometimes tips over completely, and you're saying that we just need to buy brand new chairs to accommodate the shorter table. I still don't understand how a crappy Squad-level fix is somehow worse than the fact that Recall effectively says that any old saved ships are effectively trashed.

Whatever problem was behind the scenes never manifested as an issue for me in my entire 12 years of playing KSP, until you tried to fix it, and now things have come to the point where calling the current version of KSP Recall (and by extension: Tweakscale) "A mod that will completely break your game" is fair criticism.

We've spoken a lot before and I respect the work you do and the service you provide considerably, but this is tough-love. You're very clever and skilled but we're going on several months of hacking together a series of broken fixes to repair a devastating problem that was entirely induced by an attempt to fix a problem that as near I can tell, you're the first and only one to have ever noticed or cared about fixing. Is this just the Sunk Cost Fallacy? Because I would at this point just say to roll everything back, and never touch it again. Pretend you never saw it. Leave this underlying hacky fix where it's been for the last two years.

There is a certain degree of trust that the players need to have in modders, that they will A) Keep players informed, and B) Not break their games, and I feel like that trust was violated here.

I feel uninformed because you've basically turned us into QA testers for four versions of your mod that are so clearly broken, you should have caught it yourself, so how on earth did we get to version 0.2.2.2 and it still isn't fixed? If you said "here's a working version on Git, let me know if you have issues", I am informed. When you push a stable release to CKAN, at least three times, to fix a bug that does not appear to have ever been fixed in any version, what is this besides completely untested, unfinished versions being willfully pushed to the public for us to figure out all the problems for you? And second, the game is broken. Yes, most of it works, nothing appears to be permanent, but when a major core feature of the base game is genuinely unusable for four versions, that's bad. That's really bad. If Modders had a Hippocratic Oath, that'd be one of the things you never do. Break your own mod, fine. Break the base game, no.

I've rolled back Recall to 0.2.0.6, before this mess was unleashed, and I will be unlikely to ever update Recall again. If after four version releases we're still dealing with clearly broken features that appear to be totally untested, when will a version of Recall be released that causes permanent damage in some fashion? I have no reason to believe that that couldn't easily happen in the future. I'm sorry.

Edited March 7, 2022 by Frostiken

[Lisias]

Before providing support for your problem, I need you to understand some things first (on spoiler, to avoid cluttering the support ticket with… "fun".   ) :

Spoiler

 

• I'm not Squad's (or yours) employee, I'm doing this in the Open Source spirit using my (scarce sometimes) free time.
  • I do my best, but there're no implied or explicit guarantees
    • And yeah, I bork now and then - hey, it happens, ok?
  • Hell, KSP is a paid product, but yet my add'ons are usually stabler than it!
    • Once I manage to hit that sweet spot, at least...
• It's plain impossible to foresee the consequences of a code like KSP-Recall in every possible interaction with 3rd parties, the combinations are nearly infinite!
  • So I do my best supporting Stock, and handle exceptions on 3rd parties as they happens
  • As everybody else, I must say. Anyone telling you otherwise is… well… deviating from reality.
• You are not the only one suffering from these pesky KSP (and, sometimes, 3rd party add'ons) problems.
  • I am too, and this is the reason I created KSP-Recall at first place
    • At that time, I thought doing something to help would be more constructive than just complaining about.  
• What leads to another very important fact:
  • You guys are, indeed, "my" Q/A Team.
  • I just can't foresee or test every single possible combination of Add'Ons in the face of Kerbin!
    • I need you guys to help me on helping you!!
  • Anyone not willing to be part of such Q/A efforts are free to hire me for handling your specific problem, usual U.S. Software Engineering fees apply.

That said...

On 3/6/2022 at 5:39 PM, Frostiken said:

There is no AttachedOnEditor module for the US2 part in the .craft file.

So it's not my fault. I can't be responsible for a fix that doesn't works because it is not being used!!! 

(and thanks for doing part of the diagnosing for me! You saved me a lot of time!)

Now we need to know why US2 parts are not being patched with AttachedOnEditor. The patching process is pretty straightforward:

@PART[*]:NEEDS[KSPRECALL-ATTACHED-ON-EDITOR]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA],@MODULE[TweakScale]]:FINAL
{
	%MODULE[AttachedOnEditor]
	{
		active = True
	}
}

For every part that have TweakScale, but don't have ModuleAsteroid, ModuleComet neither KerbalEVA, apply the patch!

Why I did it? Because until now I didn't had a report of this problem happening with any other add'on other than TweakScale, so I choose to be conservative and to only shoot the ducks I can see.

So, dear grumpy Kerbonaut, what you are telling me is that (as I always suspected), TweakScale is not the only one being screwed by Squad's Editor stunt. Thanks for your report, I really appreciate it (besides being a bit uncomfortable about how you did it…)

macmini62:Downloads lisias$ cat LIFTER_\ RMX\ Mk_IIB.craft | grep "TweakScale" | wc -l
      23
macmini62:Downloads lisias$ cat LIFTER_\ RMX\ Mk_IIB.craft | grep "AttachedOnEditor" | wc -l
      23
macmini62:Downloads lisias$ cat LIFTER_\ RMX\ Mk_IIB.craft | grep "PART" | wc -l
      60

You see? AttachedOnEditor was only applied on parts that have TweakScale module (I eyeballed the file too, just to be sure). But you are using a lot of parts that doesn't have TweakScale installed, so the AttachedOnEditor wasn't neither.

In order to see if I'm really right, please edit the patch to:

@PART[*]:NEEDS[KSPRECALL-ATTACHED-ON-EDITOR]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:FINAL
{
	%MODULE[AttachedOnEditor]
	{
		active = True
	}
}

And see if the problem goes away. Please note that I removed the need to have TweakScale applied, the thing will now be applied (almost) everywhere.

 

On 3/6/2022 at 5:39 PM, Frostiken said:

Whatever problem was behind the scenes never manifested as an issue for me in my entire 12 years of playing KSP, until you tried to fix it, and now things have come to the point where calling the current version of KSP Recall (and by extension: Tweakscale) "A mod that will completely break your game" is fair criticism.

Nope, it's not. It's an incredibly unfair and… humm… "deviated from reality"  statement.

A more accurate one would be "KSP is a game that completely breaks your gaming regularly and repeatedly". TweakScale was working perfectly fine on KSP 1.8.1, and suddenly Editor started to screw it up on 1.9.0 .

And I'm not even talking about the remaining inumerous serious problems that are plaguing KSP nowadays, some of them since 1.2!!!

It's simple like that.

 

On 3/6/2022 at 5:39 PM, Frostiken said:

With all due respect, and I mean that sincerely: who, exactly would "everybody" in this situation be? I have never, ever heard of this problem. I have never, ever seen of any issues that were related to it.

You never heard of the problem because nobody else had diagnosed it. As the problem with the AutoStruts, by the way, screwing up savegames since KSP 1.2 and nobody knew about until I diagnosed it.  

The real problem is that (some) developers just blindly patch symptoms instead of working harder to find the root problem and fix it before the side effects blows up on the user's face at first place.

Burying your head in the sand is not the proper way of handling problems.

 

On 3/6/2022 at 5:39 PM, Frostiken said:

I still don't understand how a crappy Squad-level fix is somehow worse than the fact that Recall effectively says that any old saved ships are effectively trashed.

There're a lot more things that you just don't understand. Let me try to remove one of them from your significantly extense list:

I didn't managed to inject the proper values from the PartModule on an preexisting Craft/SubAssembly file because the correct values since KSP 1.9.0 are available only after the OnLoad cycle of the PartModule, and so it's beyound the PartModule's ability to fetch it at this time.

Only on OnStart the First Update these values are available (because the Editor bluntly overwrite some values between OnLoad and OnStart First Update in a - desperate IMHO - attempt to fix the problem happening on OnLoad), but by then, everybody that was in need of such values (as TweakScale and, as it appears, some others) is already royally screwed.

A proper upgrade process is beyound the capabilities of a PartModule.

So another approach is needed, and I think that the proper one will be a custom KSP Upgrade Pipeline process. But this is something that I didn't learnt how to do yet.

Feel free to help me on the subject.

 

On 3/6/2022 at 5:39 PM, Frostiken said:

I've rolled back Recall to 0.2.0.6, before this mess was unleashed, and I will be unlikely to ever update Recall again. 

Your loss. There're more fixes for long standing serious bugs on the way.

Unfortunately, I don't expect to nail it on a single shot as you appears to demand from me. But this is (fortunately for me) your problem, not mine.

 

On 3/6/2022 at 5:39 PM, Frostiken said:

I'm sorry.

I'm not. I'm less than pleased with your decision, you can bet your SAS on it - but I'm not sorry.

I'm doing the very best I can, and I'm pretty sure I did a lot more than expected from me: I'm one of the really few ones diagnosing problems plaguing KSP and even Unity for years already.

I have nothing to be sorry about.

 

Let me know if by changing the patch as I stated above the problem is fixed for you.

May the road rise with you.
 

Spoiler

 

— — POST EDIT — — 

Explaining tech details early morning in a hurry and when liquided is, usually, a bad idea.

The problem happening on the Editor is not happening between OnLoad and OnStart, because OnStart happens before OnLoad, damn it. I'm working on a different framework at day job, where the Data Load phase happens before Starting the service and I ended up screwing up things in my memory.

I'm getting old, as it appears. (sigh)

Anyway. The show must go on.  

 

Edited March 8, 2022 by Lisias
POST EDIT

[R-T-B]

20 minutes ago, Lisias said:

You guys are, indeed, "my" Q/A Team.

QFT.  This is true of pretty much every mod that is free.  People forget it too easily.

The only small difference is some mods are lucky enough to have a (almost always small) team of beta testers.  Those beta testers are also free-time unpaid peoples who may or may not have time that day of the week though.  So same end result.  You often end up being the beta tester.  Be patient with us, please.  We do our best.

FWIW, I believe Kopernicus, which an absolute metric ton of mods depend on, has like 3 beta testers and I'm usually lucky to get one of their attentions before a release.    Often the Q&A team is the dev in question, and you, the user.  Be a team player.

PS:  Keep in mind, these statements are general in nature and apply everywhere, not just to Lisias.  He's as susceptible to "borking" as he calls it as any lone dev, though.

Edited March 7, 2022 by R-T-B

[Lisias]

ANNOUNCE

KSP Recall 0.2.2.3 is on the Wild, featuring:

• Allows patching AttachedOnEditor on every compatible part, no matter it has TweakScale installed or not.
  • Needed because a TweakScaled part borks when attached to another without it.

— — — — — 

---

This Release will be published using the following Schedule:

• GitHub, reaching manual installers and users of KSP-AVC first. Right Now.
• CurseForge. Right Now.
• SpaceDock (and CKAN users). Right Now.

All distributions channels are belong to us.  

—— — — — 

I found a workaround for upgrading the SubAssemblies!!!!

Use Craft Manager to load the SubAssemblies as they were Crafts, then drag and drop the thing back as a new SubAssembly! 

Edited March 8, 2022 by Lisias
POST EDIT

[DeadJohn]

On 3/8/2022 at 9:09 AM, Lisias said:

Allows patching AttachedOnEditor on every compatible part, no matter it has TweakScale installed or not.

I finally had a chance to try this tonight doing some merges and alt-click copies. It works! It works! It really works!

A big thank you for all the time you put into that fix.

[Lisias]

On 3/7/2022 at 4:25 AM, R-T-B said:

QFT.  This is true of pretty much every mod that is free.  People forget it too easily.

I think people are being deluded, being induced by some to think like that [other way].

It's already from a long time that some people are detracting OSI licenses, some authors around here appear to be interested on harvesting the benefits from the Open Source but are not interested on giving back - au contraire, the goal appears to be monetize at the expenses of Open Source.

And this twisted mentality about Quality is part of the scheme: the common user is lured into using these "higher quality" artefacts for free (as in beer) and as soon the OSI alternatives are no more (and so people gets virtually locked on such artefacts), you start to see unrelated demands as "respect" or even "donations to motivate further development" popping around.

Yes, you get free beer. But you can't get out of the party and using the toilet costs you twice the price of the beers you got for free.

Bait and Switch, I say.

Edited June 5, 2022 by Lisias
Better phrasing.

[Lisias]

Moving the discussion from TweakScale's thread, as this is related to KSP-Recall.

 

14 hours ago, Kor said:

I'm playing 1.12.3 with JNSQ and Tweakscale but otherwise a pretty minimally modded setup. I'm running into a problem with stackable cargo parts (struts, fuel ducts, small solar panels, etc.)

- If such a part is launched in a cargo container, it remains stackable until placed "in the world." Then it is no longer stackable.

- If such a part is launched as part of a craft, it immediately becomes non-stackable.

You found something new!

Initially, I did a test using only Recall, TweakScale (besides not using it, so it didn't not affected the test) on 1.12.3.

My first run was fine, I launched a cargo bay with 4 small solar panels and a command chair with an engineer, and made the engineer to weld the solar panels on the cargo bay, then unweld them and stored them on the Kerbal's backpack. And I could stack all of them normally (well, only 3 of them as 4 would exceed the weight a Kerbal can carry).

Hum… Not Refunding related [it's involved however], otherwise I would had not being able to stack the unwelded panels on the kerba's backpack.

By placing them on the ground and then recovering them, I could stack them back on the kerbal's backpack the same. Moving them to the cargo bay worked as expected.

Then I launched the thing again, but with a solar panel already strapped on the stunt. Things appears to work fine until I unwelded the already strapped solar panel - from this point, every solar panel that was instantiated into the World could not be stacked anymore. Weird! [on KSP 1.11.2 things worked fine, this only happened on KSP 1.12.3!!!]

So, yeah. Your hunch about Refunding being involved on the mess is correct, but the trigger of the problem is unwelding a stackable part that was launched with the craft and trying to stack it.  I find interesting that parts (with refunding) only loses the stackable ability once I unweld a launched part - until that happens, these parts behave as expected. [again, on KSP 1.12.3 - on KSP 1.11.2 the only trigger is stacking a good part over a infected part!] 

And then an additional misbehaviour: the solar panels are being "infected" not by being instantiated, but by being stacked over an "infected" solar panel! I could weld and unweld the solar panels at will, they only started to be unstackable when I stack them over an infected part. From this point, that specific part get "infected" and became not stackable!!! [This appears to be the root problem? Perhaps the other behaviour I detected on KSP 1.12.3 was something made trying to workaround the problem on KSP 1.11.x?]

You can stack a "healthy" part over an infected part once, but by doing this, that part gets infected and once you grab it, you can't stack it again.

Oh, well… I'm not sure if this is a missing use case on Refunding, a new bug on KSP, or both. I will try some more tests (as trying the thing on older KSPs to see what happens) and I will get back to you soon.

— — POST EDIT — — 

I reproduced the problem, ipsi literis, down to KSP 1.11.x.

KSP 1.10.x can't be used, as at this version the Inventory modules were not introduced yet.

Well, we have consistency. The problem exists, it's related to the Inventory modules for sure.

Now I'm trying to rule out or confirm Refunding as the source of the problem - it may be a innocent bystander caught in the crossfire on this situation - we must remember that until unwelding a part from a launched craft, things were working fine. So it's not a bug on Refunding's code, at worst, a missing use case - what would not be a surprise, I coded it on the KSP 1.9.0 times.

— — POST POST EDIT — — 

Geez… Just found a "new" bug on 1.11.2 : if you drop a solar panel into the runway, it pass trough and explodes… (sigh)

— — POST POST EDIT — — 

Opened an issue for the problem: https://github.com/net-lisias-ksp/KSP-Recall/issues/38

— — POST POST POST EDIT — — 

Additional findings on italics above. From now on, all relevant information (and evidences) will be available on github only.

I kindly ask the fellow Forum members to avoid cluttering this thread with incomplete and precipitated arguments, as well to avoid suggesting me to do anything that could be considered a crime on my Country.

Quote

Art. 12. Violar direitos de autor de programa de computador:

Pena - Detenção de seis meses a dois anos ou multa.

§ 1º Se a violação consistir na reprodução, por qualquer meio, de programa de computador, no todo ou em parte, para fins de comércio, sem autorização expressa do autor ou de quem o represente:

Pena - Reclusão de um a quatro anos e multa.

=====

Art. 12. Violating computer program copyright:

Penalty - Detention from six months to two years or a fine.

§ 1 If the violation consists in the reproduction, by any means, of a computer program, in whole or in part, for commercial purposes, without the express authorization of the author or whoever represents him:

Penalty - Imprisonment of one to four years and fine.

=====

Source: http://www.planalto.gov.br/ccivil_03/leis/l9609.htm

Additionally:

Quote

Softwares são desenvolvidos em linguagens de programação e salvos em arquivos de texto denominados códigos-fontes. Após um processo chamado de compilação, são transformados em arquivos capazes de executar tarefas em dispositivos eletrônicos.

Para o usuário, não interessa saber como as linhas foram escritas e, para o desenvolvedor (salvo nos casos de Software Livre), não interessa passar seu conhecimento a terceiros.

A princípio, esses arquivos de código-fonte estão protegidos, pois não fazem parte daqueles distribuídos por mídia ou pela Internet. Contudo, existe uma técnica que consiste na função inversa, ou seja, transforma-se o arquivo que executa determinado software em código-fonte. Dá-se a essa ação o nome de engenharia reversa. Realizar engenharia reversa de um software com sucesso representa mostrar ao público algo que foi objeto da criação humana e que, a princípio, estava protegido. Evidentemente, esse tipo de conduta é proibido pela Lei de Software.

A simples ação de identificação de código-fonte já é considerada crime no seu aspecto mais brando, conforme debatido no item anterior. Se utilizarmos o resultado da ação em outro software com intuito de comércio, termos a forma qualificada de crime.

==== 

Software is developed in programming languages and saved in text files called source codes. After a process called compilation, they are transformed into files capable of performing tasks on electronic devices.

For the user, it doesn't matter how the lines were written and, for the developer (except in cases of Free Software), it doesn't matter to pass on his knowledge to third parties.

In principle, these source code files are protected, as they are not part of those distributed via media or the Internet. However, there is a technique that consists of the inverse function, that is, the file that executes certain software is transformed into source code. This action is called reverse engineering. Successfully reverse engineering software represents showing the public something that was the object of human creation and that, in principle, was protected. Of course, this type of conduct is prohibited by the Software Law.

The simple act of source code identification is already considered a crime in its mildest aspect, as discussed in the previous item. If we use the result of the action in other software with the purpose of commerce, we have the qualified form of crime.

Source : Manual de Direito Digital, Glaydson de Faria Lima. (Digital Rights Manual), Section 14.9.2

it worths to mention that KSP-Recall is available on Curseforge, where rewards are granted - so, yeah, it's considered "commerce".  As well any kind of rewarding, as "donations" by the way.

However, the article on the book I transcribed above fails to fully describe Reverse Engineering. There's a kind of Reverse Engineering that it's allowed on my country for sure, the "Clean Room Design". This is precisely what I do on KSP-Recall.

Insisting on suggesting me to use the result of decompiled code into KSP-Recall is, at worst, incitement to crime in my country. I kindly ask the fellow community members to stop suggesting me such.

Edited April 4, 2022 by Lisias
POST POST POST EDIT.

[Gotmachine]

Simple.

The inventory system doesn't allow parts having resources to be stacked, so your Refunding stunt essentially prevent any part from being stacked.

The behavior is inconsistent because the check for this is only done in ModuleCargoPart.OnLoad(), which might not be called at all (newly instantiated parts in the editor) or called before you alter the part resources
Arguably this check should be enforced every time a part is manipulated, but in KSP defense, altering resources at runtime isn't a scenario that stock support out of the box.

Anyway, the only thing you can do is enforcing that rule from your side when you add the resource (setting ModuleCargoPart.stackableQuantity to 1 when it is >1), but that mean loosing the stacking functionality altogether.

To quote myself from a year ago :

On 3/22/2021 at 10:50 AM, Gotmachine said:

Your solution has much more potential for side issues and unwanted interactions.

A statement that has never ceased to prove itself over the last year.
If I may remind you, there is still a much cleaner solution to that KSP issue available for you to implement lying on a gist.

[Lisias]

On 4/4/2022 at 4:52 AM, Gotmachine said:

Simple.

The inventory system doesn't allow parts having resources to be stacked, so your Refunding stunt essentially prevent any part from being stacked.

AGAIN? Did you at least READ what I wrote above?

On 4/3/2022 at 11:52 PM, Lisias said:

My first run was fine, I launched a cargo bay with 4 small solar panels and a command chair with an engineer, and made the engineer to weld the solar panels on the cargo bay, then unweld them and stored them on the Kerbal's backpack. And I could stack all of them normally (well, only 3 of them as 4 would exceed the weight a Kerbal can carry).

Hum… Not Refunding related, otherwise I would had not being able to stack the unwelded panels on the kerba's backpak.

So, dude, Refunding is behaving. Something else is triggering the problem that involves Refunding  - and by pursuing this something it's very likely that I will discover something new, that so you will be able to use on your add'on

[snip]

On 4/4/2022 at 4:52 AM, Gotmachine said:

If I may remind you, there is still a much cleaner solution to that KSP issue available for you to implement lying on a gist.

A solution that is potentially illegal on my Country. [snip]

Edited April 5, 2022 by Snark
Redacted by moderator

[Gotmachine]

[snip]

On your specific issue with your refunding thing, I didn't investigate in detail, and I won't.
I'm just pointing out that you are spending a lot of time and effort trying to solve side issues that you're responsible for in the first place with that refunding hack implementation, something I warned you would happen.

The piece of code I suggested a year ago (team play !) is perfectly within the bounds of any KSP rule or country law, and certainly not any more or less than your own or any other KSP mod. No idea what you're talking about.

IMO, refining it (as it is, it has the issue that cargo parts IPartCostModifier costs will be accounted for twice, but there are ways to fix this) would be much less work than trying to fix your current implementation.

If you want to keep your solution of tracking IPartCostModifier costs though a PartModule on every part (which is useless since stock already does it correctly, available in ProtoPartSnapshot.moduleCosts), you could at least get ride of the fake resource thing (which is the main cause of the side issues).
Just persist your results on the module, then analyze the persisted state of that module in a onVesselRecoveryProcessing or onVesselRecovered callback (you could even keep the injection of your "refunding" resource for UI feedback, but by doing it only just before recovery you're greatly limiting the potential side effects).

If you have questions about any of this, feel free to ask.

Edited April 5, 2022 by Snark
Redacted by moderator

[Lisias]

On 4/4/2022 at 7:14 AM, Gotmachine said:

On your specific issue with your refunding thing, I didn't investigate in detail, and I won't.
I'm just pointing out that you are spending a lot of time and effort trying to solve side issues that you're responsible for in the first place with that refunding hack implementation, something I warned you would happen.

The piece of code I suggested a year ago (team play !) is perfectly within the bounds of any KSP rule or country law, and certainly not any more or less than your own or any other KSP mod. No idea what you're talking about.

The problem you consistently fails to acknowledge is that, in essence, you are putting my cheeks on the line of fire.

The kind of reverse engineering you are using is not legal in every country on the World, and there's a hell of an excellent chance of being a crime on my Country.

I want to say it again, a crime on my country. Not a misdemeanor or something to be dealt on a civil lawsuit - but a felony in which I risk being indicted under the penal code. With all the consequences this implies.

I just can't touch decompiled code (unless someone on Squad explicitly authorises it!) - as well any Brazilian KSP gamer, by the way. Downloading your add'on on Brazil is, in essence, software piracy. Even my work here is legally safe for me due the express authorisation given on Add-On Posting Rules and the API being officially published, as it's virtually impossible to infer all the KSP details we need to code by using just Clean Room.

It's nuts? Hell YEAH!! It's completely nuts, but until the subject is pacified on our Courts of Law, it's how things are around here.

[snip]

It's not a crime on yours? Good for you (really!). But even on USA things may go south in a near future, so it's not wise to have all our eggs on the same basket in a way or another.

So, in a nutshell: fell free to use any knowledge you get from reading my code and documentation. There's a reason I publish them as OSI, they are meant to be reused.  [snip]

I have a job to care about.

Edited April 5, 2022 by Snark
Redacted by moderator

[Gotmachine]

There isn't any decompilation involved in any of this.
This is using a quite self-explaintory "moduleCosts" public field and public GameEvents that aren't any more or less documented than anything you're using in your plugin.

[snip]

Edited April 5, 2022 by Snark
Redacted by moderator

[Lisias]

On 4/4/2022 at 9:00 AM, Gotmachine said:

There isn't any decompilation involved in any of this.
This is using a quite self-explaintory "moduleCosts" public field and public GameEvents that aren't any more or less documented than anything you're using in your plugin.

Read about the "Fruit of the Poisoned Tree" Legal Concept. [snip]

No one wants (or needs) a help that can ending up with the indiction due a crime, no matter how remote (for now) would be the possibility.

Things change, copyright rights are sold, and God knows if the new owner would not be a copyright troll in need to make some quick buck: anything you do will linger for at least TWENTY YEARS before stopping being a liability to you.

There're smarter (and safer) ways to accomplish what you want.

Edited April 5, 2022 by Snark
Redacted by moderator

[dlrk]

4 hours ago, Lisias said:

Read about the "Fruit of the Poisoned Tree" Legal Concept. 

Uh, I don't know what's going on here, but that is a doctrine about illegal searches by law enforcement, so whatever you are talking about, it's wrong.

[Lisias]

On 4/5/2022 at 12:03 AM, dlrk said:

Uh, I don't know what's going on here, but that is a doctrine about illegal searches by law enforcement, so whatever you are talking about, it's wrong.

(not) Exactly.

And this very same doctrine is applied on IP Law!

Quote

Some IP regimes, like trade secret law, apply fruit of the poisonous tree logic, allowing the plaintiff to recover not only for the profits the defendant made from secrets she actually stole and used, but also for the profits of any product that resulted from the use of those secrets, even if the product does not itself incorporate the secret.

Source.

Using knowledge that's only obtainable by decompiling the Source Code (that's automatically protected on my Country) can taint any work built over that knowledge. 

But once you prove that the same knowledge can be obtainable by empirical tests or any other means, you are shielded from the problem due reasonable doubt. Being not impossible that you could learn something without breaking the law, you can't be accused of breaking the law to obtain it without further evidences.

— — POST EDIT — — 

The Fruit of the Poisonous Tree concept is applicable on IP Law, but on USA it does not apply to Copyright Violations. On my country, it does - and this makes all the difference in the World (not to mention it being a crime on my Country).

Edited April 14, 2022 by Lisias
post edit - and adding some needed emphasis.

[Snark]

Various content has been removed, due to:

• personal remarks and provocative language
• accusations
• backseat moderating

Folks, let's please remember that we're all friends here, and there's no point in picking fights.  A few important things to remember:

• Please try to stay on topic.  The topic of this thread is this mod.  Getting into debates over general legal matters isn't really germane to the topic.
• Please leave the past in the past.  Discussions of current matters in the current thread are fine.  It's not appropriate to drag in complaints about past interactions with anyone; that's a form of personal remark and doesn't belong here.  Address the post, not the poster, please.
• Please do not make accusations.  It's not allowed.
• Please do not tell anyone what to do or what not to do.  You're not a moderator, and it is not your place.  If you think someone is behaving inappropriately, by all means report it and the moderator team will have a look.
• Best to leave lawyering to the lawyers.  Anyone who's not a lawyer is in  no position to make legal assertions, particularly not to anyone else.  Of course you may have concerns about legal matters, and how you choose to act on those concerns in your own affairs is your own concern; but please don't presume to lecture anyone else on the topic.
• It's perfectly reasonable for people to make suggestions.  Please don't jump down their throats when they do, regardless of what you think of the suggestion.
• It's perfectly reasonable to say "no" to someone's suggestion.  This is self-evidently obvious and needs no further elaboration.

A final note:  it's generally never a good idea to post while angry.  If you can't respond to something reasonably and calmly, best to wait a bit until you've calmed down enough that you can do so.  (Or if that's not possible, just don't respond at all.)  Angry responses never solve anything, and generally devolve into unproductive arguments where everyone (including innocent bystanders) loses.  So, can we take it down a notch, please?

Thank you for your understanding.

[glibbo]

I just like to play the game, I really appreciate what Lisias and everybody else does to try to make it better....

[Lisias]

4 hours ago, glibbo said:

I just like to play the game, I really appreciate what Lisias and everybody else does to try to make it better....

Thanks.

I want to add that I'm pretty sure that everybody on this thread is trying their best to do so.

But we live on a less than ideal World, with less than ideal rules - and, worst, different rulesets on many Countries, some of them conflicting. Conflicting rulesets lead to conflicting situations - and some few of them can be extremely enervating (due the nasty consequences of being caught by one of that less than ideal rules).

Please don't take any of my (surviving...) comments as detrimental to any of the correspondents. They are not wrong on what they mean to do, it just happens that I got caught on one of these less than ideal rules and I'm unable to do what was suggested (besides the suggestion having technical merit) - and the hypothetical consequences usually are only really "appreciated" by people who got caught by them before (I had an interesting life, you know? ).

KSP-Recall is engineered to cope with that less than ideal rulesets (even on different Countries than where I live), even if detrimental of better technical solutions when existent.

If you don't need to cope with the concernings I have to, by all means I encourage you to use any alternatives you think will better serve you.

Be safe!

Edited April 6, 2022 by Lisias
some entertaining grammars made less entertaining. And removing a less than ideal advice… :P

[Lisias]

NOTAM

Recently, an issue was reported on KSP-Recall about a misbehaviour when interacting with Procedural Parts (issue #41).

At that time, I didn't managed to reproduce the issue. My tests were biased on changing the Procedural Parts, when the problem was with DEFAULT Procedural parts - once you change the shape of the part, things worked fine. Unfortunately, it took me 20 days to realise the root cause of the problem, what I would probably take yet another 20 days without the help of DRVeyl, as well the help of StonesmileGit. Thank you very much, guys!

But eventually I nailed it.  

I applied a pull request with the fix to procedural parts. In the mean time, I also detected some opportunities for improvements  on KSP-Recall itself, in which I had worked in the mean time and now it's currently under testing.

Both change sets (on Procedural Parts, and on KSP-Recall) will fix the problem individually, but the Procedural Parts one will fix the root cause at once, preventing that something could be triggered again later by another add'on that needs the correct nodes's definition being on the Part's Config when OnLoad is called.

In the mean time, users affected by the problem (i.e,, having installed KSP-Recall and Procedural Parts) can copy this patch into your GameData. This is exactly the same patch I used on a pull request into the upstream:

Spoiler

// This patch fixes the Attachment Nodes definitions for the
// Procedural parts, fixing the following issues:
//
// * https://github.com/KSP-RO/ProceduralParts/issues/315
// * https://github.com/net-lisias-ksp/KSP-Recall/issues/41

@PART[proceduralBattery]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.1875, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.1875, 0, 0, -1, 0, 1
}

@PART[proceduralHeatshield]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.1, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.1, 0, 0, -1, 0, 1
}

@PART[proceduralNoseCone]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.3125, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.3125, 0, 0, -1, 0, 1
}

@PART[proceduralStackDecoupler]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.1, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.1, 0, 0, -1, 0, 1
}

@PART[proceduralStructural]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.375, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.375, 0, 0, -1, 0, 1
}

@PART[proceduralTankLiquid]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.375, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.375, 0, 0, -1, 0, 1
}

@PART[proceduralTankRCS]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.25, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.25, 0, 0, -1, 0, 1
}

@PART[proceduralTankXenon]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.15, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.15, 0, 0, -1, 0, 1
}

@PART[proceduralTankSRB]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  1.25, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -1.25, 0, 0, -1, 0, 1
}

@PART[proceduralTankOre]:AFTER[ProceduralParts]
{
	@node_stack_top =   0,  0.5, 0, 0,  1, 0, 1
	@node_stack_bottom= 0, -0.5, 0, 0, -1, 0, 1
}

 

On the not so bright side, unfortunately I took too much time to diagnose and fix the problem, and this ended up prompting the Procedural Parts guys to ask CKAN to declared KSP-Recall in conflict to Procedural Parts, preventing CKAN users from installing KSP-Recall (and, so, TweakScale that depends on it on KSP 1.9.1 and newer) when Procedural Parts is present. And vice-versa.

As a compromise to prevent this measure what would harm users of TweakScale and Procedural Parts, I had agreed on testing Procedural Parts for problems on each new KSP-Recall release. So, in order to fulfil my part of the bargain, I will need some more days of testing before publishing the next release.

In the mean time, I kindly ask Procedural Parts users to use (even than temporarily) the patch I published above.

Cheers!

— — POST EDIT — — 

Pinging @Galland1998, as you were the first to report this. Sorry taking so long!

Edited April 20, 2022 by Lisias
Some entertaining grammars made less entertaining.

[Lisias]

NOTAM

I BLEW THIS ONE. It's a TweakScale bug!!! Fixing it on TweakScale (obviously)

https://github.com/net-lisias-ksp/KSP-Recall/issues/42

Thanks to @Alexsysby the report!

Cheers.

Edited June 12, 2022 by Lisias
whoopsy...