DarthParametric

Modders
  • Content Count

    4,626
  • Joined

  • Last visited

  • Days Won

    523

Everything posted by DarthParametric

  1. I have some replacements for the kolto tank soldiers: I left the terrible vanilla textures intact, so any reskins of the original placeable (did Jorak Uln do one for that tank?) will work with these. Currently there are 6 male variants, 2 from each race: I'm thinking about adding some female ones, as well as flipping the pose of the male ones to provide some variety. Making some minor timing edits to the animations would also help break things up, so they aren't all bobbing up and down in unison. I was also thinking whether it might be better to go with the round tanks you see on the side of the room: Replacing the two at the end with tanks of the same cylindrical type, then add extra bodies to those tanks on the sides. Those side ones are actually part of the level model, so you'd just need floating body placeables for those. I don't think that style exists as a standalone placeable though, so it would need to be ripped out of the level model to replace the end ones.
  2. Hrm, there's certainly something odd going on there. I just encountered mesh visibility issues with a placeable I was making as well. It was exactly the same thing. Putting everything inside dummy objects solved the problem (even though the vanilla model had everything as direct children of the OdysseyBase). And even then, it seems like it is extremely picky about order in the hierarchy. I split the animated and static objects into two different dummies. In order for the animated objects to be visible, their dummy must be above the static object dummy. Bizarre. Ideally, this thread should probably be merged into the MDLEdit bug report thread, so bead-v sees it upon returning from the Outer Rim.
  3. I would assume their lightmap UVs were probably auto-generated, yeah. Pretty much all of them only use a fraction of the available UV space. Maybe it was intended to keep to some uniform size/pixel density to keep shadows consistent. As to how they were generated, it would have been baked in 3DS Max, probably in a not too dissimilar manner to how modders do it now (albeit most likely with some scripts to automate things).
  4. Your tool is working correctly. That's just how the lightmap UVs are arrayed. For example, Plane02 in PLCaa that uses that lightmap:
  5. Remember from your adventures with the Ravager models that MDLEdit appears to require all meshes in a level model to be children of a dummy object, which is itself a child of the AuroraBase. It doesn't appear to like meshes being direct children of the AuroraBase. Also, how big is your object? Is it smaller or bigger than the existing skybox (504ONDg)? Because world 0 is probably the wrong position, judging by looking at the whole level. 504ONDc is roughly in the middle of the layout, so I would duplicate its co-ords in the LYT for your model. That is assuming you want your object centered to the level of course.
  6. Some time back I made a model of Mira's wrist launcher styled after her concept art: as a request. My understanding is that it was intended for inclusion in a larger "Concept Mira" mod. But that was pushing two years ago now and I don't believe anything happened with it, so I figured I should put it to use. Here's the model I originally came up with: The intention was for her whole body to be flipped to match the concept art, hence it is on the left wrist (although the body model isn't flipped in that pic). That was back in February 2016. Today, I dusted the old girl off and gave her a lick of paint: I'm not super happy with the body of the rocket. I need to play around with that a bit. I probably also need to dial back the envmap a bit. Getting that right always drives me mental. While I was at it, I played around with adding the glowy bits to her headband (although the glow is pretty underwhelming in practice): I also scaled down the shoulder pads, as I never liked the giant size of the default ones. I still need to add the straps over the top of those, like in the concept art. And for good measure, I also deleted the weird "hair hat" she had. I did mess around briefly with trying to improve the look of it by adding in some subdivision, but that didn't work out.
  7. Playing through Onderon, a couple of a additions to the wish list come to mind. JCarter and I discussed these previously at points, namely the Mandalorian shuttle and the Basilisk War Droid. If you were going to remake the landing videos, might as well add those two to the list. That would be a good opportunity to switch out the in-game appearance of the shuttle, swapping the G-Wing for something else. And of course tackling the issue of the canonicity of the Basilisk's appearance (or lack thereof).
  8. The forum has a large mod projects sub-forum. I'd suggest that if this project is to progress to anything significant, an early point of business would be creating a dedicated sub-forum for it. That seems like it would fall under your purview. Depending on how hands on you want to be, there are a myriad of managerial/organisational type things that you could do. Having been involved in an (ultimately failed) large mod project before, I know firsthand that these sorts of things live or die based on organisation. Trying to get a group of disparate modders to do anything collectively is like herding cats. It will quickly fall into a heap unless things are very clearly planned out. As an example, for myself as a potentially interested contributor, what I absolutely need is a clear outline of exactly what the project is doing, what has been done, and what yet remains to be done, and who is doing what. I need a list of tasks that are awaiting assignment that I can peruse, and if one takes my fancy I need very specific guidelines for what is required and by when. To use the Yavin station as an example, I would want specifics of size/dimensions, does it have to be fully constructed or do you only need a camera facing half, is it a high poly CG model or a low poly game model, does it need lightmapping UVs, do I need to create the textures, what's the timeline for completion, etc. Who do I talk to if I have questions/problems, how do I report my progress, what do I do with the final assets? And if I agree to undertake this task, then it needs to be made clear that this task has been assigned, so someone else isn't doubling up the same work. Someone, or possibly several someones, needs to implement and manage such a system.
  9. Yes, I noticed. To be honest that's premature at this stage. At this point we need discussion and organisation. Randomly making stuff now is a waste of time, as chances are it could end up needing to be partially or wholly remade at a later date once all the requirements are known. And regardless, doing it via random request threads is not the way to go. That way lies madness. If you are keen to pitch in SH, I'd suggest there are far more useful contributions you could make in an administrative capacity.
  10. It's basically just a giant lightsaber with a couple of flappy bits. I don't think recreating it would prove to be a significant challenge.
  11. I assume you are a former Bioware Austin employee, from their Cartel Market art team?
  12. They are placeables in both cases. For the Star Forge captives, the label in placeables.2da is, for some reason, "Dead Malak". The model name is PLC_EndCorps. There are three static body meshes, two of which hide under the floor at any one time. The animations switch between the bodies depending on the status of the captive. There are four textures used for the bodies. The "healthy" appearance uses PLC_EndPlA and PLC_EndPlC. The "drained" appearance uses PLC_EndPlB and PLC_EndPlD. I recall there being some discussion here at one point about the possibility of replacing those with something less terrible, but at the time we didn't have the model tools to handle it properly. The injured Republic soldiers in the kolto tanks in the Taris Upper City South medical facility are the generic placeable KolTank2.utp, "KoltoTank2_with_body". The model is PLC_KolTank2. The body uses textures pmbal01 and PMHC04. The breathing mask texture is shared with the tank itself, PLC_KolTank.
  13. That's C9-T9, the unbeatable swoop racing droid on Nar Shaddaa. I figured he needed a more sporty paint job.
  14. Perhaps you could hack a console to get a binary load lifter in there to carry the locker back to the sub.
  15. My feeling is that the Ebon Hawk models are probably mostly ok, they primarily need some new textures. Looking at the Peragus and Korriban videos, the CG model doesn't look significantly more detailed. That said, it's certainly feasible to touch the old girl up a bit, add in some extra geometry where necessary. That's probably getting ahead of things though. I would think the logical place to start would be producing a spreadsheet of exactly what is needed for each shot in terms of assets, determining what already exists in the game content that can be used as-is, what can be used but needs some TLC, and what needs to be scratchbuilt. Then you can start soliciting for volunteers to tackle the various bits. It would presumably be wise to make use of some sort of tracking/project management system. And something like a GIT or SVN repository would be useful for sharing/storing the assets.
  16. I'm not sure if this is a bug, or user-error. I tweaked the astromech animations to suit my model: clean up some clipping, add in a probe arm door, and animate the rear wheel. Testing it in game it seems like certain animations are stuck on their last frame when finished, rather than returning to the default. For example, using security to open a cylinder, when complete the probe arm will remain extended rather than retracting. Similarly, after combat the gun will remain popped up rather than returning to flush with the head. Do any potential causes spring to mind? A casual comparison of the animation section of the ASCIIs for my model and the vanilla don't reveal anything obvious. Edit: If I load the vanilla animations back onto my model, they seem to function correctly. So presumably that means some error on my part. Edit 2: OK, disregard. Seems like a couple of animations have bad keys at the end, causing the poses to blend into the subsequent animation. Entirely user-error. Edit 3: Maybe not. Comparing the animations in question to the original again, they actually seem the same. I did notice that my model had the "compress quaternions" option turned off, unlike the vanilla model, but when I enabled that and recompiled, that seemed to screw up the animations even more, seemingly reversing things. For example, unlocking a crate, rather than rocking back and extending the probe downwards, with compressed quats he leans forwards and the probe points up in the air (like he is giving the finger - must be going through a rebellious phase). The end result is still the same, with the probe remaining extended after the animation finishes, it's just rotated 180 degrees now. Edit 4: Reloading a fresh version of just that one container unlocking animation from the vanilla model and adding in some extra keyframes for the probe door, it still results in the probe arm hanging out at the end. It's kind of like that saber animation issue where the blade stays extended. Edit 5: OK, the problem was user-error indeed. It seems the problem was missing keys for the default state for certain parts. So presumably the model had no return state for things like the probe arm, so it just got stuck in the last used pose until it was repositioned by another animation. Adding some keys for neutral states to the other animations appears to have sorted the problem. I guess there is nothing more to see here.
  17. Is that the bloke hiding in the locker?
  18. I was just talking about the landing/take-off vids.....
  19. I just watched the TSL landing/takeoff videos again, and wow the quality really is terrible. We must be to the point now where it's time to re-render all those as some sort of large group project. But in terms of the skybox, it's very orange.
  20. I just downloaded it. The archive is fine. The problem is on your end.
  21. One option may be to re-bake the level's shadow maps if you think the lighting is wrong.
  22. Hrm, the last one looks a little too blue to me. I think the middle one is closer to where it needs to be, personally.
  23. No. The T7 version is the default. The vanilla-style head with blue stripes is an optional alternative. With all the other stuff on my plate, I don't have plans for any further variants at the moment. I still have to sort out the protocol droids so I can get the first round of testing done over Xmas. Then after those two are released, it's on to the war and assassin droids. Once all the base versions of the mods are out, I may come back to it at some point in the future as part of a revision/update, but no promises. Of course there's nothing stopping someone else from releasing different texture variants. Edit: Now the testing can commence.
  24. Soon™: With that many lights, I could probably start my own disco cantina.