-
Posts
7,440 -
Joined
-
Last visited
Everything posted by Lisias
-
If I understood the documentation correctly, they are intended for being use outside from a event driven UI main loop. In PHP, you recreate the World each Request (including SGDB connections, unless you use a Connection Manager, that by definition is external to the PHP.exe). Until the moment, I have evidences that on Unity, the IMGUI appears to work on the following life-cycle: you have a Awake(), when your MonoBehaviour is created, then a Start(). A Reset() happens everytime your Behaviours gets the focus, and then later a OnGUI(), called everytime it's your time to draw something in the screen (this sounds a lot as a Stacking Window Manager). But on the very Unity Documentation for OnGUI, you find a example where the GUILayout is used. =/ I know well a lot of things, but Unity is not (yet) one of them - but or someone on Unity's documentation team screwed up epically, or the OnGUI is being handled somewhat heterodoxly by us. However, here we have the Unity's life-cycle, where it's clear that OnGUI is called multiple times (so, it's not my "OnFocus", Reset() is the correspondent one). Ergo, yeah - the example I linked above is... not exactly the best one possible. IMGUI should not recreate everything each time OnGUI is called, it's plain nuts. For a good reason: this thing essentially implements a Stacking Event Driven UI in each GameObject. :-) Since you decided to implement your UI in separated GameObjects, all that clutter is just making your life miserable giving you nothing in exchange. What's precisely the worst possible way of doing things, from the performance point of view. If I need a button, I need a container for it. So, I create a Container, create the button inside it, configure the button attributes (size, position on the container, event handlers as "OnClick"), put everything hooked on a variable on the "Start()" and then, on the OnGUI, just tell Unity to "draw this container on this position". Such container is destroyed on the "OnDestroy" event, or you will have a memory leak. Somewhat more complicated life cycles can be implemented for Widgets that are not necessary all the time. Sometimes you need a Settings, other a Part Atribute Editor, etc, so in order to prevent having everything and the kitchen's sink created all the time (cluttering the heap and increasing the minimum memory footprint for your code), we build a FSM on the OnGUI to handle the mess. Of course, I'm telling you what we did on the Win16, Win32 and even Win64 (QT does the same, Android too - but in a highly abstracted way). Unity appears to be somewhat exoteric, as it appears. Here, on UbioZurWeldingLtd.cs, you can see the original author controlling states and creating "high level widgets" on the object to be reused. Follow all the references for the "_welder" attribute and you will see the guy "caching" some widgets. However, and you have a strong point that I didn't paid the due attention, there's a lot of calls to the methods you are complaining. Speaking frankly, this appears to be a memory bias from my side. =/
-
There's only one thing better than benchmarks for a old far... I mean... guy like me. Source code. :-) THANKS! :-) I choose to give a peek on a older version than 17.9, since you stated that already made the performance improvements, and I need to see the older way in order to understand what happened. So I gone for the 16.11 version, and this is what I saw: On SCANsettingsUI.cs, there's a function called DrawWindow, that does the heavy lifting of drawing .. the Window. There're a lot of gui_settings_<something> being called, where (obviously) the heavy lifting is being done. And here is where things gone... not the best way possible: The widgets are being created and thrown away every frame! I already had inferred this (really, I used to program C++ and Delphi for Windows 3, and GUIs hadn't changed at all since them, only their abstractions), but know I'm sure: this is not the best way to handle event driven GUIs. Event Driven code needs to control states. So, the window is in "uncreated" state at startup. When you need to show it, you change its state to "creating" and, when this state is completed, you change it to "visible". You can change the state to "hidden" (where it still exists and are being updated, but not drawn on screen) or you can "close" it, when then you delete everything and change the state back to "uncreated". So you need to write "state change handlers" (yes, this is essentially a FSM - Finite State Machine): you code one function to handle "creating", another one to handle "visible", one for "hidden" (if applicable) and one for "close". More complicated FSMs needs 3 handles for each state: phase_in, level and phase_out (this helps to keep the states number to a minimum, but it's not exactly necessary here). So, you just create the widgets in the "creating" handler. And from now on, you call the "visible" handler instead - where you just update what's already created and show it. This prevents the Garbage Collector from going havoc. I followed up the code, tracking what interface/abstract class the DrawWindow belongs, and got into SCAN_MBW.cs. It is called inside a function called DrawWindowInternal, that it's passed as a parameter (so it's a handler itself) on the DrawGUI, that it is itself another handler that the Visible attribute uses to put on the current window's draw queue. Interesting enough, the SCAN_MBW originally relied on SCAN_MBE to be called on the event changes. Even better, there's a DrawWindowPre and DrawWindowPost hooks for the phase in and phase out event handlers for what I called "Visible state", but in this code they were "short circuited" into the same event handler as the DrawWindow in the present implementation. Pheeew. This was almost a full-blown Window Management toolkit! :-) Something I will look on again for sure. The problem I see on this is that the event driven support from SCAN_MBE is not being used anymore, and another subsystem were "hammered" on it, overruling the previous life cycle. This new lifecycle is the one recreating the world on every frame instead of reusing what was created in the previous state (PHP style!). So, it's not a surprise your GC is going nuts. :-) While far from ideal in the present implementation (from the code style point of view), the UbioWeld (I'm also mangling it on my own fork) plugin does the right thing on this. Ideally, each Window should be implemented in his own class (that would prevent some mess while debugging the thing), but the way how things are done (controlling states, and just updating what's already created on a OnGUI call) is there.
-
Purist or not? Do you use DLC parts in your creations?
Lisias replied to lodger's topic in KSP1 Discussion
Well... A bug is only a bug until it's fixed.... Or documented and promoted to a feature. :-) There's no choice but to wait and see what happens. =D- 51 replies
-
- 1
-
Purist or not? Do you use DLC parts in your creations?
Lisias replied to lodger's topic in KSP1 Discussion
Perhaps it's not a bug, but a visual way to tell what's "up" and what's "down" on the part? These markers are purely aesthetic - or at least, I didn't found absolutely any difference by using different markers on my parts. But what I would like is a way to tell where is +Y and -Y on the part. Sometimes, I ended up rotating the parts while stacking them up, and then when I attach something on these parts, that part became 180º rotated and I need to rotate it back. While adjusting the CoL, it's usual to reattach the wings on an adjacent part, and this rotate and rotate again thing can be annoying and error prone. Without visual cues about what's +Y and -Y (as the part you screenshoot), you cannot prevent such errors before they bitting you, and perhaps this is the way the Add'On author found to solve this.- 51 replies
-
- 1
-
From my times on Windows 3 programming, I learnt that using Modal Windows (what PopupDialog is) to do Modeless Windows job is rarely a good idea. But, granted, things may had changed. This is the time in which one need to call for numbers using Benchmarks. :-) Calling drawing functions, by itself, is not a problem necessarily. But this discussion is going to the same places as the Stacking versus Composite GUI debacle: it depends essentially on the environment you are running them and how you are running them. It's better to find some time to do that benchmarking I mentioned before further talking about, otherwise I would be just exchanging opinions.
-
Yes, but the argument I'm counter-arguing is that it's useless. My argument is that learning it can worth the pain on the long run. I agree that OnGui is somewhat esoteric (believe me, I worked with "worse" things that worked better), but IMGUI has it uses - mainly, by using just code to handle things instead of creating GameObjects (and all the clutter) just for simple widgets on the Editor screen. What, well... Helps performance.
-
I beg to differ. From my times on Orbiter, we use to use GDI directly to draw 2D (essential for HUD and MFDs). Then O2016 came, changing everything, and absolutely all the plugins that draw 2D became useless. O2016 provides now a 2D API, that is not that pretty, but it's guaranteed to work in future versions (local or remote). If anything changes badly, we will bash our heads on the wall only once (to update that 2D API), and then everything works again. I think that keeping on OnGui will prevent such problem, mainly due Unity itself.
-
[1.2.x/1.3] MemGraph 1.1.0.3 - with Stutter Reduction
Lisias replied to Padishar's topic in KSP1 Mod Releases
It's not exactly related to Garbage Collector, but it also hurts as memory is consumed: if you are a helpless Mac user, since El Captain you are forced to tolerate this abomination called Memory Compression (zram for the mobile users). Do you remember Ram Doubler, QRAM and other "ram doublers" on the Windows 3 era? Same thing. Same crap. Compressing memory before swapping it to disk is a nice idea, since the lesser time you spend on I/O is far worths the extra time spent on compression - but as an alternative for swapping, it hurts gaming. Badly. Take this in consideration when gaming on Mac and before hunting down what can be a Unicorn on your mod. -
[1.12.x] JSI Advanced Transparent Pods (V0.1.24.0) 12th Sep 2021
Lisias replied to JPLRepo's topic in KSP1 Mod Releases
Hi. I found an interesting bug on JSI Advanced Transparent Pods on KSP 1.4.1 for Mac, running on a Mac Mini Mid 2011 & MacOS Sierra. When the camera is at one specific altitude, the Kerbin rendering became flawed, with some faces not rendered at all (see the picture below). I tested it on a plain vanilla KSP 1.4.1 installation, all in the default settings, on a plain new save in sandbox mode. Absolutely nothing changed, besides the plugin and the test craft (all stock parts). The KSP.log from the testing session is here. The Player.log is here, and the craft "source" is here. There's some in situ testing you need me to do? I'm the one with the offending machine, and this kind of error would be detected sooner if this would happen in anything but a exotic hardware configuration. :-) -
What is your most facepalm-worthy moment regarding KSP?
Lisias replied to MaverickSawyer's topic in KSP1 Discussion
It just happened. I'm trying to figure out what mod is causing a glitch on the Kerbin rendering from space that, oddly, just happens at a certain distance - and it's the reason I didn't noticed it before. Since I want to make a video for a challenge, this glitch became a showstopper and then I'm hunting it down. So I decided to move all GameData to a backup folder, and copy back a few mods gradually each time to trim down the culprit. Easy, just a bit time consuming. But I forgot to backup my save, the game deleted everything that was using a mod (and *everything* was using a mod), and now I loose the vessel I was going to use on the recording (and some stuff more). =P I'm feeling pretty stupid by now. =D -
Have you ever done something really cool completely by accident?
Lisias replied to severedsolo's topic in KSP1 Discussion
This is *waaaay* interesting! Time to twist some rules on some challenges... -
There's no free lunch. You gain something, you loose something. I used to play Orbiter until recently. There're fabulous work done there. But writing mods to it is far from being for the faint of heart. C++ is not that easy, it's hard to debug and "exceptions" just crash the whole shebang instead of being logged into a file. :-) For *real* space simulation, I don't think anything will surpass Orbiter for a long time. But to having fun, both writing mods and playing (with or without mods), I think that KSP is still the thing. They're not mutually exclusive, however. We can play both (if we manage to find the time, obviously!)
- 637 replies
-
- 3
-
[snip] Anyway, the developer's exodus are not just off-topic, but also covered by a thing called NDA, and believe me - you are even more wrong about this than you think. There's not a single chance that anyone, anywhere, would be transparent about this.Not on this case, not on any other case. Non Disclosure Agreements have this name for a reason. :-)
- 637 replies
-
Au contraire, this time is the exact opposite. They said what they think was going to happen ("1.4.3 next week"), something change or gone wrong, and then we have a situation created exactly by the transparency you say is the way to go. Sometimes we forgot that people do what people do, and not all the people are like "us". I'm pretty confident that such transparency would work with you as much as it would work with me - but it didn't worked for a lot of people, and know the guys have another fire to put out. The "sweet spot" of communication level is somewhere "lower" than this, if we take in account what's happening on this thread. But, granted, somewhat higher than the usual practice. I think you're mistaking transparency with communication skills. Low transparency is actively hiding information. Low communication skills is failing to show that information effectively. These are two different problems that happens to have the same final result - but being different problems, they need different solutions. "Use the right tool to do the job right" Nops. No new depot on steamdb.
- 637 replies
-
Sausages, laws and software: too much transparency and it will affect your stomach. :-) The "level of transparency" is not that bad - you can find the information (or infer it) with proper research and perception - and this appears to be the problem. I think the problem is on the Communication level - and this can be happening even inside the Team itself, and the communication problems with the customers is more an effect than a cause.
- 637 replies
-
- 1
-
I saw the light, I mean, read again some PMI essays. :-D Developing KSP is a *PROGRAM*, not a *PROJECT*. Any attempt to handle KSP as a Project will fail.
- 637 replies
-
Purist or not? Do you use DLC parts in your creations?
Lisias replied to lodger's topic in KSP1 Discussion
IMHO stock is what everybody gets by buying the game. The DLC is a paid add-on. An "official" add-on, but yet, something added to the game after being drafted from the shelf.- 51 replies
-
- 1
-
Google for it. What happened at that time leaved a lot of scars around here, and it's probable that the moderation would intervene to prevent a flame war.
- 637 replies
-
And this is a problem. Believe me. The number of customers that complain are small compared with the customers that just go away. The complaining ones are the ones willing to stay, and since they are facing some problems to get what they want (stay), they complain in the hope of get things fixed. Happy people don't bother others because they are happy. Unhappy people does. And unhappy customers are customers going away (with their money).
- 637 replies
-
- 3
-
As I said before, KSP is like a vintage operating system (in size and complexity). Features as added as the current ones are stable, but now and then a new feature breaks a stable feature, and then we have a patch issued. The usual life-cycle of a nowadays game *DOES NOT APPLY* (and I wondering if someone at TTI's HQ is reading this and learning something). A main stream game usually are developed for years (two is usual, but some ones took 10 - I'm looking at you, Last Guardian) in closed quarters, being published only when someone decides it's time to go gold. It's essentially a Cascade Development Process from the user's point of view (internally, God knows what goes). Once it hits the Box Office, it's a product, with a product's life-cycle. KSP is like Windows on this point: it's a Featured Driven Development (anyone knows RUP?). There's no way anyone but the biggest players could deliver such complexity in a one shot development process, so the features are delivered as soon as they are implemented. However, this leads to a problem: cash flow. Once a customer buys a version, it had paid for the features the product already have, but who pays for the new features? New customers. If by some reason these new customers declines in number, it affects directly the cash flow and, then, the capability to finance the resources to keep the development! The efforts being (fiercely) applied in some non-critical features (as Mission Builder and Localization) appears to corroborate my thesis: these guys are fighting for cash flow. We, current customers, are out of the cash flow. We already had given them the money, and the money was already been spent. So, given the choice between fixing a bug that affects a loyal customer (but that already has paid), and one the potentially increase the user base (what means *incoming*), it's easy to understand why the Management (probably TTI's management) are taking such decisions. What can be done? Essentially, what's being done: understanding that sometimes "things" happens, but actively complaining when something stupid happens due absolute lack of attention of the development team to us, current user base (being such lack of attention a demand of the management or not). The best and only way to help Squad to deliver a good product (or service perhaps?) is voting with our money. Things goes fine (or the finest it can be), we buy the DLCs and/or whatever they sell to finance the development. Things goes to the tubes? So the cash flow - we stop spending money with them. This is the only argument that Squad can use to counter-argue a short vision decision from the management: "You will loose more money on the long run than you will win in the short". Mainly because this is the only argument that really matters to Management: money
- 637 replies
-
- 3
-
Disclaimer: It's all pure speculation, I'm pulling all of this out from my... hat... :-) and I'm extrapolating using what I learnt from my previous work on a multinational corporation. It's essentially a fictional short story. :-) A plausible one, nevertheless. The 1.4.0 launching date was a business orientated decision (ie., something that must happens to satisfy a business interest, and not necessarily decided by a business man). I think this is what happened due the somewhat large number of unhandled bugs - but hey we got Parachutes and some product Localizations (Brazil, Italy, German and French - exploring new markets may be the business need to be addressed ASAP). The 1.4.1 version was probably already scheduled (or at least planned) by the tech staff, as these guys are not stupid and already knew that 1.4.0 was going gold before being ready. Something messed up in the mean time, and 1.4.1 was launched before being ready too. *THIS* is the real issue, as it appears. 1.4.2 was so *fiercely* rushed into production, in the most corporate style: in the blind believe that 9 pregnant women can deliver a baby per month in the next 9 months.
- 637 replies
-
- 2
-
My point is that it's pointless (pun not intended) to address this to the developers. This is a business decision, and should be handled as such. Devs do what the guy with the money tells them to do. We must address our concerns to these guys, not to the devs. Since we don't know who's this guy, then we address our rage =P to the Squad Team as a whole, and then they have an argument to be used with that guy, Well, clearly someone there really *do not* care about present customers, and are focusing on new ones. You are right, devs usually love what they do. But they need money to pay their bills, not love. And this money come from someone that doesn't love the game, but the incoming the game can provide him. We, users, need to find a way to to use money to tell someone, somewhere, what they should not do with the game we love.
- 637 replies
-
- 2
-
What, IMHO, it's the right way to address the thing. The dev shielding is (between other things) precisely a way to redirect the backslash to the group as a whole, and not to individuals. From now on, it's over the Squad's shoulders the responsibility to address the issue and fix the problem. How? Who? When? It's their decision, not ours. They will win as a whole, or they will fall as a whole.
- 637 replies
-
- 1
-
My bad, I didn't expanded the idea correctly: the same things that break mods, break the game internally. You can see KSP as a small, general physics and world drawing Kernel, and a ton of mods interacting with themselves in order to have something useful drawn on the screen. Some of these mods are written by Squad theirselves, some others by third-parties (us). I have the feeling that when they updated the "kernel" to cope with Unity's new version, they didn't propagated correctly all the changes to their "mods", and then someone above them told them to rush the thing out the door at some arbitrary (from their point of view) date, and then they crunched things the best they cold to meet the deadline demands, not the quality ones.
- 637 replies
-
People do what people do. We need to draw a line somewhere to prevent verbal abuse escalation, but if you draw the line too low, people just leave. Paying people, I must remember. One need to learn to tell bad from evil. Bad can be handled and it's not rarely useful. People needs venting. It's what allow them to come back and try again. We need to learn to cope with that. The same can and must be said about users. Users invest they scarce free time on the game. Time that cannot be recalled. And they demand some satisfaction in exchange of such time invested - otherwise, they get angry. The very angry you get when your money invested didn't rewards as you was told it would. Developers are being paid to develop. Users are paying to use. This is a HUGE difference.
- 637 replies
-
- 2