Jump to content

RebornKyle

Members
  • Posts

    46
  • Joined

Everything posted by RebornKyle

  1. Do you mean the cutscenes in Jedi Academy? I didn't modify any of the JKA campaign, at least not in the base mod. I did in the custom add-on, but not any of the cutscenes with Luke. I'm not sure what could cause that. And I never noticed anything in the Academy game when I went through it to test before
  2. What problems exactly? Also this mod is used with JK enhanced, and the OG mod. Make sure you have both!
  3. Just tested the download version and didn't get any errors. I recommend you create a backup of your gamedata, and do a clean install.
  4. I messaged the staff about this, hopefully it gets fixed soon. EDIT: was fixed! Thanks for the review btw
  5. Version 1.0.0

    11 downloads

    A small texture mod designed to make the levels of t2_wedge and ffa_bonus1 have a green sky and skybox, similar to how it looks from orbit in the movie in-game. I was never satisfied with how it looks like Bespin 2.0 in the level, personally I think that's boring. Like why show a green planet if it's not going to actually be green? Anyway... With this the level is much more unique looking. Plus, the drifting fog in the story level is now much more visible. All it is, is a re-colorization with new palette of the existing skybox textures. So there should be no clipping or blending issues. Comes with appropriate levelshots as seen in the screenshots, so you'll never have to think about Bespin again, only green
  6. I asked our lord and savior (ChatGPT) and surprisingly it had an answer for me. I had to add animation to the turret_damage.md3 model because apparently the game freaks out if a model is moving and it doesn't have animation. So I just added 2 frames marked down in blender using SomaZ's plugin, and the message has disappeared. Now the turrets move exactly like in Outcast! Their aim is a little off compared to Outcast, but its sufficient.
  7. I managed to solve another bug in the JAO mod: the turrets in ns_hideout now move again. However, when destroying any one of them, an unending stream of the same warning pops up, which can be seen in the attached screenshot. It doesn't crash, but its an eyesore that stays in the top left corner due to it repeating over and over. I'd guess that the reason it's repeated about a million times is because it gets a warning each time it moves, which is just about every frame, lol. Does anyone understand what's going on here, and how to fix it? I've never seen this at all. For reference, I'm using misc_turret, not the original misc_ns_turret that Jedi Outcast used for this level, due to it having its own bugs that I'd rather avoid for now. Not sure if that would cause the issue, but it seems to be fine when its NOT destroyed, so...
  8. This sounds like an ext_data problem. Did you install JAEnhanced? And once you installed that, did you then replace the zZz_ja_enhanced.pk3 in the jaenhanced folder with the one that came with this mod? And did you replace the other files listed that I provided with in gamedata and jaenhanced?
  9. Version 1.2.5

    171 downloads

    Hello and welcome to something that's taken me over a year to complete. Welcome to Jedi Academy: Outcast: Unofficial Patch. What's in this mod/patch?: Extensive bug fixes, improvements, and features for the original Jedi Academy - Outcast mod (as well as some bugs that I found in OpenJK and JAEnhanced that are fixed here). Also contains full menu support for inventory items found in the original Jedi Outcast game. It's fair to say that there are now only a handful of bugs left that I couldn't solve. This mod runs on the base provided for JAEnhanced, so all features from that mod are included in this. For a full list of bugs fixed, check the changelists found within. But here are some major ones: All cutscenes fixed Galak_Mech fixed Missing sounds for Mark1, Minemonster restored Restored Bryar Pistol as the secondary used in Outcast's campaign Restored zero gravity event in doom_shields (thanks Linken) Fixed yavin_swamp map weather, textures, environment NPC alt-fire restored Lady Luck's turret and doom_detention's turret fixed ns_hideout turrets move on rails again (1.2.0) Prisoners wear correct outfit in artus_detention and artus_topside All inventory items restored, with bind-able configurations in the menu (1.1.0) Various bugged NPC scripts, behaviors, and more fixed Bugged lightsaber that occurs in yavin_canyon fixed. Restored Jedi Outcast's demo level weather In addition, some additional features have been added. These include: imperials, impworkers, stormpilots use their original pistol from Jedi Outcast Boss battle music, and additional NPCs, for ns_starpad's showdown with Reelo. cairn_dock1 contains some additional NPCs to enforce a stealth run. Allied NPCs no longer injure each other (SWGL feature) Fast stance bug that afflicts JAEnhanced fixed (SWGL feature) Some modifications made to Jedi Academy campaign (optional) Support for Infinity Blade's Mercenary Kyle model in Jedi Academy (optional) Other optional features, like different models, behaviors, etc. To install, the following are required and to be installed in the listed order: Jedi Academy Jedi Academy Enhanced Jedi Outcast files (MUST BE ACQUIRED BY PURCHASING OUTCAST, I WILL NOT PROVIDE THESE) Jedi Academy - Outcast (original mod) All files in this mod download It is highly recommended you do a CLEAN install of these mods. That means no additional mods present in your game folders at time of install. Once that is done, and you are sure the game runs fine, then you can start adding back in mods, to see if they are compatible. This mod runs the same way as Jedi Academy Enhanced: you must start Jedi Academy by clicking on the ja_enhanced.x86.exe that comes with this mod. Create a shortcut for it so you don't have to look in Gamedata every time to run it. Check the readme for each mod for any help you may require. This mod's essential readme is in the main folder. If there is anything you think is not right and not covered by the list of known bugs, please reach out to me in DM on here and I will patch it when able.
  10. One more minor update (hopefully the last one) NPCs still had a tendency to switch to fast, albeit very briefly, if you were a staff user and they were a staff user, with the above fixes. As well, for whatever reason, the rebornmasterstaff NPC was still completely afflicted, he was the only one. But, the solutions are fairly simple that I found. In NPC_reactions, switch the ordering of the if statements and connect their execution through else if, like so: if (self->client->ps.saber[0].type == SABER_STAFF) { self->client->ps.saberAnimLevel = SS_STAFF; } else if (self->client->ps.saberStylesKnown & (1 << SS_FAST)) { self->client->ps.saberAnimLevel = SS_FAST;//next attack must be a quick attack } And in AI_Jedi, add this if statement after the client check in Jedi_AdjustSaberAnim, to perform an immediate check and return if they have the staff saber type: if (self->client->ps.saber[0].type == SABER_STAFF) { self->client->ps.saberAnimLevel = SS_STAFF; return; } Now having tested all the base given NPCs (and JK2 ones), I can safely say the glitch does not rear its head anymore, with any NPC. That is with the base NPCs though, so I'm not entirely sure how custom created NPCs fair, but I feel as long as they use _humanoid animations its very likely they'll be ok too.
  11. Well everyone, happy to say that not only does Linken's code work, but I'm an idiot. Somehow between adding the partial fix and the full fix, I had managed to switch my directories. I was adding the newly compiled code to my backup So yeah I never saw the fix in action because I was still using the partial fix. Amazing! Ha.... Despite wasting hours trying to debug it, at least now I can say that this is the solution to fix the bug I've described. I'd recommend to anyone developing OpenJK to add this patch immediately though. I found it occurring not only in OpenJK base, but Jedi Academy umodified. It's a serious immersion breaker for dual and staff users. Thank you @Linken for the assistance! EDIT: ONE MORE THING! The fix Linken described in AI_Jedi is slightly different than the one above. You HAVE to add SS_STAFF as the end range for Jedi_AdjustSaberAnim. Otherwise the glitch persists. Linken did do this in the first commit he made on the bug, so that's how I knew about it.
  12. @Linken I went digging through the commits you've made to SWGL, and found two relevant ones to my problem. One was the aforementioned AI_Jedi fixes. The other file that both commits touched on was NPC_reactions. These lines were the new ones added by you and your team: if (self->client->ps.saberStylesKnown & (1 << SS_FAST)) { self->client->ps.saberAnimLevel = SS_FAST;//next attack must be a quick attack } if (self->client->ps.saber[0].type == SABER_STAFF) { self->client->ps.saberAnimLevel = SS_STAFF; } Combining these fixes into my solution, I am happy to report a partial success. Single and Dual-wielding NPCs are no longer affected! However staff users still are. Linken, is there any chance you may know the other part(s) to the solution you found? Perhaps mixed in with a different commit? Everyone, see my below post. Full credit goes to @Linkenfor the fix and help!
  13. Apparently it affects the game even with nothing but the base assets. I stored a backup in an entirely different location, deleted all of Jedi Academy files, then uninstalled it, re-downloaded it, and booted it up only to encounter the same glitch when doing it again. I've now put my backup back in. Unless I'm doing a clean install wrong here, or that somehow the hardware I'm using isn't up to snuff to run JA (lol), then something seems to be wrong with the steam version itself. I cannot recall this bug ever appearing when I had it on disc many years ago as a youngin, and I loved using the staff style too. RIP my brain and any hope of figuring this out on my own.
  14. Ok so, I tested it extensively in-game as I had no luck with figuring out a solution (yet). Here are my findings: Single saber NPC's ARE AFFECTED. I figured this out by spawning in alora (from hoth3, not taspir2) who only has one saber style, medium, but who is not hardcoded like the cultists to follow one particular or multiple saber styles, while I used a single saber. She went to fast style! However she did correctly go back to medium every time, even when I only used a set medium style back at her. So its temporary with single sabers, but it still does happen. The only NPC immune to this effect is tavion_scepter. Hers is a great indicator as to the problem, as her scepter is not a saber, but a different weapon itself. Thus the problem may lie exclusively with the way the saber weapon is handled. There does not seem to be a clear way as to what actually triggers this. I thought that damage alone might be the cause, but I hovered above NPCs that were engaging me, and I did not damage them in any way once spawned nor could they attack me. After a random amount of time, they started using fast style. Damage DOES however produce immediate results, much faster than waiting for the NPC to switch. Not sure then if its damage itself or some code being used with the damage that other properties of saber combat use as well. Staggering them with force push or gently brushing them with saber (not attacking), also triggers it pretty consistently. Switching your style with either dual or staff (fast with dual, medium with staff) can cause the NPC to switch BACK to the appropriate style they should be using. So it seems like the NPC is reading what style we're using and incorrectly switching, when they shouldn't ever have that option to. They will switch back to the buggy fast style if your style matches again however. It is exclusively based on what style the player is using that affects the NPC. The saber type itself does not matter. For instance, I glitched my player to have the staff style while using a single saber. When using the staff stance, the NPC became bugged. When switching to any other style, the NPC switched back to staff style. To go over the specifics of the behavior the NPC exhibits while bugged: Their movement, attacks, saber lock anims, recoveries, taunts, and pretty much everything exhibit the behavior of what should be an NPC using a single saber with fast style. The ONLY thing not affected, is their neutral stance with sabers out while not moving at all. They display the correct stance every time. With all of this in mind, I'm hoping someone can figure out where the issue may lie without me having to dig, but in the meantime I'll continue to do so when I can.
  15. I wanted to do an update on this, just so its on record. The issue with the invisible bolts lies in the code itself, specifically in g_turret and cg_weapons. You have to change the FindItemForWeapon's input in SP_misc_panel_turret method to WP_TIE_FIGHTER. It was still looking for WP_EMPLACED_GUN, from the last game... As well, the hud will glitch out if you change this, so in cg_weapons, you have to add the appropriate FxSchedulers for that. All of them can be found prexisting with the WP_EMPLACED_GUN's FxSchedulers. Then it works perfectly for all turrets. To get the turret in ns_starpad to be consistent with its fire (which I found it is NOT, no wonder that section is a little difficult), move the gun_down ref tag by -5 on the z-axis. Voila!
  16. I twiddled my thumbs for way too long before I realized I can just look at the code for SWGL on GitHub and see what the differences between mine and @Linken's are. I think I've effectively ruled out the function changes for Jedi_AdjustSaberAnimLevel. Doing combinations of, and also just changing them all to SWGL version, yielded the same results no matter what. I'll keep looking further and compare the two files later, to see if something else may be the key.
  17. I looked further at the function, the first set of statements set the styles of specific NPC types, that's understandable, but unlikely to be the cause, as both allies and enemies are affected by this, and the code only affects single style NPC types like the cultists or certain ranks. The rest of it I'm not too sure about, it seems like edge cases in case of switching past the enumerated types of styles, and a final block for debugging. That part could be the issue, but I don't see an easy fix for that in this file. I'm afraid I don't know where to go further.
  18. Unfortunately the replacement didn't seem to do it. I replaced the SS_FAST flag with the Q_irand(SS_FAST, SS_TAVION), results were the same. When I have more time I'll look a little further at the function call itself
  19. I see, thank you Linken. Do you remember where the problem was in the hardcode? Or did you have to write new code to correct it? Perfectly fine for doing either, but as we all know the code is old and a spaghetti filled mess, any place to start is a great one. BTW, kudos for fixing so much with your mod too, its very impressive how well it plays, and how well everything is integrated all together, from the JAO mod inside to the new missions recently created.
    This is the Ladder-esque map we've all been waiting for for years now. 40 rounds of extremely tough enemies. And also unique ones! (Done with scripting and not unique NPC's, Author is out of his mind, in a good way! lol). From lightsaber wielding stormtroopers (Kreel?), red rapid fire stormtroopers (Sith Troopers?), reborns with a random max 3 force power, lightsaber tanky Weequays, and the final boss being a Desann with SHIELDS... the creativity is off the charts. Did I say its tough? I mean its almost unbeatable. I'm sure there will be some maniac who manages to beat this on the hardest settings possible, but I daresay that may be a year from now or more. You will definitely be able to spend a lot of time on this map. It took me 40 minutes to beat it... on God mode and with saberrealistic 9 on. I highly recommend the latter setting if you don't want to bash your head for dying to 16(!) reborn_new's at once. I'm sure there are some who think I'm exaggerating, but seriously, just play it and you'll see what I mean. It also keeps track of how many map secrets you find, which I also really appreciated. It shows a true passion for the map maker, and adds some replayability if you miss some. Not to mention the map itself is extremely well designed and detailed. I cannot sing the praises of the author enough. Whether you cheat like I did, or decide to face the gauntlet for real, it is so much fun to play. 10/10
  20. Basically when you as the player wield a saber staff, other NPCs who wield saber staffs will start out using the expected stance, but then for whatever reason changes to fast style, with both blades extended. This effect lasts until they die, I think. I also think that dual wielding (2 separate single blades) is affected by this, same method as above but just with dual wielding stance instead, they'll start using fast stance with both blades active. I don't use that stance much though so I can only say I've seen it, not that I regularly encounter it. From the 4 forums I saw on the topic, it might affect OpenJK users. I myself use JAEnhanced, so I can confirm that it does happen with at least one OpenJK mod. No idea why this happens, because it only occurs when the player is also using those styles. Single lightsaber users would not encounter this bug, the NPC correctly uses all available styles to it when this happens. So to sum, staff players will encounter bugged staff NPCs, dual players may encounter bugged dual NPCs, single players unaffected.
  21. I've noticed this bug has been unsolved from various forums I've looked at. It seems to only happen when the player wields the same weapon type too. Tried to fix it without diving into the code, through npc and sab files, but that doesn't work, so I'm 99% sure its a hardcode issue. The problem with that is the references are too vast and complex for all the different saber styles, especially ones with restrictions like the dual and staff, to sift through. Does anyone have experience in solving this issue, or know where to start looking at least?
  22. Eureka! I successfully merged one large weatherzone entity that covered the entire map, allowing the game to recognize the established weatherzone patterns, AND keep them upon subsequent reloads. With that, yavin_swamp's restoration is complete. I found that where you place the weatherzones matter for the outside brushes: if there are no weatherzones encompassing an outside brush, it will not rain there. So I could theoretically make the zones even more fine tuned, as there are a couple of spots it shouldn't rain on the map, but it does, and those outside brushes are permanently apart of the map unless someone does a full reconstruction without those outside brushes. But, I'm just gonna keep it as similar to the base as possible. If I find some discrepancies between base Outcast and this version I'll attempt to fix it, but for now I'm happy where it is.
  23. Ok, tested it in base, it displays the exact same behavior, so I know its not an issue with the mod. I'll attempt a merging of weatherzone entity brushes and see how that goes. @SomaZ thank you for helping me understand this, I could've been chasing the wrong idea multiple times if not for your insight.
×
×
  • Create New...