Leaderboard
Popular Content
Showing content with the highest reputation on 06/02/2018 in all areas
-
2 pointsI have asked DarthVarkor to make a little video so we can hear the female Darth Revan lines along with some action. He hasn't made it yet because I've only just now sent him the sound file. (No rush, DV!) My intention is for us all to see the video at the same time, including me. I've given him some suggestions on shots but he'll have final cut. I received a different voice sample for feamle Revan from someone else which was interesting but I'm hoping that I can convince her to try out for Jett Darklighter. Fingers crossed!
-
2 pointsYeah, it seems to treat pretty much any non-word-character as 'whitespace' for the purpose of word-separation for title(). It's like they used [^\w]\w as a regular expression to match the start of words. It even treats numbers as word breaks! I like a couple things about Python... this is not one of them. >>> 'blah.blah.blah'.title() 'Blah.Blah.Blah' >>> 'blah-blah.blah'.title() 'Blah-Blah.Blah' >>> 'blah$blah.blah'.title() 'Blah$Blah.Blah' >>> 'blah55blah.blah'.title() 'Blah55Blah.Blah'
-
1 pointI had to redo one of my videos as I screwed up the audio on it (the Bounty Huner one) and I thought I may as well point the folks here to them in case they haven't seen them. Examples of the LucasArts Golden Guy Examples of the LucasArts Golden Guy, Part 2
-
1 point
-
1 pointI discovered something a bit odd. When I put the attached sound file in-game and get into a firefight, the sound modulates! That is, its pitch changes shot by shot, alternating between 2 or 3 pitch-variations. Does Kotor actually process sounds dynamically and I only notice it with this one sound? Or, more simply, does it have a built-in modulator to spice up the sound of combat, and there is something about this .wav file that makes the modulation uniquely distinct? Or third, am I insane? heavy_blaster.wav
-
1 pointI did some messing around in MDLEdit and also took a look in KOTORMax. The last time I worked with this stuff was long before we could properly import or edit these, and back then I did some edits like making the blue lasers bluer and making yellow and green variants. It was interesting to take a look at them again with the new tools. So, it appears that only the red lasers really make use of the light color. Of course the light is white for the white lasers, but it's also white for the blue lasers. Only red has red light. Also, because the color is animated, I'm not sure how to edit the color in MDLEdit. I believe it's the colorkey controller, but I didn't try it. I used the white lasers as a template for my yellow and green ones and thought they looked decent as is, though I might fiddle with it at a later date.
-
1 pointYou can edit it with MDLEdit. The controllers you want to change are color for the light and colorStart, colorMid, and colorEnd for the emitter.
-
1 pointThere's also a light as well. There's are two animations, the default one which has the light turned off and the particle spawn rate set to zero, and the firing one which sets the light colour and fades it in and out, and also sets the particle spawn rate.
-
1 pointThe models are VFX emitters. The colour is specified in the emitter settings. The texture is an alpha mask for the particles it emits.
-
1 pointLike I said, you don't have to create it from scratch, you just use a modified copy of the original. Here: https://www.darthparametric.com/files/kotor/k1/[K1]_PFHA03_ebmar.7z Here's the vanilla head model, along with an edited copy with a unique filename and unique texture name. I've included the ASCII (decompiled) models so you can see what was changed, and in case you want to make further changes yourself, as well as the supermodel if you make changes and recompile. You can use MDLEdit to do so.
-
1 pointYou might want to have a look at this - https://web.archive.org/web/20150925093208/http://www.lucasforums.com/showthread.php?t=168268 Although you can ignore the hex editing bit, assuming you wanted to go that route. The new model tools should mean that is no longer necessary.
-
1 pointYou can use that head. If you want to use it straight vanilla, just set the normalhead value in the added appearance.2da row to whatever the heads.2da row ID is for that head. If you want to use a custom head texture, you'll need to create a custom named copy of that model and point it to your new texture. It's a fairly painless procedure. Then you add that to heads.2da and set the normalhead value to that.
-
1 pointThanks, guys! The move from stereo to mono on the suspect .wav files did the trick after all.
-
1 point🐍 That sneaky hungry snake strikes again. Bad snake! Baaaad snake! Quick! We must feed it more variables, so that it might be tame again.
-
1 pointIn K1 in order to use a custom head texture you must create a new model for it, unlike in TSL where you can just specify a texture override in heads.2da. So even if you don't want a physically different mesh, you still need a custom model that points to your new texture. For appearance.2da you can control what body models are used, so even if you don't want actual custom meshes/textures,. you can still have the appearance use any body model you want, regardless of what equipment they are actually wearing. For example you could equip them with heavy armour, but have their appearance be a Jedi robe. As to the UTC, that's the simplest part. You just find the UTC in the appropriate module in KTool, and, assuming your edited 2DAs are in the Override folder so KTool can see them, open the UTC in KTool's editor and choose the new appearance from a drop-down menu, then save it. In the case of K1, you can typically just put the loose UTC in the Override folder, because they gave them all unique names. Unlike in TSL, where they use generic UTC names that cause clashes between modules and thus must be packed into MODs. Of course if you want to publicly release something, you'll need to create a TSLPatcher setup that will dynamically create and inject your changes to any pre-existing files if necessary, rather than just dumping pre-edited stuff in the Override.
-
1 pointIt's the same routine as for any other unique NPC. Add a new heads.2da row with a custom head, and a new appearance.2da row that points to the head row ID. Specify custom meshes/textures in either/both 2DAs as appropriate. Edit the NPC's UTC to point to the new appearance row ID.
-
1 pointIt is possible to have .WAV Sound FXs [Force Powers, characters action such as their reaction when they attack and getting hit] above 100KB to works in-game. I have them working in my playthrough seamlessly. Try to make sure the end-result channel is in Mono with about 352kbps to 705kbps of bit rate just to be safe, and not in Stereo [you will not have them working on Stereo even if they have 1KB size of files I believe]. I hope this helps I am sorry DP, but I can't make it work. Excited with the possibility- I did like what you said; exporting the project straight to two (2) .MP3 files- both 128kbps and 320kpbs for compatibility test, then convert their sample rate to 44.1KHz with Stereo channel using an audio-converter. But them works to no avail 🍃
-
1 pointHah. Damn python, trying to be clever. Apparently when you call 'title()' on a snake-case string, it capitalizes every part. So 'Billboard_to_Local_Z' becomes 'Billboard_To_Local_Z'. For the non-programmers out there, that's not what most languages do. Normally it capitalizes the first letter, or the first letter of every word separated by whitespace. Thanks for the report, fixed in KB 1.0.1. MDLOps and KotORBlender don't add the empty value 'chunkname ' line. It is especially problematic for how the MDLOps parser was originally written, but KB is fine with it. That is too bad that MDLEdit seems to put it in, but unless I did something special, I'd expect that to cause MDLOps some problems. Maybe I'll take a look at that sometime.
-
1 pointMDLEdit compiles it with no errors but can confirm that MDLOps is choking on it. Loading it into KOTORMax causes the script to throw an error at line 2547, which is the end of node emitter Projectorflare. Edit: A quick comparison to the vanilla indicates that the Blender version is missing "chunkname" and "render Motion_Blur" from that node. After replacing that node with a copy from the vanilla version, KOTORMax throws an error at the next emitter node, so presumably KOTORBlender needs a tuneup in that regard.
-
1 point
-
1 pointQuick update at where I'm at with testing: HK-48 is a little too OP so I'm going to take another look his character to make him more balanced. I'm also just learning how to use script parameters so I'm gonna be rewriting some of the scripts to decrease the amount of files and make things a bit smoother. Other than that everything seems to be working just fine, but I've not yet tested all the endings to the HK Factory. Don't want to promise anything yet but I'm really close to getting this finished and released. If anyone's interested here's a little look at HK-48:
-
1 pointNew version of KotORBlender out, KotORBlender 1.0. This one has much more capabilities and features, thanks to Ndix UR. You need Blender 2.71 to 2.79 for it to work. May work with future Blender versions, but that has to be tested when those come out. https://deadlystream.com/files/file/889-kotorblender/
-
1 pointUncheck 'Export TXI Files' on the Export Odyssey MDL settings and/or don't use relative paths, I believe. Probably one of those places I should look at making paths more OS-neutral, and also probably find /look for the Blender API relative path methods...
-
1 pointMight I suggest starting with a smaller project first? That way you can develop the requisite skills in order to bring larger projects to life. Most larger modding projects end up never getting finished (or are finished in a sub optimal state). By taking the time to work on a few smaller projects (adding items, NPCs, ect...) you will have a better understanding of what is needed to successfully pursue your larger scope projects. Obviously, I do not want to dissuade you from trying, but I have seen a great deal of modding projects remain incomplete due to the lack of cohesive fundamentals.