Nazalassa

N 5

Had some fun

Now we can change any texture, not only the ones we can put the mouse pointer on :D

Noted. (will fix in a relatively near future)

Besides, HUDReplacer does not appear to work in: Mission builder Settings Tracking station In the last two ones, UI elements are loaded, but it's not possible to perform either a dump, a reload, or to ask what is the image here. It can replace any internal image - more on that once I've restarted KSP.

The list of things that load images when opened is now: KAL editor "Play Mission" window (main menu / start game / play missions) Downloading update rn

I have, um, already made that although it is not yet available for download. (joke) If you want the file, you can get it here, just put it in the "flight" directory (GameData/Naztheme/Flight). Note that you have to restart KSP if you want the "normal" texture to show up. That said, the texture's 1:1, so it won't be really hard. Anything that only uses stock textures will work fine (except if it uses some textures that haven't been done yet). If, however, a mod uses its own textures, then I don't think it will work, I (or we) will have to add a bunch of, or at least some, textures to the mod. But I'll think about it when I'll have put more textures in the stock game (I'm planning to do the flight scene, and finish the AG tab in the VAB).

N 1

N 3

-- BEGINNING OF TRANSMISSION -- After having tried to get aligned pixels on the screen for various elements (recover button, etc.), the way KSP's UI elements are made internally (the images themselves) and are displayed are completely inconsistent, and I feel like it's a joke. Let me explain the many issues I've found making my texture pack (no doubt I'll find even more). Inconsistency #1 For a button, you need 4 images: when it's idle, when the mouse's over it, when it's pressed, and when it's disabled. For some buttons, they're all in the same image. (example below: the cargo button in the VAB's topbar) But for other buttons, these four images are separate! (example below: the crew button in the VAB's topbar) Normal: Over: Pressed: Disabled: And the use of either of these ways is not even consistent! These two buttons are right next to each other in the VAB's topbar. Inconsistency #2 Buttons are not rendered 1:1. If you set only one pixel in an image, it won't appear as a pixel on the screen - or if it does, it's rare and you're lucky. I believe the images are mapped to rectangles (like with UVs) and therefore are a bit distor[d/t]ed. Sometimes part of an image is rendered 1:1 (example: the corners and sides of all the rect_round_...) but not the rest of it (example: the center of all the rect_round_...). But that's not really a problem for borders. It gets more problematic when it happens to buttons. Personally, I want the buttons (and everything else) to be "clean", which means that I want to be able to set single pixels in a specific color, which is damn hard when the image is slightly off-centered by the rendering engine, or anything like that (especially when it's not rendered 1:1). Here's an example. I want to show this on the screen: So I have to feed the game this image: These buttons (VAB topbar and similar things) are rendered 3:8, 3 pixels on the screen are made from 8 pixels on the image. I have to use this pattern, which is a grid of 1x1 black and white squares when given to the game: For other buttons, such as the recover button, I give up - it's impossible to get the game display proper pixels! I know it probably wasn't designed to do that, but I think it would be better if they just used 1:1 images - faster rendering, less complexity... Maybe they did that because they want the UI to be scalable, in which case um... (they could do several versions of the images... Bah.) For some buttons, like the little down arrows that show on the KSC scene to indicate nearby ships, it seems that they are randomly shifted by a fraction of a pixel each time they render differently - changing a pixel can cause that, even without moving the camera or things like that (it could have an influence). One more thing with this arrow: apparently the image is 58x91 (don't ask why). The game seems to try to make it fit into a 57x91 rectangle. No way to have a "clean" icon then. Inconsistency #3 NAMING! The names of internal images are also completely inconsistent. Example: images for a button with the mouse over it can be either: <name>_Over, <name>_over, <name>_Hover, <name>_hover... A true nightmare. If you want to have an idea of how nightmare-ish it is, have a look at an extract from the sorted dump of HUDReplacer: There are plenty of typos, too. -- END OF TRANSMISSION -- Small "bug" report: Apparently, the images for the KAL editor are loaded when the editor is open, which means that if HUDReplacer only loads things when changing scenes, it doesn't load stuff for the KAL editor until changing scene after opening it. Maybe add a way to specify a list of images that must be loaded at the beginning of the game (loading, main menu, or something)? This can probably fix the problem. Also maybe do another build, there hasn't been one for the last patch and I can't compile C#.

N 5

It's Nazalassa here (8/10)

Version 0.2c is out! Changelog Added missing elements for subassemblies. Added KAL editor elements (KAL editor is complete now). Completed Kerbnet access window. Tweaked app_divider_pulldown_head_over (the orange bar above PAWs) so that it appears darker and less orange. (if you don't like it, tell me and I'll restore its previous state) Fixed DeltaV button being off-centered in flight. Screenshots: Note: the KAL editor likely won't be affected when you open it for the first time, if you have the dev edition of HUDReplacer, press 'q'. If you have the regular version, go to any other scene (tracking station, etc.) and then go back to the ship (or the VAB if it's where you were).

We're off by one, as the first post of this page should've been 4200 (but it was 4199). Therefore, 4214.

N 5

N 4

Suggestion for next version: add orbital trajectories, as well as Ap/PE markers, and an altitude display (and an AP/PE height display).

Yes, I will reply next... @Akagi I summon thee

Me neither, but I could see the top last time I tried.

N 6

N 6 New age!

N 8

N 10

Hello @some_failure! Welcome to the forums :)

Note from future self: with 256-analog computations (my analog adder, bus, etc.) we can write the numbers in binary from 00000000 to 11111111 (0 to 255) and then say that we represent them using two's complement. So we can represent negative numbers like this, for example KAL position of 192 represents -64. In this case it's fully compatible with my adder. btw, everything in the above post can be considered as "stock", as it should be loaded without problems by KSP. I don't know if editing the craft will break it, though. Requires experimetation.