Leaderboard

I realize it has been quite some time since I have posted a proper update. Unfortunately, right now I have nothing major to share that looks pretty. But, I have been dusting off the old tools and getting back to work on this. I've also been looking for ways to simplify and reduce some things, and I've sort of had a "Eureka!" moment that's going to allow me to combine two quests, eliminate multiple areas that I have yet to model, and just keep things simpler. I don't want to spoil all the details, but it's taken a burden off my mind at least. Some of you may be disappointed to hear about the reduction, but I don't want there to be bloated or unused space, which is what I am effectively eliminating here. I am really more interested in the quality of the mod, and an actual release. So in this case, less is more. On the modeling front, a number of things are getting an overhaul. The cantina is getting a face lift, and the street is going to be restructured. Most don't know this, but I actually had a second street module. I am combining both into a more condensed street area. The two-module version was too expansive and had too much wasted space. It was fun doing the outside areas, but it just ended up being a lot of empty space. I got a bit too ambitious wanting a Taris-plus sized planet. After the cantina and streets are re-configured, I am looking at only one more area to model from scratch before the area models are complete. This will be an indoor area that houses the gladiator teams as well as various vendors that would go along with such an event. After this area is complete, essentially the whole planet will be built. I still need to do some work on the gladiator arenas themselves, but luckily this will be fairly easy. Immediate goals are: Finalize Cantina Model Gladiator Row Finalize Street Area Connect all areas Work on Gladiator Arenas Longer term goals for this year: Simplify some quests Get quests implemented Alpha testing Thank you all for your continued support of this project. I know development is often spotty from my end, but I knew this was likely to be the case going into it. But if I keep on plugging, things will get finished.

Hello all, just as a quick introduction to me as this is my first post. I'm a game design student with an unhealthy obsession with Star Wars, I have something silly like 10000 or 15000+ hours cumulatively between SWG/SWTOR and all the other star wars games over the last 20 years. I started modding and programming on Empire at war making very basic mods for personal use only about 10 years ago as a teen but thats where my actual video game programming experience ends outside of stuff I've done in class or as assignments. I'm looking to expand my career portfolio and have some fun by making some mods for KOTOR/TSL. I've been familiarizing myself with NWScript and how things are handled in the game files and I still have a lot to learn. I'm a total noob as far as artwork and module design goes but I'm fairly adept at object oriented programming/scripting which is a skill I'd like to further polish through this endeavour, I'd also like to learn the aforementioned skills and start making models/meshes and levels. On an aside, I'd appreciate any literature/documentation/whateveryouhave that I can use for learning for any of the above and whatever else you might think could help me on my journey. Now that thats out of the way, here is the main purpose of my posting: I haven't been able to find actual definitions for the abstracts (or at least what I think are abstracts, you don't know what you don't know etc etc) in the Nwscript.nss in any of the files I've inspected in KOTOR tool ###from nwscript.nss### // 485: Create a Modify Attacks effect to add attacks. // - nAttacks: maximum is 5, even with the effect stacked // * Returns an effect of type EFFECT_TYPE_INVALIDEFFECT if nAttacks > 5. effect EffectModifyAttacks(int nAttacks); // 486: Get the last trap detected by oTarget. // * Return value on error: OBJECT_INVALID object GetLastTrapDetected(object oTarget=OBJECT_SELF); // 487: Create a Damage Shield effect which does (nDamageAmount + nRandomAmount) // damage to any melee attacker on a successful attack of damage type nDamageType. // - nDamageAmount: an integer value // - nRandomAmount: DAMAGE_BONUS_* // - nDamageType: DAMAGE_TYPE_* effect EffectDamageShield(int nDamageAmount, int nRandomAmount, int nDamageType); As you can see, the abstracts are here in nwscript.nss. I chose this particular excerpt because I'd like to 1. potentially add effects of my own that I could use for future projects and 2. Modify constraints on existing effects, namely the modifyattacks effect. As my first foray into this I'd like to increase the maximum on nAttacks so that I can give the player more options for increasing their damage. So. Are the definitions I'm looking for found in the engine itself or something? From what I can tell in my ongoing investigation of the opensource re implementation of the Aurora engine called Xoreos found here https://xoreos.org/doxygen/da/d48/namespaceEngines_1_1KotOR2.html this doesn't seem to be the case, but I also haven't been very thorough. I also understand that KOTOR/TSL are ran by the odyssey engine; not the Aurora engine though odyssey is apparently based off of Aurora. I honestly couldn't tell you what the differences between the two are and am hoping I could be informed on that front as well TL;DR Any information you have on how nwscript/c/c++ work or constraints on making mods for kotor/tsl and especially where I can find the definitions of the functions I'm looking for would be greatly appreciated. Thanks in advance!

View File JC's Security Spikes for K1 Security spikes are disposable items that give the player a temporary boost to their Security skill when activated, helping them pick more difficult locks. At least, that's how it's supposed to be. That's how they work on the Xbox version, and in KOTOR 2, but security spikes don't actually do anything at all on the PC version of KOTOR 1. The cause seems to be some sort of bug in the GUI that prevents security spikes from ever appearing in their intended slot. So when interacting with a door, there isn't an option to scroll from the Security skill to security spikes, as there is in KOTOR 2. The GUI was changed for the port from Xbox to PC, and security spikes probably got left out due to oversight. I couldn't find any way to resolve the issue, though, so I came up with two alternative options. Option A Option A replicates the security spikes' intended function as best as I could manage. They’ve been given an activate item property and appear in the non-medical item slot (along with stimulants and shields). When a character activates a security spike, they receive a temporary boost to their Security skill and proceed to unlock the nearest door or container. Apart from the boost, the skill check for the lock is the same as usual: 1d20 + Security vs. the lock’s DC. Security spikes are single-use and discarded whether the character succeeds in picking the lock or not; however, they are not used up if the attempt was impossible – if there wasn’t anything in range or the lock required a special keycard, for example. Regular security tunnelers grant a +5 bonus and security spike tunnelers grant a +10 bonus. Option B Option B removes security spikes from the game, replacing them with credits. The value is equivalent to the most you could get from selling the original security spike items to a merchant. Mission’s ability to create security spikes on the Ebon Hawk is removed. Submitter JCarter426 Submitted 02/01/2019 Category Mods K1R Compatible No  

That...depends. In C, you can't. In C++, you can overload a function, as long as the signatures, i.e. the number of parameters and their types, are different (internally, C++ "mangles" the identifiers, using a scheme that encodes the parameter types into the name). In NWScript, you can't either. The compiler wouldn't know what to do. When you write a script in NWScript, you use the compiler (for example, a modifed nwnnsscomp for Kotor, based on a open source reimplementation by the "OpenKnights Consortium" of the original NWN compiler, based on the work of Torlack who RE'd the stuff back in the day) to turn the C-like NWScript source (nss) into NWScript bytecode (ncs). Internally, the bytecode doesn't know much about the engine functions anymore. The compiler looks into the nwscript.nss file to look for the name of the function, and then counts at the index of the function within the file. I.e. if it's the first function in nwscript.nss, the second, the third, etc. That number it puts into the bytecode file ncs. So in the bytecode, you only have pushes onto the stack, for the parameters, that the compiler arranged there (and space for the return value), and then "call engine function 523". The game, when running the script bytecode, takes that number, then knows what to do, and which parameters it takes. I.e. with NWScript, you can't change the number of parameters, and the types, because that knowledge is hardcoded into the game. (Well, it's not impossible, just quite hard.) What you could, theoretically, do is add a new function to the bottom, then manipulate the look-up function in the game to recognize it. You'd still have to add the functionality itself, though. It's still hard, just slightly less so. (This could also be used to emulate overloading, by extending the compiler to map the overloaded functions onto later indices. Might not be worth the hassle, though.) We, err, don't have that implemented yet. It's not really that it's forbidden. It's just that you're setting yourself up for a lot of hard work and pain. And potentially failure, of course. I know, coming from me, who's RE'ing games for fun, and who has too many projects and stuff to do for 10 lifetimes, that's a bit ironic. Still, I still think the "best" way to resolve hardcoded things in KotOR is going over xoreos: getting xoreos in a playable and "done" state, so that improvements can be build upon xoreos. Not that this isn't a massive amount of work either, far from it, just that this opens up so many more possibilities. If you're adding a single thing to KotOR using the manual binary-hackery method, it's way harder to be sure you didn't miss anything, you can't verify easily when you continue to work on it that you're not breaking it, it's harder to integrate with other people's work, etc. You could instead do something similar, figure out how things for in the game and reimplement that in xoreos, bringing xoreos further along. It will not give you the gratification of having changed something in the original game as quickly, and still need to wait for other people to do similar things for other areas, but once it's all done, that's a far more stable base. At least that's how I see it. YMMV and all that jazz. And to be fair, I started xoreos low-key in 2010, and while there has been progress, it's still far from done, nearly a decade later. It is what it is.

In C/C++-parlance, these are called "function declarations". They declare the name and parameters of a function, so that the function can be called. (Additionally, you have a comment explaining the function, which is not strictly necessary to call the function but helps the programmer.) Yes. The whole functionality for these functions is inside the engine, inside the EXE. It can't be changed readily at all. Wrong. The code and documentation of xoreos show explictly that the functionality is within the engine. That's pretty much expected, yeah. These engine functions usually check the parameters to be within their valid ranges. The rest of the code expects them to be still within the valid ranges, too. If you suddenly violate this expectancy, a crash is the most likely thing to happen. What you are doing is most probably invoking what's called "Undefined Behaviour", and the program might actually do everything it wants to in such a case. Common joking examples include eating your grandmother or letting demons fly out of your nose. On a more serious note, the game might also not crash immediately, and just leave your game in a broken state (even carrying on in future save states), so that you might, for example, always get a crash in a later section of the game, or just not progress through the game at all. Because you're changing the game's memory to values the original programmers never thought about. Essentially, what you'd need to do is to check every single location in the game that uses the value you changed, and verify that it still does the originally intended actions. And if you want it to do something additional or different, you need to make sure that it still makes logical sense in combination with the rest of the code. In addition to adding the new functionality, that is, which in itself is a tall order. Frankly, I for one would disadvise you from going down that road, but it's your life.

It should, but all the security spikes currently in your inventory still won't do anything. If you remove them with KSE and then add them back in, they should be converted to the new kind.

Sithspecter, first of all, welcome "back" with news about your great project! I, like many, was really happy to read your update and frankly, I am also happy you are cutting content. I feel like Knights of the Old Republic (way more than TSL) did an excellent job at keeping areas nicely contained and focused and I am hoping Sleheyron will follow closely this game design and from your word, it does seem it will. I hope my next question doesn't sound impertinent but is Fair Stride still working on this with you or are you now the sole developer? Could you also give us an example (without providing specific details, of course) about your plan to simplify quests? Thanks and godspeed! Cheers!

Great to hear things are still moving along! Take all the time you need, SS. I'd rather have a great mod that took a few years to get out than a half baked one that was rushed

I am in no way skilled enough to really offer any meaningful assistance to that project yet but I'll keep studying and maybe in time I will be. Who knows what the future may hold. I'm disappointed but not surprised. Thanks for the reply! I'll do some research on cracking exes but thats something Ive never even thought about doing, though I doubt anything I'd be able to produce after the learning process would be in any way distributable to others. Might be fun for me to play around with on my own playthroughs though @Qui-Gon Glenn I'll play around with it and see if there's anything funky I can do. EDIT:After a solid few hours of shenanigans I have good news and bad news. The good news is I was able to isolate the address for nAttacks in the memory using cheat engine which implies that I can maybe find a way to locate related data using odbg for cracking if I get smarter. I never thought I'd try to learn assembly/machine code before but here I am. The bad news is that simply forcing the value to anything other than what it should be using cheat engine causes a crash as soon as you try to use any attack action. Which leads me to another question. Is there anywhere I can find debug/crash info? No matter what, I'm enjoying this process so if I don't end up with anything to show for my work then I'll still be happy and won't give up.

Unfortunately, I don't think anything you mentioned can be edited. Everything defined in nwscript.nss is all we have to work with as far as scripting for the game, and the source for that is hard-coded. You'd have to crack the EXE to do anything about it. Yes, xoreos is an open source implementation of the entire Aurora family, including KOTOR. Everything from Neverwinter Nights to Dragon Age 2. The open source part is the key point there, as it would theoretically allow for the sort of thing you want to do when completed. It's not exactly in a playable state yet, but it might be more up your alley. And I'm sure they'd welcome any assistance.

You should create two modular bits so that if someone has TSLRCM but not M4-78EP(or vice versa), they can still use your mod.

I remember years ago running through either the first or second one in the beta release. I actually liked your original design because there was no proper hangar - the ship was just there on the street and anybody could see it as they walked by. It was like the planet is so polluted and overdeveloped they don't really have the space for that or even care to anymore. Like Nar Shaddaa. Some of that wonkiness might've been due to your skill level at the time, but I actually liked that. I really like the new one too, though. It's by far the most polished and looks exactly how you'd expect one of the game's hangars to look.

If I can do it, anyone can. That said, I'm not that skilled nor do I know anything about modelling etc. If you want to learn how some stuff works then Real Rece's tutorials on YouTube are the most helpful I've ever seen for most of the basics.

1. have a Jawa Juice (it can be as dull as flat water or whatever you like) 2. Know what you like Set yourself a modest and specific goal (such as: "that armor is ugly, I have to replace it!" or "every toon has to look like Bastila or Carth!"): in other words, something you can see the end of such as recoloring, retexturing, changing something very specific in the game or adding an item to begin with and you'll be good. It will allow you to learn a few aspects of modding and how the game files structure work. 3. Explore: I started modding because my old computer back in 2003 could barely handle swoop races...I had to find a way to win! I didn't know anything about modding so one day I explored the game and its files, found the first version of kotor tool which was only a few months (if not a few weeks) old on LF, experimented like a mad scientist (i had no clue as to what I was doing) and found a workaround the swoop nightmare. Nowadays there are many tutorials but if you can't find what you are looking for, move to item 5. 4. Don't get lost Don't start with an ambitious conversion project that you'll never see the end of. 5. Ask questions What you think might be a stupid question> not asking and being stuck 6. Have fun (no explanation needed)