DarthParametric

Modders
  • Content Count

    4,675
  • Joined

  • Last visited

  • Days Won

    533

Everything posted by DarthParametric

  1. 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.
  2. 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).
  3. Your tool is working correctly. That's just how the lightmap UVs are arrayed. For example, Plane02 in PLCaa that uses that lightmap:
  4. 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.
  5. 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.
  6. 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).
  7. 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.
  8. 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.
  9. 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.
  10. I assume you are a former Bioware Austin employee, from their Cartel Market art team?
  11. 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.
  12. That's C9-T9, the unbeatable swoop racing droid on Nar Shaddaa. I figured he needed a more sporty paint job.
  13. Perhaps you could hack a console to get a binary load lifter in there to carry the locker back to the sub.
  14. 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.
  15. 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.
  16. Is that the bloke hiding in the locker?
  17. I was just talking about the landing/take-off vids.....
  18. 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.
  19. I just downloaded it. The archive is fine. The problem is on your end.
  20. One option may be to re-bake the level's shadow maps if you think the lighting is wrong.
  21. 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.
  22. 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.
  23. Soon™: With that many lights, I could probably start my own disco cantina.
  24. You have two options. The quick way is via scripting, to spawn the object when the PC enters the module. This is best used for testing. Typically you hijack the on-enter script for the module to have it fire your script first, before passing on the original on-enter script. You can read some info about that here - https://web.archive.org/web/20151203123041/http://www.lucasforums.com/showthread.php?mode=hybrid&t=143536 - as well as plenty on DS, such as - http://deadlystream.com/forum/topic/3894-module-npc-and-object-placement/ - if you use the search function/Google. The second option is what would be considered the "proper" way to do it for the finalised version of a mod that is to be publicly released. Namely, adding your content to the module itself via a MOD file and editing the module's GIT to add in your placeable spawn data. The downside of this approach is it only works if you haven't previously entered the module, hence why this is better left for release versions and using scripting for testing.