ndix UR

Here are some screens. Working on an info file etc. Also, just as a side note regarding the giant duplo button issue. I actually see those as outlet covers, not buttons. The idea is that they would roll over, revealing the ports where droids would connect to the console. Also where the security spike would get used or whatever. In the original texture they seemed to be actual port outlets, I just liked the 'port covers' approach a little better. I guess I could have made one of them rolled open to make it explicit ...

i tried (for science). there doesn't seem to be a font or text changing capability built into the 'hilight' functionality, and basically the only class of problems I'm capable of solving w/ a hex editor are changing arithmetic calculations where the math and/or constants are inferable. that said, i believe w/ the default functionality you would be able to have a texture appear as the 'fill' in the button when you mouseover it. i would have to play with it more to know for sure, but you might be able to use this to have the aurebesh appear above/below the text (and make the new fill texture the same color as the text to have the text 'disappear'). kind of a low rent hack, but so far that is the best i've come up with to implement something like that. TLDR: it looked good, then it looked bad, now it looks maybe. not giving up on menu rescaling. some reasons for hope. Luckily, that might just be enough to get through this menu rescale. I have more to report on this topic. So, I wrote a script which scales the entire UI to any given resolution via edits to the GUI files. It basically converts all the GUI files to XML, finds all the Extents (as shown above) and scales them up based on the root extents in each file, then it converts back from XML to binary GFF, then you copy those into Override/. This works ... somewhat. Visually, it's awesome. There's no crashing, and the UI is fully navigable via the keyboard. What I have found though, is that there are 3 different classes of screens you get, in terms of issues. equip.gui, inventory.gui, options, many others: these all *look* fine and correct when you scale them up, however, the button 'hotspots', or, where the game thinks the mouse should be to be 'over' a control, go off. Specifically, the game thinks the buttons are lower and further right on-screen than they are. It gets worse when you scale more (just a bit off at 800x600, way off at 2560x1600), so this is going to be some kind of multiply/divide issue maybe, but I have not found it yet so can't say. loadscreen.gui (possibly (2) others): when you scale these up, the game moves your up-scaled loadscreen to the same upper left position of the tiny loadscreen. making it mostly off-screen. math-wise, this comes down to a "something minus 640" and "something minus 480" hard-coded in the executable. I was actually able to fix this issue through hexedits, so now my loadscreens work as expected at high-resolution. mipc*.gui and mainmenu*.gui: these are the files that have numerous 10x7, 8x6, 16x1 etc versions. as such, I think because they were designed to support different sizes, they "just work." You can edit the extents in these and it will all work fine (assuming you correctly scale up the extents of everything in Controls after you do the root tGuiPanel extents). top.gui: these are the top buttons in in-game menus. this file has special issues. i think it might be more like loadscreen.gui, especially because it changed (but not yet correctly) when I fixed the loadscreens. If I can make progress on the first class of issue (the hotspots) ... after that it will be time for testing on some other people's executables and/or setups. Anyway, lots more testing and tracking to do, and it's not an easy problem, but there might actually be hope for this. Which would really be great, because this issue makes playing Kotor1 from a couch with a controller extremely difficult. And, of course, actually seeing the detail (on the equip screen) in those beautifully hi-res item icons for the masks (thx xander) and HQ blasters is super awesome!

hey ... so ... this just happened: i tried hexediting, but that was a no-go (although i did find a replacement that crashed the game at the 'right' time). i had to basically resize and move every gui element in mainmenu.gui in the k-gff editor. i also copied my mainmenu.gui to all the other mainmenuXxY files, like 10x7, 8x6, etc. (in Override). now i am moving on to some more difficult (and important) menus in-game (equip, map, etc), but i just wanted to make sure that nobody else has already solved this? i use clonegizka's stuff for TSL, which is super-great, but man, in TSL it's just a stretching issue, in Kotor1 it's an 'unplayably tiny' issue. so, at least for me, this is a pretty big deal. i am taking notes on what each element in the GUI files is also. if people are interested i can post more info as it develops. especially because this stuff is not going to be easy to do for multiple resolutions, and the only resolution i can test is 2560x1600, a weird 16:10 resolution that's not going to be that helpful to anyone else ... assuming no gotchas and i actually continue with this, i will need some 1080 testers sometime, because that seems to be a common play resolution. if any of you guys who tested this stuff know of screens that seem like they definitely won't work, please let me know at your earliest convenience so i can try those ones early in the process. i don't really want to get 80% into this and find out that 20% of it is impossible ... for science, this is using the GOG release in wine on mac os 10.9. here's another link that's easier to full-size:

alright, I've got a version I'm pretty happy with ... unless people have major issues and/or easy improvements, I'll probably call it good. Console2Kb2.7z I'm definitely happy to add an info.txt and release it on the site, that would be great ... perhaps I will reach out to I used mdlops 0.7a2 to de/recompile my models ... does someone with more experience know if that's a reasonable version to have used for this? It definitely seems to work in-game and looks 'fine' as far as I can tell, but, having read a lot about mdlops ... the versions seem to each have their idiosyncrasies, and I don't want people to have issues if it were to become widely used. Also wondering whether there's any merit in releasing the non-animated version alongside the animated one... Thanks to all testers and commenters.

Yeah guys, sorry, I am close, just been doing some life things and working on other skins and modeling tools ... I also took a run at trying to upscale the kotor 1 menus (via hexediting) because they drive me insane. (but let's not get off topic w/ that...TLDR, it didn't work) I am going to try and finish this out today though ... I'm hoping this next round of update is going to be 'the one,' because yeah, as DarthParametric said, not sure how much more time I want to spend on this vs. other things. I don't have the texture on me right now, but I can say that I've redone the front base (under the panel), given many of the metal surfaces more/better texture, removed the Arabic numerals from the screens, and changed up the text content a bit. I tried changing up the light pattern but I don't like what happened, so that's the one major outstanding thing right now. I don't need it to be perfect ... just ... better. oh ... and I definitely see the hat now, LOL

Thanks for the details on how to capture stills, which I had not gotten working yet either, but I was actually talking about video capture there like SithHolocron did, to get the animation motion stuffs. I agree with you that the area underneath the control panel is one of the most 'unresolved' parts of the whole thing. I have taken a few steps to try and fix it, but they haven't really worked yet. I'll try some more things. Yeah my globe animation was kind of a nasty hack, it looks surprisingly good in motion considering how weak it is. When I embarked on this adventure I was mostly just trying to really stick to what was being implied in the original texture, kind of a basic upscale. It has kind of gone beyond that now, and I think I can find time to improve some of the bits. There's some good inspiration in those 70s-esque industrial panel images you posted. I assume it is mostly the controls in the center 'main control panel' part that you are thinking of? @Kexikus, thx I am going to work on roughing it up a bit more.

I spent awhile trying to do a screen capture ... buut ... all the screen capture utils either crashed or dropped the game to 0 FPS, so that's a no-go. I'm going to try to finish it this week, so I'm attaching a beta version for comment. Console2Kb1.7z The things I'm already planning on working on and could probably benefit the most from specific comments: the light bar blinking patterns, the large glowing buttons, and the metal textures. The light bar blinking patterns ... I find the one on the right more successful, albeit much simpler. The only kind of issue is that it is mainly an on/off blinking, which I also kind of did for the large button on the right (but in opposing phase, maybe I should actually make those blink together? like they are actually indicating the same thing?) The metal textures aren't terrible now but I think they can be improved by emulating some of the game's other consoles a bit more, so that's my plan. The large glowing buttons are pretty low-detail in the texture, so I don't want to do too much to them, mainly wondering what colors I should be using there ...

OK. i think it might still need some refinement, but all the heavy lifting is done. i've kept my animation limited to the left touchscreen, the two lightbar panels, the two large light buttons, and the two secondary blue monitors. They are all being animated from a single 3x2 TGA flipbook w/ 350x350px 'frames'. I added 0.9 neutral self illumination on the light buttons, and .2 neutral self illumination on the lightbars and screens. I added a bit of geometry for the light buttons so that they are now slightly raised. The neutral illumination thing is great because I'm not 100% sold on the buttons, I changed one to red and one to orange. I am definitely feeling that a bit, as some things kind of want to be at 6 fps while others are a lot better at 3 or less. currently everything is running at 3 fps. I did as much as I could to break up/stagger the repeats, which I feel like is working pretty alright. At least for me it is testing pretty well ... immersive without being fun house eye-grabbing. The lightbar animations are really the ones I am least sure about at this point ... I might need to revisit those to be more like the thing redrob41 posted ... I've given it a round of aging, but it might not be quite enough yet ... especially on the back side. @Malkior thanks for the notes on metal texturing ... I haven't been able to get good looking scratches really, but adding some speckling and other things has been helpful. So yeah ... not exactly sure how to proceed from here ... I've got a 7z I could PM to anyone interested in testing ... or should I just post it as a beta or something? Thanks again for everyone's help & comments.

I just spent waaaaaaay too long debugging MDLOps and I have a fix for you! Setup: working on character models with blender using neverblender import/export Symptom: recompiled characters don't have shadows in game. if they are playable NPCs (handmaiden say) and you enter combat with them active, the camera freaks out, doing a combination of moving inside the model's head and orbiting them really closely as if some kind of collision were happening. Cause: neverblender exports models with classifications in ALL CAPS. It took me *so* long to figure this out. I tried just about everything else (returning weights, tverts, faces, orientations, all things neverblender changes on a simple import/export). Solution: in MDLOps.pm change line around 1795: } elsif (/\s*classification\s+(\S*)/i) { # look for the model type $model{'classification'} = $1; to } elsif (/\s*classification\s+(\S*)/i) { # look for the model type $model{'classification'} = ucfirst lc $1; This is similar to how keys are used in the nodelookup hash. Anyway, I hope this will save some blender character modders some grief somewhere down the line. Thanks for maintaining this essential software!

i figured out how to get blender to tile the texture image in the UV editor. Just click 'Repeat' on the 'Display' panel under 'Coordinates:'. That would have really helped me 2 days ago . I actually understand the animation flipbook stuff pretty well, I've made animated EH screens and Telos billboards for my personal game by editing people's excellent existing stuff and figuring out what they did in the TXIs while I was there. Yeah, if I go down the animation path I will have to go crazy with it, probably all 4 of the extra monitors (agree w/ you on the 'not the main one' thing), pulsing the pink light, and different sets of lights illuminating on the 'orangered-yellow-orangered' light bar. I think I could probably live with that. In terms of the pink color on the light ... I think I might agree with you that it might look better red. Maybe a red somewhere between the red on the 'main control panel' and the orangered in the light bar. I chose pink because that's what the the original texture seemed to maybe have. Right now I'm trying to figure out how to change the pink light into an actually light-emitting separate mesh. I'm guessing that involves setting selfillumcolor in the ascii version of the model before recompiling ... the only other question mark is how to actually apply a material in blender ... I would probably end up cheating and just export to ascii, set bitmap, and then reimport. doesn't sound too optimal ... Also I am going to add some sliders to the side super plain panels as you suggested. Looking hard at the low resolution model, I feel like the original intent might have been that the raised areas on the panel (which I made into touchscreens) were going to be holo-emitters ... there's a kind of blurry linear effect on the side panels in the original that is making me think that. I have no idea how one would even begin to implement something like that, which is maybe what Obsidian concluded too. oh well, I'll leave that for the next person... Edit: @SH just saw your post. We are totally on the same page w/ the light bar animation, and I agree with you on the other one too. In terms of matching the surroundings/aging it up a bit ... the only surroundings I found are M478 ... is that what we're talking about? I agree with you that they kind of stood out a bit more than I would like when I was looking at them in game.

@xander2077 thank you so much for those instructions. so. helpful. just wow. Thanks to your advice I had no trouble at all with the UV remapping. Blender tried to make it difficult, but I was able to persevere. I also found some weird things in the stock UV map for that model. There were 2 chunks of the model whose texture mapping were well outside the texture area. I have a screenshot ... though it is a little hard to interpret, check it here (hard to interpret because blender is showing the entire UV map shifted off to the left ... which is weird and I've never seen before, still though you can see the two regions that are way outside the texture ). Is that a common thing for the game designers to have done? I could tell that one of the mismapped regions was maybe at one time supposed to be pointing at the extra screen info that was lurking unused in the lower right corner of the texture. This prompted me to add two "new" screens to the texture. They are the areas on the raised parts away from the main controls. I made them into touchscreens ... hopefully people will be ok with that. The one on the right has an on-screen keyboard up and some finger controls over a pipe network. The left touchscreen has an orbit control and some gradient readouts over a data rendering of space debris. I also broke out the right secondary screen and flipped its UV vertices. So no more mirrored (or repeated) text, and all 4 of the 'extra' monitors are now separate within the texture. Here's how it looks now: I also tested the recompiled model in-game, and it's working. I've also applied noise and added a static scanline overlay to all the screens. The only thing it's missing now are potential new meshes for glowing (maybe animated) lights and/or maybe animated screens. Whew, I need a little break though. Any and all feedback welcome.

@LiliArch you are totally correct about the Win32::Autoglob thing ... sorry, I was talking from memory and not looking at the code! Yeah, without Win32::Autoglob, on Windows, you wouldn't even be able to easily figure out whether you were supposed to be in command line mode or not. According to perl docs the if would look like ... if ($^O eq 'MSWin32') { # code that assumes Windows use Win32::Autoglob; } Personally I would probably do... if ($^O =~ /^mswin/i) { use Win32::Autoglob; } Which checks that the version string 'starts with mswin' (case-insensitive). The only reason I would do it that way is to potentially avoid breaking if Windows ever starts reporting itself as MSWin64 (while still providing Win32, the perl library) or something crazy

Thanks to everyone for the feedback and suggestions. First off, I'm going to work on adding appropriate noise to the surfaces. Next, I think i'll add the scan lines xander2077 suggested (just still for now). Then I'll start trying to correct the model to fix the mirrored text issue (which is definitely annoying). I knew I was opening a can of worms by introducing text ... but I just couldn't help myself. And yeah, the original texture was so tiny ... I think it was a 256x256, there was definitely no text, just a teal smear with some blue around it. I am thinking that the UV inversion on the right monitor should be more approachable for me. Basically all of the modeling activities being discussed here are things I haven't figured out how to do in blender yet . Challenging, but that should be a good thing. Hopefully the UV remapping stuff won't be too hard to figure out ... I'm just a little worried though because while I was working on the texture, blender was having an issue with UV mapping that I've never seen before ( I do really like the idea of making a separate UV island for the left/right screens, so I might try that. Part of the reason I like the idea of keeping the screens in this texture is because there is a huge amount of wasted area in it. The original texture even includes an additional screen-like bit in the lower right that seems to be unused as far as I was able to tell (in my texture it is just a flat gray spot right now). Would it be possible (without adding meshes) to make a separate island for the main screen such that the main screen would not have to be two symmetrical halves? If I can't figure out the UV remapping I suppose I'll just have to replace the text with something more symmetrical... Once the screen issue is worked out I'll try the new meshes for button glow ... although, now that I think about it, I'm not really sure I understand why and how new meshes relate to adding glow? I'm assuming I would be adding some envmap to the new mesh textures which would make them glow ... but since there's no envmap on the whole console, I could just do it at that level and make the glowing bits of the texture semi-transparent, right? I understand that adding meshes for some of the button and light features would make it look a lot better from different angles and whatnot, just not quite how it relates to the glowing effect. Thanks again for all the helpful ideas and answers. I'll let you know how it goes.

@SithHolocron, I have a 2K retexture I would be willing to give you (and anyone on the site) for anything you (or they) want to do with it. Here's what it looks like right now as a low quality JPEG. Let me know any changes you need (I haven't done much 'noising' on it yet) or want and I can do that and eventually send you a full quality TGA. Also I am a total site noob, so if you can tell me how I'm supposed to transmit the 17M TGA to you, that would be awesome Edit: I made this myself with no outside resources or inputs, but it does use the aurebesh font.

Yeah, so, the fact that MDLOps is designed to work on the command line is why it is so easy to fix for command line usage on other platforms. The problem with how it is currently written, is that it requires Tk & Win32 to be present ... even when you are not using them. Win32 is a non-starter and has to go (on non-Windows platforms), and Tk I just don't feel like installing (because I don't want/need it). I really do love MDLOps as a unix command line tool ... when I was recompiling the entire KoTOR weapon model overhaul to use in TSL, I only had to run two commands: mdlops *.mdl and mdlops -k2 *-ascii.mdl and *boom*, 70+ Kotor1 models recompiled and ready to go for TSL. Thinking about using a GUI for that makes me groan (although a featureful one wouldn't be too bad). I just realized that there's an even easier fix, which is to just move the 'use Tk...' and 'use Win32...' lines into the actual usegui = yes block. Sorry ... code. That would make it still useable as usual on Windows while also supporting command-line usage on other perl-enabled platforms.

I am doing the same kind of workflow as you, but on a Mac rather than a Linux machine (both are unix though, and I use a lot of linux). I recently switched from using the MDLOps 0.5 exe that ships w/ Kotor tool (in a wine command shell) to using the 0.7a2 perl code. I am also using Blender w/ newest neverblender for modeling. Because I wanted to use mdlops on the command line the first thing I did was pull out the Tcl/Tk stuff, and of course the Win32 dependency. I haven't posted it yet because I want to actually refactor it properly so that the Tcl/Tk and Win32 stuff is in a separate file (software engineer hat), but I've also gotten bogged down trying to fix some of the weird errors mdlops has and adding features to make the models work better with Blender. To make your own quicky fixed-for-unix version, just open mdlops.pl and delete lines 190-509 (usegui = yes to MainLoop), 540-543 (sub Tk::Error), and 1141-1152 (sub browse_for_file). Also remove the 'use' lines at the top for everything Tk and Win32 related. Make sure you copy or symlink MDLOps.pm into your perl lib directory (get a list using: perl -e "print qq(@INC)" (best practice would be to put it somewhere under 'vendor_perl' from that list) )

I know this is an old thread but I just found it because I had the exact same problem with the HKs (and some other body models I am working on reskinning) and was able to figure out the problem. At least for me, the 2DA edit solved the problem ... but only if you use all caps in the envmap column. So "CM_Baremetal" as in the posted screenshot does NOT work, but "CM_BAREMETAL" does. Hopefully this will save someone some debugging down the line. I also tried for awhile to set envmap to different values to get it to accept the TXI file info, but no dice. FWIW I am running the game (and Kotor tool) via wineskin on a Mac and don't have a Windows box to test on.