Jump to content

Teancum

Members
  • Posts

    546
  • Joined

  • Last visited

Everything posted by Teancum

  1. I absolutely get what you're saying. I still think there's a potenial code workaround. It's a matter of searching for a JK2 bone and replacing it in memory with the JK3 name. My realm is outside of C++, so I can't sit and write out the code, but that's how I see it. Aren't all the extraneous JK2 bones ignored in JA anyway? What's left isn't an extra bone, but a misnamed one -- or am I wrong?
  2. Yeah, I had edited my post while you were replying. The bones are only referenced directly by name in one place in the code (as mentioned in my previous post), but they may be referenced by ID elsewhere. Hence why I see this as a code-based fix versus re-rigging mulitple models.
  3. *EDIT* Now after some research I remember the issue. The left-hand JO bone was renamed from lhand_tag_bone to lhang_tag_bone in JA. It's referenced in tr_ghoul2.cpp (at least in the Xbox source code, which is presumably identical here). It seems a semi-simple If statement could handle this, but then again it may not be as simple as a one-time rename.
  4. I'm speaking from more of a SWBF-solution type of thinking, but couldn't a bone have been dynamically created via executable code? I.E. If the game didn't find the bone it needs, then create it and attach it to the left hand bone? I dunno, I have to create workarounds like this all the time at my job, and I feel like ages ago when I worked on adding menu options to OJP there was a dev that came along and said they had solutioned a workaround that was never put into place.
  5. I'm sure this was fixed years ago, but I haven't been online with JA for 5-6 years. Was the dual-saber bug with JO models ever fixed? It's the one that would only let one saber leave the player's hand when they did that "saber circle" special move (not sure how to describe it).
  6. Yikes. That almost sounds like they were asked to pull it from somewhere higher up. For the source to disappear like that is concerning. Glad I grabbed it while I could.
  7. Dependencies change based on Visual Studio version. I'd recommend trying to compile with VS2003, or compiling the OpenJK version.
  8. I wonder how much of this could apply retroactively to Voyager Elite Force. If I remember right it uses either MD2 or MD3 character models, but the scripting, BSP structure, and overall AI should be largely the same. ***EDIT*** More info -- http://eliteforce.gamebub.com/skinning.php Also, several Elite Force source files (READ: not the full source) were previously released by individual Raven folk. See this (scroll way down for Elite Force stuff). It'd be cool to merge Elite Force and Soldier of Fortune stuff in. http://eliteforce2.filefront.com/developer/Raven_Software;115 Also, SOME source was released by Ritual Entertainment for Elite Force 2 (also a Id Tech 3 game). Might be interesting to have a fork that goes that route. -- http://eliteforce2.filefront.com/developer/ritual_Entertainment;1513 It's not much, but hit helps. ***EDIT #2*** Could I also make one request and ask that the Jedi Outcast mulitplayer gametypes be ported to JA (if they haven't already been - I haven't been an active JK series player for years).
  9. Yeah, I like the challenge, but mostly I like the idea of giving console players something PC players get. Well, that and the fact that it's been so long since I've used a mouse and keyboard that I don't know that I'd be any good any more.
  10. @@eezstreet - true. I've been looking at the source myself. There are definitely some Xbox dependencies missing, though they may be part of the XDK. I assume with much of it, though, that the Vicarious Visions fork just got merged in during development and the commented out. Admittedly I have a side-agenda of wanting to see a newer build of the game on the Xbox, but I suppose I'll have to maintain that build if I wanted to do something like that.
  11. ^This brings up an interesting point. I'd suggest (though I don't see this happening) that the entirey community maintain ONE code branch for the core game. Individual mods can fork off as necessary, but this way all benefit from having everything at their disposal.
  12. I get where you're coming from -- but it's all interweaved and will likely break things along the way, whereas simply not bothering it will allow you to move forward without having to fix things. And on the subject of compiling, that's incorrect. The original XDK (technically) is floating around the web, and VS2003 can be used to compile the code, which incidentally is probably the version the PC build was done on as well. It may compile easier there rather than a new build of Visual Studio as dependencies have changed. Agreed. The idea of such is great, but with JK so cheap it seems best not to try and split the community.
  13. *Teancum from Gametoast here. I wanted to make a quick comment on this, being a developer (outside the game industry) for several years. Seems totally pointless. It's embedded over 100 times in the source, and it doesn't hurt anything to keep it in. I'd recommend just leaving it alone. Pulling it will be an aboslute ton more trouble than it's worth, and will likely accidentally break many things along the way.
×
×
  • Create New...