Leaderboard

Welcome! It's great to meet a fellow victim programmer! I'm unfamiliar with NCSDIS, so I read a man page. As far as I can tell, it produces an assembly-like output, DOT output, stack information, and control structures? My binary does all of that, too. 🤣 Not sure how NCSDIS helps here or can be integrated, but I'm interested in looking at it to see what I might have missed. The documentation is accurate. It says the JSR instruction doesn't modify the stack. However, before you even get to the instruction description the section "Calling Subroutines and Engine Routines (ACTIONS)" states that "Invoking subroutines [Amano: that means JSR] or engine routines [Amano: that means ACTION] is done basically in the same manner. Arguments are placed on the stack in reverse order. The call is then made and the callee removes all the arguments from the stack prior to returning." So, somewhere inside the called function is where the arguments are popped. This makes sense given that NCS was patterned after machine code, and the most common calling convention at that time, stdcall, had the callee clean the stack. No worries, this is my thread to discuss the development of whatever this will be named. I'm not on Discord, but I will send you direct messages here if I run into any issues. You can also subscribe to this thread in case anyone else replies, particularly from DP, Salk, or DrMcCoy since they directly work with NCS files. 😊

Hi @DrMcCoy thanks for “@ing” me - I rarely post on forums but this has given me motivation to do so I’ve made the GitHub repo for my implementation of “ncs2nss” public at https://github.com/lachjames/ncs2nss. There are a few things to know: - Firstly, it’s a work in progress and isn’t perfect. However, all the fundamental components are implemented and the code runs most of the time without error (as in runtime error - it may well make decompilation errors) - I would be not just happy but “double plus happy” if this were ported into C++ and included in xoreos-tools - I say in the readme that one of my goals is to demonstrate how this can be done in Python (using tools I’m familiar with such as rply) so others can implement the same (e.g. in xoreos-tools). I haven’t put an official license on it yet but like DrMcCoy I’m a big believer in open source so consider it open with attribution. - My version works with ncsdis and I encourage you to do the same (and include your improvements in xoreos-tools) as one perfect library for disassembly is better than two that work most of the time. This is just my opinion and I don’t mean to diminish the work you’ve done on the disassembler (I’m sure it’s great, just like xoreos-tools is great) - I just feel that if we all merge our efforts we can make a better final product @DrMcCoy feel free to post/copy anything from our conversations if you’d like. I’m an open book; just didn’t want to annoy you on GitHub by cluttering up your inbox with posts on issues In particular, let me copy-paste my latest message to him on Discord below: *** BEGIN QUOTE *** Hey so I've realized that this heuristic analysis is not reliable enough to be used properly, but I came up with another solution which works every time. The problem is that the Skywing documentation is incorrect, and JSR does in fact work just like ACTION in that it modifies the stack pointer by popping off arguments. It doesn't push on a return value though (if there is one, space for that must have been allocated by the caller function before calling the callee). Perhaps what they mean is that the JSR does not do anything "intrinsically", but the function calling convention appears to be that functions pop their own arguments (which is more reasonable than making the caller do it every time; this is something I've actually taught before in computer science classes). In any case, what you can do is the following (after constructing a call graph): For each subroutine in the call-graph, iterating with DFS reverse post-order traversal: 1. If the current subroutine is part of a cycle in the call graph: 1.a. Collect all the subroutines in the cycle 1.b. Trace both the final stack pointer and subroutine calls from every possible path from the start block of each subroutine to a block with no successors. 1.c. For each of these paths, we can form an entry in a system of simultaneous equations, where the final stack pointer is on the RHS and the subroutine calls are on the LHS. For example, if a path through subA calls subB 2 times and subC 2 times, and the final stack pointer is -8, our equation would be "0a + 4b + 2c = 8". 1.d. Solve this (potentially overdetermined) system of linear equations for a, b, c, ... which are the number of arguments for subroutines A, B, C, ... respectively. 2. Otherwise, compute the number of arguments as per usual for non-recursive functions. Can then also determine if there's a return value after finding the number of arguments. One issue with this is the problem of vector/struct arguments. This method will tell you the size of the stack space which is popped from the stack after calling each subroutine; however, it does not tell you the structure of said space. However, this is easy to calculate once you know the number of arguments - when you call the function in another subroutine, you can use the state of the stack at that call to determine the types of the sub's arguments (including how much space they take up). *** END QUOTE *** Don’t mean to take over this thread so I’ll make a new one if you want. I’d also be more than happy to talk to anyone on discord about this - feel free to message me (Lachjames#6269 - if you’re on the DS discord server you should be able to message me).

Hello! I'd like to ask your opinion about this item's restriction. Currently it's restricted to Light Side but not to Jedi. The description speaks specifically of being an item created to celebrate Guun Han Saresh's acceptance into the Order. Do you think it would make more sense if only light sided Jedi could wear it? Thanks.

Hello, ebmar! That is exactly what I had done locally but I wasn't quite sure. Especially considering that the polar opposite item (Tulak Hord's Mask, which also looks identical in the original game) is restricted to Dark Side but not Jedi. I hope others will chime in and give us their opinion as well. Cheers!

I think that's a great idea for consistency's sake. I mean, it does make sense after all. Perhaps adding Jedi Defense to Feat Required field on the item's template/UTI would be the best approach for that.

Hi I've spent the last month working on a new decompiler for NCS code, and I'm ready to share my work in progress with you all. It works properly on many scripts, but there are still situations where it produces incorrect code (but the issues are usually relatively minor). I started this project both because an updated, open source NCS decompiler would be useful to me, and also to learn more about decompilation theory. It's a fascinating topic - I plan to create a YouTube video series on decompilation, using this code as an example. It's also meant to be a reference for others who want to implement an NCS decompiler for themselves (e.g. in C++ for the xoreos-tools project), or for those who want to learn decompilation in general - although NCS is a relatively simple language to decompile (for many reasons, discussed in the GitHub readme), I use very little in the way of "heuristics" and have based my algorithms mostly on the famous 1994 Cifuentes thesis "Reverse Compilation Techniques". I'll keep you all updated if you're interested in any educational content I produce based on this project. Relative to DeNCS, my code has some new features (some implemented fully, some still in the works), including: - Detecting if-else if-else if-...-else chains and not using nested ifs (done) - Doesn't have any problems with ACTION assignments to global variables (DeNCS fails on this, which is one of the main reasons some K1 scripts don't work in DeNCS) (done) - Handles recursion gracefully using a technique I came up with (which I believe might be novel) (WIP but mostly done) - Detecting includes and using the source code from the game's NSS files rather than the decompiled code (WIP) It works quite well, but it's not perfect yet and there are issues (take a look at the GitHub README for more information). Please be very careful if you want to use this for your mods, and (if possible) decompile scripts with the original DeNCS as well to check for consistency. If in doubt, I'd trust DeNCS over my decompiler for now. You can find the complete source code on GitHub at https://github.com/lachjames/ncs2nss as well as instructions on using the decompiler if you'd like to give it a try. I'd be very grateful for any suggestions or issues anyone would like to raise I'm aware that other decompiler projects are currently in the works, and I'd be more than happy to work with anyone who would like to work with me. I've licensed the code under GPL 3.0; my understanding (I'm not a lawyer) is that you are welcome to use the code for anything as long as you open source that code too. At the very least, this is my intent. This is the same license xoreos-tools uses, so it seems reasonable. This project relies on xoreos-tools for disassembly; Windows binaries are included in the xt/ folder (but I intend to remove this before any official release, or at least work with @DrMcCoy to make this automatically update to the latest version of xoreos-tools).

You might want to look at this if you haven't already - https://deadlystream.com/topic/5992-tpc-compressed-texture-transparency-alpha-blending/

Never played either of the Dark Forces games, but I know some of the story from those two games. I do have Mysteries of the Sith and intend to play it one of these days (once I get newly-discovered KOTOR and KOTOR II out of my system). 10 years ago, Academy was my favorite, and while I still enjoy Academy...Outcast is my favorite. MIssions in Outcast flowed together into a smooth story. Lack of customization actually worked in Outcast's favor...developers could tailor AI/environments on each level to be better matched against Force powers/weapons Kyle acquired as the game progressed. (Seriously...the bacta supplies drop once Kyle masters healing...that's not a coincidence!) I'm just amazed at how many details I still pick out to this day...this game was just designed so well. It also helps that the Quake III graphics hold up decently well. I would love to play the Dark Forces games, but I'm not sure if they'd work on my Win10 laptop. (Don't have it near me or I could give specs for the graphics card. It's from 2013, so not sure how problematic the hardware might be.)

The TPC texture format contains a floating point number in its header that we refer to as 'alpha blending'. It appears to be critical when used with DXT5 compression. This tutorial will try to help you use this feature properly. What is alpha blending? Alpha blending is not a direct 'opacity' or 'transparency' factor. It is only relevant for non-environment mapped textures that contain alpha-channel image-based transparency. For example, semi-transparent signage, mostly transparent windows, ghosts, etc. The best description I can give you for what alpha blending is: TLDR: alpha blending is not object opacity. It hides any mesh behind the textured object that has opacity less than tpc alpha blending number. Set it to 0.0 when using texture alpha channel as transparency. The meshes that will be hidden include any mesh that may be using alpha channel solely for environment mapping. Let's see how this plays out in practice with some visual aids. Each figure uses a TPC encoded version of the K1 Manaan Overhaul semi-transparent texture for the Sith Embassy signage. Transparency of the sign is right around 50%. Figure 1. TPC with alphaBlending set to 1.0 With alphaBlending set to 1.0 the only thing that shows through the sign is the skybox itself. This may be some kind of depth buffer test to make sure that something always blends through, which, in the 1.0 case, leaves just the most distant mesh, the skybox. Figure 2. TPC with alphaBlending set to 0.9 This seems to be the critical shot. With alphaBlending set to 0.9, lma_wall11 is showing, while lma_wall09 is hidden. lma_wall11 is 100% opaque, 0% transparent. lma_wall09 is 85% opaque, 15% transparent. So because lma_wall11 opacity > alphaBlending, it is shown, while, for lma_wall09, opacity < alphaBlending, so it is hidden. Figure 3. TPC with alphaBlending set to 0.5 In figure 3 we can see that both lma_wall09 and lma_wall11 are showing because their opacities are both greater than 50%. Figure 4. TPC with alphaBlending set to 0.0 This looks exactly the same as figure 3. Wait, isn't that weird though? Why can't we see the other sign through the first sign? It's opacity is 50%, which is greater than 0.0... Figure 5. TPC with alphaBlending set to 0.5, reverse viewing angle Just by looking through the sign in the opposite direction, the signs in the background now are blended through. This is showing a couple things. First, it seems that alphaBlending doesn't actually control instances where the same texture is behind itself. Instead, it appears that there is some kind of directionality at play. I haven't figured out what determines the direction of blending. I investigated whether it was the faces that appear earlier or later, but that didn't necessarily seem true. Using alpha blending The game's vanilla textures use all kinds of different values from 0.0 - 1.0 here. I do not fully understand why or how they have come up with a lot of their alpha blending values. In my testing, it seems like if you have a semi-transparent object, you set this to a low value, 0.0 or 0.1, and if you have a non-transparent object, you set this to 1.0. The important thing is that you do not think of alpha blending as the transparency or opacity of the object itself. If anyone comes up with better guidelines for setting this value through scientific testing, I will be happy to update this post to reflect the improved guidance.