Jump to content

Lisias

Members
  • Posts

    5,088
  • Joined

  • Last visited

Everything posted by Lisias

  1. Well… I came from the car industry too (after jumping ship from the Mobile). And I know something for sure - anyone on the* team being caught mistreating a potential customer the way I saw happening on this thread would have some serious problems on his/her employability. You just can't point your finger into your customer's nose yelling "I'm a professional on this field and you are not" and expect to keep their money - even when you are right, what's (frankly) not too common: the customers know their problems better than you, they have problems on communicating them to you. Boeing is giving us a hell of a lesson about how to cope with criticism. I suggest we listen to these guys, they are the real deal.
  2. A fantastic real-life use for Infernal Robotics! Ping @Ben J. Kerman !!
  3. Lisias

    The Probe!

    Hail Boeing, uh… Probe! Jebediah finally gone to Space! In one piece! https://www.engadget.com/boeing-starliner-kerbal-space-program-jeb-212326380.html Congratulations, dude! Jeb is on ISS now! (skip to 4:06)
  4. So it was organic and expontaneous? I'm impressed!
  5. Believe me, I know! Believe me, I don't care!!! It's funny to remember now, but at that time I got sick with the motion. It's like sailing on rough seas!
  6. In My Humble Opinion, a WAY better way to counter act criticisms was done by… Boeing! A Jebediah plush was sent to space on the Starliner. EXCELLENT P/R stunt, I say. This is an argument I can see value on a discussion like this one we are getting around here. As we say around here in Brazil, "Águas passadas não movem moinhos" (water under the bridge do not move mills). What you are doing today is what matters. https://www.engadget.com/boeing-starliner-kerbal-space-program-jeb-212326380.html I think that at least the P/R issue was addressed beautifully. (I loved this one - I was expecting something like this, to tell you the true) [snip] Cheers.
  7. No one beats the Dutch, however!!!
  8. IMHO we are giving too much attention to the form of the message, and to few to the content. Sometimes what we are understanding as stalling or deflection are just the dude/gall missing some nuance due language barrier or some previous post - or even some emotional response triggered by some other post that leaked into the current one (I'm surely did it sometimes). From my times on a multinational, where we had to talk to people from different countries, I had ended learning that a German can tell he/she loves you in a way a Brazilian may think he wants to ki... punch you. And a French can tell he/she wants to punch you in a way a Brazilian may think he/she loves you. Perhaps something similar may be happening on this discussion? Both "sides" appears to be interested on a good exchange of opinions - besides some exasperation here and there...
  9. There're some of these around here where I live: And this is from another state of my country: The very interesting thing is that besides being a puller (the second axle from front to rear does the traction), the engine is on very rear - so we have two articulated drive shaft from the engine to the driving axle. And I don't have the slightest idea how they do with the gear shift! On a side note, the last wagon where the engine lies is bumpy as hell, by God's sal]ke. The most comfortable wagon is the first one - dual axled. By a mile!
  10. You appears to be mixing different situations from different times on the same argument. Of course that the mindset the stakeholders had before the pandemics are different from the mindset after it. For the best, but also for the worst. Whoever is paying for this party is still doing it because he thinks he still can get a good profit from it - but as time passes, that profits shrink a bit, and he also knows it. And since this dude makes a living by maximising his profits, it's reasonable to conclude that since he didn't pulled the plug yet, he still expects to have some. But this doesn't necessarily means he's happy about it. The zeitgeist before the pandemics is drastically different from the zeitegeist we have now. World had changed absurdly, and you can bet your nice corsair keyboard this affected drastically the expectancy of profits - what's also affecting how the stakeholders are managing the pressure on the dev team. No primary stakeholder is willing to risk bankruptcy for any dev team in the World - unless he's already facing bankruptcy and there's nothing else to lose, so keeping betting on the product is the best option no matter how bad things may be. So, since there's no sign of financial troubling on TT2, and there's no sign that Private Division is going to be merged or decommissioned, and they still are funding the KSP2 development, apparently we can conclude that they are still funding the project because they still think they will recoup the costs at least. But we can't say they are sure they will have an acceptable profit on the thing, they may just be throwing some more money on the thing in order to avoid losing what was already spent - what sometimes can lead to the Sunken Cost Fallacy - no one is above the risk of falling on it. Not me, not you, not them. The complexity of the games from that time, as well the complexity of the tech environment was way, but way less complicated than nowadays. But some of the people are still the same, and unfortunately I think they had exhausted their ability to cope with the current development environment. The things I had seen on Unity, frankly… Dozens of spinlocks on a multi-task, multi-core environment? Seriously? We are not running games on a 68000 anymore. But yet... On a somewhat shallow analysis, the new guys appears to have the technical expertise, but not the competence to handle some subtleties of the development (not to mention basic tasks management or plain maturity). And the old guys failed to keep in touch with all the details of the current modern tech environment they need to cope, they apparently failed to recognise the need to learn a lot of the thingies the new guys learnt. We appear to be a group with different and distinct mindsets, with different and distinct abilities and competences - all of them failing to merge into a cohesive development effort. Given the harsh economical times that are approaching, I think the companies that will survive tomorrow will be the ones that will solve this dilemma nowadays. Things are going to get way worse before getting better. A product that WE didn't paid a cent for yet. But some people are paying for it, and they want their money back - with interest. And since we are the ones that are going to provide such money and interest in the future, the discussion on hands are not that dismissible.
  11. I wont call it "hate", but I can't criticise you for doing that neither. But definitively, it's not "blind" - there're clues (if not evidences) that he have good reasons to think how the does. It doesn't means he's right, tough. It only means that perhaps he can be. That's an excellent argument. All the heat NMS got was by Sean Murray losing the control of his anxiety and ending up talking too much before the game release. NMS would still be a bit bleak and somewhat dull game on the launch, but these weakness would not had be so evident at launch without all that heat he inadvertently started by talking too much. And, really, the game was good enough to be released. All that bad press was undeserved - but I can't say it was uncalled for... Staying silent while doing the work is a good way to handle the heat from some stakeholders - as long you have support from the primary ones (the guys that are funding you), and, believe me, Seam Murray didn't stayed silent to them. IMHO both you and @PDCWolfare forgetting that besides we are stakeholders on this project too, right now we are not the primary ones - we are somewhere between secondary and excluded at this point. Until we start to throw some money on the product, they don't own us too much (if any) explanations, so unless they are being naive as Sean Murray was, they are only telling us what some key dude there (a primary stakeholder for sure) thinks they should be explaining. There're good arguments on both sides of this discussion, and I think we could be getting even some more insights about what's happening if we manage to remember that when arguing.
  12. I know. There're a some add'ons with faulty config files around, but since on vanilla KSP they pass trough (and I'm starting to figure out why Squad royally screwed up on KSP 1.9 on that Editor stunt), blaming TweakScale as a scapegoat appears to be the most usual way out of the mess. Without the affected add'ons' authors collaboration, I'm afraid this is too much work for me doing it alone. Technically, I can launch a TweakScale Companion for Tantares and BDB to tackle down the problems on a patch or even some code, but doing it all by myself is over what I can do on my free time. No. It was outsourced! Look for the "All Tweak" thread.
  13. If you want to suck even more, I'm the right guy to help! But if you want to get better, I suggest some older vídeos from Scott Manley. I linked one of his play lists, the one I think it will help the most now. But check the others ones too! Cheers.
  14. Found the source of the problem! (finally!) The "Grus*" parts from Tantares are flawed somehow. I don't know yet what's happening with them, but the problem until the moment is only happening with them. I initially considered that it could be a conflict or bad interaction between AttachedOnEditor and ModuleProceduralFairings (the only Module left after I started to dismantle the parts looking for the source of the problem), but when using the Stock Fairings (that also use the ModuleProceduralFairings), nothing wrong happened. So it's something on the mentioned Tantares parts for sure. Couldn't figure out exactly what yet (I suspect it's something similar as the problem I had with Procedural Parts, but it's only a guess at this moment). The best (or less worst) work around I could find for now is to remove AttachedOnEditor (and also TweakScale in abundance of caution) from all the Grus parts that have ModuleProceduralFairing. I'm trying to figure out a work around for the WeekEnd. Keep an eye on https://github.com/net-lisias-ksp/KSP-Recall/issues/44 . — — — POST EDIT — — — @hugoraider, I'm stuck. Besides having a lot of parts throwing exceptions on Part Load, a few others have yet new problems that are screweing up AttachedOnEditor. However, it is needed by the part nevertheless otherwise the parts would be scattered around while trying a merge (and probably ALT+Clicking them) - so we are in a catch-22 situation: can't use the AttachedOnEditor on the part, but can't use the part without AttachedOnEditor. Further work on it seems fruitless to me because: It's not something wrong on KSP-Recall neither TweakScale. So there's nothing I can do on them It's really something on some parts of Tantares (and relatives) So it's no up to me to fix them Historically, 3rd party add'ons were reticent on accepting my pull requests with the fixes So it's usually a waste of my time trying to fix them myself. I think you should talk with Tantares maintainers about this issue. I will gladly help to diagnose and fix the problem if this will lead to the problem being fixed on their side, but I ask you to understand that I reticent on doing it by myself.
  15. I hate to say that, but I have too. On the pretty old days of the Siemens Mobile, I had worked on what I think may be one of the first A.R. games for mobiles, a thingy called Cuddly Combat. It was the first 3D game for the Siemens SX-1 for sure. And we had a budget, and we had a deadline, and the Siemens Mobile's CTO (I think, don't remember exactly his position - Germans have different hierarchical structure) more than once explained to us (sometimes, on the most German way possible. ) that the constant delays we were having were costing them money and that besides the project was essentially P&D, some results were expected anyway. We ended up delivering it, but yeah, we was being pressured for results. If you never felt the pressure of a deadline or a budget, be absolutely sure that you was shielded by your boss. You own him a beer.
  16. Still having my cheeks mercilessly bashed by the problem. This kind of problem I'm getting from AttachedOnEditor, historically, is related to parts being screwed up somehow by being mangled at runtime (as Procedural Parts does) or while being "Compiled" by the Part Compiler - something happens, the worker's thread is killed, and a lot of things are left behind - as creating the data structures AttachedOnEditor needs to work. Checking my KSP.log that should be pretty similar to yours, I see a huge amount of exceptions being thrown by the Part Loader, so my current hypothesis is that that crapness is related to the problem at hands. As soon as I have time, I will hunt and remove all the parts borking the Part Loader and see if the situation improves (if any of that borked parts are being used on the sample craft, then we have one more evidence to corroborate the hypothesis). Then I will reevaluate. This thing is going to fight back...
  17. That part probably has TweakScale hardcoded on it and the PartLoader is complaining about it. You can safely ignore this - but you can also get rid of it by shoving the following patch somewhere on your GameDatabase (I suggest GameData/__LOCAL/TweakScale/cleanup.cfg for easy tracking): PART[*]:HAS[@MODULE[TweakScale]]:FINAL { -MODULE[TweakScale],* { } } It will remove the TweakScale data from the parts before KSP tries to loading them, and so the PartLoader will not complain about its absence. Other than that, nothing else will change. Cheers! (Just remember to remove this thing if you ever decide to install TweakScale!)
  18. Almost surely not. That patch could be placed virtually anywhere, I suggested saving it on that __LOCAL thingy to easily locate and remove it there when needed (as we did now). But once I detected the Heatshield0 problem (and it was correctly patched with AttachedOnEditor), this eliminated any chance of that patch being necessary, because the trigger for the problem is AttachedOnEditor being patched on at least one part with something weird.
  19. That "GamaData/__LOCAL/KSP-Recall.cfg" one I posted a bit before and that did't worked for you!
  20. Yep, I finally found something weird here. I found a weird NRE happening on a Stock part you are using (Heatshield0) that doesn't happens on a (almost) vanilla KSP 1.12.3 installment. Remove that Patch from your rig, it's useless. Someone is screwing up the Heatshield0 , inducing AttachedOnEditor to bork, what kills the thread, what leads to that result I posted above. It's unknown if it's the same thing happening to you (your screenshot is different from mine), but it's an anomaly no doubt. I'm still working on it, I will advise any news. Full details on https://github.com/net-lisias-ksp/KSP-Recall/issues/44 However… In the mean time you want to play the game, so right now I can give suggest you to remove the Heatshield0 from that craft file and see if the problem goes away, If the problem is still there, I'm afraid that the easiest way out of this mess until I fix it is to remove TweakScale from your rig - what will prompt KSP-Recall to do not patch AttachedOnEditor on anything. The source of the problem will still be there, but since the triggers will not be in use, you will probably be able to keep playing in the mean time. I will come back to you as soon as I have more news about this.
  21. Hi! I (more or less) reproduced the problem: And created an issue on Recall for it : https://github.com/net-lisias-ksp/KSP-Recall/issues/44 (I think it's a missing use case on Recall, and not exactly a bug on it). To tell you the true, it may be a similar problem I solved on Procedural Parts. With a bit of luck, a similar fix will do the trick. I will come back to you ASAP - Day Job™ is demading more attention than usual this week, so I'm afraid I will have time for this only on the WeekEnd. However, I have a hunch: perhaps by adding AttachedOnEditor on everything the problem may be mitigated (I had a somewhat similar misbehaviour recently on a system where AttachedOnEditor wasn't patched on some parts, as it's happening on the craft you provided on my rigged rig). Backup everything (as this may backfire on us) and put this patch somewhere on the GameData where you will remember to remove it later (I suggest GamaData/__LOCAL/KSP-Recall.cfg). @PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA],!MODULE[ProceduralPart],!MODULE[WingProcedural]]:FINAL { %MODULE[AttachedOnEditor] { active = True } } As a matter of fact, KSP-Recall 0.2.2.4 already does it when TweakScale is installed. Are you using Recall 0.2.2.3 or older? I couldn't download your KSP.log, as it was already on the trashcan when I tried to download it. You will need to load and save the craft (to refresh the AttachedOnEditor internal data) before being able to attempt a merge with it. In a way or another, let me know about the results.
  22. My clients QASing the system. After the damned thing was deployed on Production…. And what's the sentence, you ask? "It goes on the square role…" It's now a meme on day job...
  23. I'm proud of the Swiss! "A company from Switzerland called AirYacht gives you the chance to hook your ship to a massive helium-filled airship and take a pleasure cruise through the skies in a yacht." ] Source: https://interestingengineering.com/hybrid-flying-luxury-yacht-land
×
×
  • Create New...