CarthOnasty

3 hours ago, Rinku said:

This is looking great! Excited to see the final product

Thanks for having a look! I encourage you to download v1.1 in the meantime if you haven't. And as a special treat, here's a version I'm working on for Tatooine:

Random progress pic.

Dooope, this is going to be awesome! I'm looking forward to everything!

@ebmar Here's a rough idea of how these wraps would work:

10 hours ago, DarthParametric said:

I'd advise against the unwrap for that top object. While splitting apart the polys like that will eliminate any stretching or compression, it will be a real bastard to texture unless it is just a flat, solid colour. Is that like a half-sphere or something?

Yeah, I've been going back and forth with that. I've tried it all connected but I just get too much distortion since the angles are inconsistent. The unwrapped polys I can make work at this point, but yeah, I totally get what you're saying. And yeah, it's basically a half-sphere, it's the base of the map.

9 hours ago, ebmar said:

Ah, think I get it. They will be separated as some parts, is that it? Hahah! Good luck with that, @CarthOnasty!

Exactly what @DarthParametric said. I ended up splitting this model a lot more than I had intended, but I think things will be much easier for in the long run, also considering I'd be making 5 different models.

Okay, I think I have a map I like at this point...

3 hours ago, DarthParametric said:

As I mentioned in another post a while back, they were likely using Max 4 at the time, which is basically what GMax is (it's just v4 with some of the features ripped out). Max's UV tools aren't fantastic, but they certainly aren't bad enough to excuse some of the work Bioware came out with. I have to wonder whether some of it was automated via script or something.

That would make a lot more sense. There's a feature in Blender that basically does that. What I found to be the most odd thing, is that these little guys....

....are mapped to literally the whole texture. I'm not at my comp, but the UV basically looks like this:

I mean, I get that 1 side of the pyramid is all light, but c'mooooooon.

1 hour ago, DarthParametric said:

And then you see some of the layouts Bioware shat out for K1 and you wonder how is that the work of a professional development studio?

Seriously, yes. The ones for the star map were just so bizarre and disproportionate. I mean, there were places where the texture would be stretched for sure---an obscene amount. Some parts of the .tga disproportionately sized as well, because I guess it was easier to edit the image versus the UV map?!

38 minutes ago, DarthParametric said:

Unwrapping is an entire art unto itself.

Dude, you are not joking. I'm learning that more and more. I know that are parts I want to accent, but I also don't want a map that has 30 different islands. And then making sure the seams work well against each other? It's madness.

Working on some new UVs. I thought I was making things easier for myself, but in fact was making them more difficult. I've been trying out different unwraps to see what might work best and make the work much more efficient.

Hey bud, fellow Mac player here. What's the trouble you're having exactly? (Feel free to throw in some screen caps if you think it'll help.)

On 7/15/2018 at 1:11 AM, Mr Ardvark said:

Here ya go, I've got a shittonne of mods installed, I hope that isn't a problem. 👌

I changed the appearance to a vanilla model in KSE though so it should work without crashing.

For you.rar

You're my hero, thanks!!

Doesn't matter if it's light/dark, whatevs. TYIA!

On 7/10/2018 at 1:33 AM, ndix UR said:

OK, I've got these issues sorted. All kotorblender issues. Will be fixed in 1.0.2.

One complete typo was making the particle effect on the sphere wrong (Motion instead of Motion_Blur in two places).

The issue w/ the lines & symbols being visible came down to my setting of minimum values for alphaMid and lifeExp that didn't include the full range of possible values. I had them set to 0.0, but apparently -1.0 is the actual minimum value. Because there are 50+ emitter controllers, I think I probably relied on logic, rather than exhaustive cataloging, to establish some of the min/max values. And anyone who tries to apply logic to the functioning of the game engine gets bitten eventually...

Here's the code patch:

  Reveal hidden contents

--- a/nvb/nvb_node.py
+++ b/nvb/nvb_node.py
@@ -1625,7 +1625,7 @@ class Emitter(GeometryNode):
             elif attrname == 'render':
                 attrname = 'render_emitter'
                 if value not in ['Normal', 'Billboard_to_Local_Z', 'Billboard_to_World_Z',
-                                 'Aligned_to_World_Z', 'Aligned_to_Particle_Dir', 'Motion']:
+                                 'Aligned_to_World_Z', 'Aligned_to_Particle_Dir', 'Motion_Blur']:
                     value = 'NONE'
             elif attrname == 'blend':
                 if value.lower() == 'punchthrough':
@@ -1639,6 +1639,8 @@ class Emitter(GeometryNode):
                 else:
                     obj.nvb.p2p_type = 'Gravity'
                 # p2p_type has update method, sets p2p_sel
+                # except it doesn't seem to initially
+                obj.nvb.p2p_sel = self.p2p_sel
                 continue
             #print(attrname)
             setattr(obj.nvb, attrname, value)
--- a/nvb/nvb_props.py
+++ b/nvb/nvb_props.py
@@ -389,7 +389,7 @@ class KB_PG_OBJECT(bpy.types.PropertyGroup):
     frameend = bpy.props.IntProperty(name="End Frame", description="Frame End", default=0)
     framestart = bpy.props.IntProperty(name="Start Frame", description="Frame Start", default=0)
     grav = bpy.props.FloatProperty(name="Gravity", description="Gravity (m/s²)", default=0.0, min=0.0, unit='ACCELERATION')
-    lifeexp = bpy.props.FloatProperty(name="Lifetime", description="Life Expectancy", default=1.0, min=0.0)#, update=kb_update_lifeexp_prop)
+    lifeexp = bpy.props.FloatProperty(name="Lifetime", description="Life Expectancy", default=1.0, min=-1.0)#, update=kb_update_lifeexp_prop)
     mass = bpy.props.FloatProperty(name="Mass", description="Mass", default=1.0, min=0.0)
     p2p_bezier2 = bpy.props.FloatProperty(name="Bezier 2", description="???", default=0.0)
     p2p_bezier3 = bpy.props.FloatProperty(name="Bezier 3", description="???", default=0.0)
@@ -411,7 +411,7 @@ class KB_PG_OBJECT(bpy.types.PropertyGroup):
     lightningsubdiv = bpy.props.IntProperty(name="Subdivisions", description="Lightning Subdivisions", default=0, min=0, max=12, update=nvb_update_emitter_prop)
     lightningscale  = bpy.props.FloatProperty(name="Scale", description="Lightning Scale", default=1.0, min=0.0, max=1.0)
     lightningzigzag = bpy.props.IntProperty(name="ZigZag", description="Lightning Zig-Zag", default=0, min=0, max=30)
-    alphamid = bpy.props.FloatProperty(name="Alpha mid", description="Alpha mid", default=1.0, min=0.0, max=1.0)
+    alphamid = bpy.props.FloatProperty(name="Alpha mid", description="Alpha mid", default=1.0, min=-1.0, max=1.0)
     percentstart = bpy.props.FloatProperty(name="Percent start", description="Percent start", default = 1.0, min=0.0, max=1.0)
     percentmid = bpy.props.FloatProperty(name="Percent mid", description="Percent mid", default=1.0, min=0.0, max=1.0)
     percentend = bpy.props.FloatProperty(name="Percent end", description="Percent end", default=1.0, min=0.0, max=1.0)
@@ -474,7 +474,7 @@ class KB_PG_OBJECT(bpy.types.PropertyGroup):
                  ('Billboard_to_World_Z', "Billboard to world Z", "Billboard to world Z", 4),
                  ('Aligned_to_World_Z', "Aligned to world Z", "Aligned  to world Z", 5),
                  ('Aligned_to_Particle_Dir', "Aligned to particle dir.", "Aligned to particle direction", 6),
-                 ('Motion', "Motion Blur", "Motion Blur", 7)],
+                 ('Motion_Blur', "Motion Blur", "Motion Blur", 7)],
         default='NONE', options=set())
     blend = bpy.props.EnumProperty(
         name ="Blend", description="Blending Mode",

 

 

You the best, thanks for the extensive work and patience! I'll give everything a shot this evening when I get home. Thanks again.

::edit::

@ndix UR Patched and compiled with no issues! Opened in-game and the model, animations, textures, etc. loaded perfectly. Thanks!

11 hours ago, ndix UR said:

Cool, if you're interested in getting support, you need to be way, way more specific about what animations are changed and/or what particle effects on what meshes.

For sure, understandable. Here's what I'm working with.

This first clip, starmap1.mov, is the default texture/animations, nothing's been touched.

First try was using MDLOps 1.0.0. I used the following settings to process the model:

I then imported into Blender with the following settings:

I didn't change anything with the model and then exported with the following settings:

The clip you see in starmap2.mov is the end result.

starmap3.mov is repeating the above steps with MDLEdit 1.0.3.

In the second video, you can see how plc_starmap_08.tpc and plc_starmap_09.tpc have loaded prematurely. Then in the process of the starmap opening, the particle effects have changed on the rising orb, sphere02 it looks to be called. After that none of the remaining textures (outside of plc_starmap_06.tpc) have loaded and the arms (Map_Arm_01, Map_Arm_02, Map_Arm_03) have duplicated, with one set remaining "unopened".

In the third, processed using MDLEdit, the animations are working, though none of the interior textures are loading.

Let know if I can provide any more info. And thanks!

Just a heads up, I repeated the process using MDLedit 1.0.3. No issues with modeling or maps or anything like that. Only issue I'm seeing is same as above, particle effects have changed and animations are off or not loading.

29 minutes ago, ndix UR said:

Well, that would be after export.

Also, in Blender, if you just parent plc_starmap_wg under the plc_starmap_pwk node, you should get the right result without having to make text edits after exporting from Blender. I think. Maybe.

1. That did the trick! I was able to import/export and recompile. And then to confirm, you can just parent that node in Blender to avoid doing it manually later.
2. Only one issue at this point (sorry): some of the particle/animations are either activating early or have different effects.

19 minutes ago, ndix UR said:

Yeah, that's more of a MDLOps issue than KotorBlender actually. It happens because kotorblender isn't putting the PWK nodes after all the geometry nodes. There's no particular reason that should be required other than the naive way I implemented the code to remove those nodes in mdlops. Technically, in your model, the PWK nodes are after all the geometry nodes, it's just that your plc_starmap_wg node has the wrong parent (which makes it seem like there's one non-PWK node in the middle of the PWK nodes, which triggers the same bug). If you change its 'parent plc_starmap' line to 'parent plc_starmap_pwk' the model works fine. I had to make some fixes to how that stuff was exported to make it more like mdledit after the 1.0.0 release of mdlops, which, I think is why you are having that issue...

Should I make that change before importing to Blemder? Or after?

Hey folks, just me being a pain in the ass again. I quickly installed the latest version in excitement and have unfortunately run into the same with MDLOps locking up when compiling the model. Attached is my direct decompile of the original model using MDLOps 1.0.0, then the export from Blender (made no edits to be sure).

Again, I'm not trying to be a pain. Let me know if I can provide any more information. Thanks.

plc_starmap-ascii.mdl

plc_starmap.mdl

Finally got everything mapped out correctly:

8 minutes ago, A Future Pilot said:

Dude, that's looking sexy!!

At first I thought I had posted a photo of my ass, but I see you were talking about the card layout.

Here's another update of the basic layout I'm looking it. It's going to be a lot more .gui work than I had planned, but anything for my adoring fans.

It's been awhile, I know. Here's an idea I threw together for a new scoring system:

Colors aren't set, that's just for an example. Middle semi-circle illuminates to whomever's turn it is; bars underneath illuminate per round won.

In theory, since these are SIth trainees, shouldn't they have the training sabers? Or because they're Sith they don't use "safe" methods of training.

18 hours ago, Oaks said:

Actually, I was thinking bout K1. When you win or lose a race, the player makes a pose for victory or loss. I was thinking of a mod that puts the player doing these poses using the swoop racing suit.

I would love this!