Jump to content

Dusty

Members
 View Profile  See their activity

  • Posts

    672

  • Joined

  • Last visited

 Content Type 

Everything posted by Dusty

  1. Dusty
    Perhaps instead of a branch of Jedi Academy enhanced, the mod would work better as a fork of it, for easier maintenance and synchronization?
  2. Dusty
    I edited the main post. I relayed some of my knowledge of Jedi Knight coding as well, hopefully I haven't made any glaring errors?
  3. Dusty
    Kewl. Maybe if we have enough non-code SP mods we could split that section up further. So its easy to find things.
  4. Dusty
    ^topic
  5. Dusty
    Can you post the parts of the file you changed? Sometimes if I can't remember exactly what I edited I use the GitHub Desktop application to help me look over any changes I made to a file, as it gives me a comparison between my own local edits and the older version of the file.
  6. Dusty
    ^I didn't look at your code yet, so maybe you already did this... wouldn't it be best just to use an array? No new code would have to be written. It could just be a more specific version of g_entities. I'm assuming it wouldn't be very memory intensive especially if it just held pointers and not the actual entities themselves. Quick recap to anyone reading this topic for help: g_entities is an array of entities maintained by the game listing all the active entities in the current game session. The player and NPCs are entities that are also clients (therefore ent->client would be non null). To figure out where your client of interest is kept in g_entities... put a breakpoint somewhere where you will have a pointer to the ent of interest (in this case our NPC). Then look at the information stored in that ent for s.number, and that number will correspond to the array index. So... lets say I have a pointer to some entity called ent which I know is a stormtrooper NPC. I will look in ent->s.number (you should be able to see all this in the locals tab if you put your breakpoint in a good spot). The number I see is say... 135. Then at g_entities[135] should be that stormtrooper.
  7. Dusty
    Both of you gave helpful answers, but Razor was first. On a side note Eez, isn't calling to an external library (std) a bit iffy? Wouldn't it be better to internalize the vector stuff into q_shared or something like that? (But then again, any std code might be pretty complex unless you wrote your own homecooked vectors...)
  8. Dusty
    The list of clients being composed of the player (client 0) and NPCs (clients 1 and up). I'm sure it's somewhere but I have not come across it. It would be helpful for debugging if you could keep tabs on a particular client throughout their lifetime in a game session.
  9. Dusty
    The most drastic changes are cvar'd. Some of the code (like the NPC stuff) isn't cvared though. When I said your mod is like mine, I guess I just meant that it sounds like a gameplay improvement mod I guess
  10. Dusty
    Update 12/16/16: I want to expand and improve this article. As it is it's kind of a vague outline based only on my own limited knowledge. The purpose of this guide is teach how the source code of Jedi Academy and Jedi Outcast is structured, especially concepts that are not immediately obvious by just copying and editing the code. Please help me improve and correct this article by posting below with anything you think might be useful. Helpful Resources: IOQuake3 Wiki: http://wiki.ioquake3.org/Game_Development Contains a lot of useful information directly relevant to Jedi Knight coding. It explains a lot of conventions like entities, vectors, and the internal libraries (the Q functions) used by Jedi Outcast, Jedi Academy, and originally Quake 3. I highly recommend at least skimming this section and the main page linked above for anyone who wants to get into coding for OpenJK. Technically this is the wiki for a Q3 modification called ioquake3, like OpenJK except for the original Quake 3 game. OpenJK SP Coding guide: https://github.com/JACoders/OpenJK/wiki/Singleplayer-Overview Explains some concepts of how the Single Player game code is structured in OpenJK. Describes how to switch between JK2 SP and JA SP using the shared jasp executable, how networking support works in SP, a little bit about how to add new values for save games. Coding Tutorials Section on JKHub: https://jkhub.org/tutorials/category/1-coding/ Many helpful guides here if you are just getting your workspace set up or trying to do something specific. A few of these are referenced below. Overview: This guide to help people jump into making code modifications for Jedi Academy and Jedi Outcast without getting lost or confused. We strongly recommend using OpenJK to make SP and engine mods, and JA++ to make JA+ or general MP modifications, and this guide assumes you are using them. If you need to setup OpenJK for compiling, check here for a step-by-step walkthrough. This guide also assumes some basic knowledge of programming, but if you want to get your foot in the door with learning C/C++, check out this guide written by Eezstreet. If you are brand new to modding these games, keep this in mind: Jedi Knight II: Jedi Outcast (JO) and Jedi Knight: Jedi Academy (JA) both have two parts, Single Player (SP) and Multiplayer (MP). The two parts of the game are similar but they have their own code files and executables, and are written in very similar but different languages, that is, SP is written in C++ and MP is written in C. All you probably need to know is that C++ almost entirely contains and can be used to write C but has many new features, syntax, and external libraries added, some to replace old C functions. At this point, you may be wondering even with this guide, how will you ever find your way through this giant crazy mess of source code that is Jedi Academy and Outcast? Look at file names, and use the search function of Visual Studio. It is your friend. Raven writes a lot of comments in their code, and the functions and files are all named according to their purpose. If you've ever modded these games before outside the code, just try searching keywords like Class_Imperial or WP_BLASTER or FP_PUSH (the list goes on and on) and you'll get tons of hits. General Code structure --- The code of both Single and Multi Player is organized into client and server side; client-side files a cl_ (this is the .exe in SP) or cg_ (the cgame/client-game code), and server-side code has the g_ prefix . Files with code that is shared between the cgame and server game code start with the b_ or bg_ prefix. What effects does this have? Multiplayer: when you edit a bg_ file you must compile all projects/DLLs for the game to run properly (that means cgamex86, jampgamex86, and uigamex86 DLLs). You can also separate the code for clients and servers; clients don't necessarily need to have server code, and vice versa. Some mods like JA+ can be played without a client-side plugin. ClientThink (which calls many other gameplay functions) is called whenever a packet arrives which could be multiple times per frame, unless g_synchronous clients is set to 1. The G_RunFrame call tree is only called once per server frame (server fps is determined by sv_fps). SP: the game is actually run as if it were a multiplayer game in some ways, with the Player and NPCs actually treated as clients in the code and the gameworld and gameplay mechanics treated as the "server". The jagamex86 DLL contains the cgame and server game code, and the executable is called the client and it contains the UI/menu code. When the game loads up initially only the executable (and renderer DLL?) is loaded. The jagamex86 DLL is only loaded when you start a gameplay session by loading/saving/starting a new game. Other things to keep in mind are that the player is ALWAYS client number 0, and this is often used to separate code that the player uses from that of NPCs. ClientThink (the exact name in SP is ClientThinkReal or something similar) that is called every frame for every client as long as that client has a BSTATE that can be executed. Also worth keeping in mind is that with OpenJK, Jedi Academy SP and Jedi Outcast SP share the same executable file. More detail to be added later. Internal Libraries --- If you look through the source code, you might notice two things... some functions that start with Q_, and that nowhere in their code does Raven include or make calls to external libraries you might be used to using (like vectors or the C++ string class). The Q_ functions are Raven's versions of the functions normally included in the standard library for C (for example Q_strcat is their version of the strcat function in C), therefore most of these functions will have the same or a similar name and usage to a C function. Why did Raven write their own internal library? This way, they don't need to to import any libraries into their game logic code, nor do they have to worry about changes to an external library affecting their game logic code. In OpenJK, there is some support for external libraries from the STL, like std::vector. Can anyone add clarification for which libraries are supported? Look up C functions here: http://www.cplusplus.com/ (Don't let the name fool you, they have all the documentation for C as well, and C++ contains 98% of C anyway) Entities --- These are the meat of the game. These are the same as entities used in maps; that is anything from a button to a door, to an NPC or the Player(s). As previously stated, Players and NPCs are a special kind of entity that is also a client; this is true for both Single and Multiplayer in JA/JK2. In Single Player all entities are stored in an array called g_entities. (Can anyone confirm for multiplayer?) The index of the array where a client is stored in g_entities is equivalent to s.number. Example: I have an entity called ent that is a stormtrooper, and ent->s.number is 104. Therefore that stormtrooper will be in g_entities[104]). The player will always be stored in g_entities[0]. More info here. Vectors -- If you've taken a high school physics class, you should know a bit about what these are, but I'll try to explain anyway. Vectors are lines that have a length (or magnitude), a position (in x y z coordinates) and also a direction (in x y z values) in a 2D or 3D space. They can be used to make boxes or shapes (like for example, a rectangular box for collision detection around a lightsaber blade). These are used by the code to test for: collision, for a clear path to or line of sight, how close/far away something is, and probably more. The main type used in Q3 is vec3_t. Raven has their own functions to do vector operations like adding, subtracting, and dot/cross products which make vectors useful. More info here.
  11. Dusty
    Sounds like Dusty's Patch JK2 edition (however I suggest having a better name that doesn't have your own name in it )
  12. Dusty
    More information about ""
    Fixed a few things I forgot in the file description. Sorry I keep taking down the file.
  13. Dusty

    Fork Megathread

    Dusty replied to eezstreet's topic in OpenJK

    https://github.com/DustysPatch/OpenJK This is the code for Dusty's Patch for JASP. Basically a single player gameplay improvement/enhancement mod. It contains code only for jagamex86, rdsp_vanilla, and the SP exe.
  14. Dusty
    I've done enough JA coding to know that Eez. Red didn't do everything for me Basically it could be a branch of your mod and maybe instead of having 3 under-used forums for my mod I could just have one sub-forum for it under the JK: E forums.
  15. Dusty
    More information about ""
    I would imagine it wouldn't be too difficult to add more single saber styles to duals and staff, however I think it would be kind of difficult to let the player change between duals AND staff. At least difficult enough for me both coding-wise and design-wise that I don't feel like figuring it out For the NPCs, I want to try and make it so you can set whether they can use kicks and karate in melee, and karate with the saber like kyle boss. The saber karate is easy since the game already supports it for NPCs, but right now I'm mainly trying to get them to be able to do melee kicks and katas like the player can, which I'm having trouble getting to work.
  16. Dusty
    More information about ""
    I'm adding a few optional fields to npc files. One is called restrictJediPowers which keeps npcs that are using sword/jedi AI from using certain abilities without the proper force powers (dodging sniper shots without force speed, pushing out of grip locks without push). The changing weapons would be interesting. In general NPCs could use better multi-weapon support. Right now if you give them a few weapons and then pull one of their weapons they won't switch to another weapon.
  17. Dusty
    No, but it would be nice to make them compatible with each other I think.
  18. Dusty
    Maybe my mod could become a sub-mod of this? Code-wise I could #ifdef things. And then any assets I've created/altered could easily just be optional downloads.
  19. Dusty
    Unfortunately not at the moment.
  20. Dusty
    In Dusty's Patch (so corny naming the mod after myself ) you kick by default with every saber type but you have to bind +forcefocus to a button and hold that down to do saber throws. That was the best I could come up with.
  21. Dusty
    More information about ""
    Scrolling saber styles... sounds... complicated. What do you mean by your other ideas? That last one I understand, make an NPC that can use melee katas like boss kyle right? That's a cool idea. I would like to merge this mod with JA Enhanced. Maybe redsaurus could help me with that. That's a really good idea. How about this: Class_Manda is a boba fett without undying. Class_Commando acts like boba fett but without undying and without the jetpack or flamethrower. I talked to eezstreet who's both a more advanced C/C++ programmer and more of an expert in the code framework, and he basically said that the AI is almost exactly the same in the code for JA and JK2, but that its due to poor waypointing in the SP maps that NPCs aren't as "smart" unfortunately.
  22. Dusty
    Personally, I find JA very unfriendly to animation mods. For example most animation mods are incompatible without making a new mod that combines them. Then there are other things, like the fact you must always start a new game for animations to take effect... I have a list of proposals, that I think would make OpenJK way more friendly to animation modding: 1. **Allow multiple .gla files to exist**. And allow specification of which .gla to load frames from for an animation slot in the animation config. Current style: BOTH_A7_KICK_S 1008 34 -1 20 My proposal: BOTH_A7_KICK_S 1008 34 -1 20 spinkick This would load BOTH_A1_BL_TR from spinkick.gla in the _humanoid folder. Otherwise it would default to _humanoid.gla 2. **Allow multiple config files to exist**. Sort of like with pk3s, the last loaded config file will take priority for controlling the properties of any animation slot it defines. An example _humanoid folder: animation.cfg (in animation.cfg: BOTH_A7_KICK_S 1008 34 -1 20) spinkick.cfg (in spinkick.cfg: BOTH_A7_KICK_S 0 27 -1 45) The properties of the definition of BOTH_A7_KICK_S in spinkick.cfg would take priority over the one in animation.cfg in this scenario. 3. **Separate config and animevents files for SP and MP**. More compartmentalization this way. Any files with a _sp suffix in their name (i.e. _spinkick_sp.cfg, animevents_sp.cfg, animation_sp.cfg_) would take priority in being loaded by Single Player, and would be ignored by multiplayer. That way old mods still work, but you can make mods that are specific to one side of the game. 4. **Other things that could use addressing**. You shouldn't have to start a new game to get an animation mod to work. The bug where looping animations played in reverse tending to get stuck could use fixing. Also, it would be nice if you could specify in the animation.cfg whether an animation should be played only on the upper body or lower body (but maybe that's asking too much). I understand most or all of these would break save game compatibility. This new animation system could just be ifdef'd in that case. But even then, animation mods by nature break save game compatibility, and people can just use cheats to remake their savegames. If I am completely honest, I don't see why that's such a big deal.
  23. Dusty
    More information about "Dusty's Patch: Jedi Academy SP (Test)"

    440 downloads

    Updated 7/11/16: The animations mod must now be downloaded separately (to avoid legal issues?). I also realized I made some mistakes in the installation instructions in the readme. If you are having problems I suggest re-downloading to make sure you installed properly. Other small fixes to the documentation. Warning: This mod is not compatible with existing save games. Just use cheats to remake your savegame. This is a test run for a modded Jedi Academy single player. All the features are code-side except for the animations (download Dusty's Patch: Animations to get them). The code uses as a base the OpenJK build that existed at the time of release, so if your system has issues with OpenJK, you most likely will have problems running this. Feel free to report issues, give feedback, or suggest features. Remember though, I'm just one person. Changes from base JA/OpenJK... New Cvars ------------------------------------------------------------------------------------------------------------------------------ g_autoRoll* - default is 1, if 1 default JA behavior, if 0 you have to be holding USE to roll g_char_forcePowerMax* - requires level restart, controls number of player force points g_char_forceRegen* - requires level restart, controls force point regen rate of player g_char_parryBonus* - same as .sab file setting but applied on savegame load for player g_char_breakParryBonus* - same as .sab file setting but applied on game load for player g_handicap* - can go up to 200 now g_saberDamageScale* - this scales saber damage, and is saved with your savegame. This effect stacks on top of the effect caused by g_saberMoreRealistic. g_saberDeflectAutoAim* - if 0, blaster deflections are not auto-aimed but go in the direction of the crosshair with randomness based on Saber Defense level g_saberForceDrains - if 1 special moves drain the amount of FP from the next cvar, katas not affected g_saberForceDrainAmount - if g_saberForceDrains is 1, special moves drain this amount of FP, katas not affected g_saberLockSuperBreaks* - if 1 default JA behavior of saber locks, if 0 no super breaks (1-hit KOs) ever happen after saber locks g_saberMoreRealistic* - no longer write-protected g_weaponVelocity*, g_weaponAltVelocity* - use this to multiply the speed of most projectiles Gameplay mechanics ------------------------------------------------------------------------------------------------------------------------------ Force powers (activated with g_forceNewPowers 1) ------------------------------------------------------------------------------------------------------------------------------ - Force Jump height for all levels increased by 25% - Force Pull level 1 pulls weapons only, level 2 can knockdown, level 3 can pull toward you a little bit - ***Force Sense gives limited snipershot dodging ability (you might need to hold down Use) - Force Speed decreases FP cost of sniper shot dodging at Level 3 (for auto-dodging anyway) - **Force Protect 1/2/3 gives only 10/20/40% damage reduction against saber attacks instead of 25/50/75% - Force Heal costs slightly fewer force points at Level 3 if I remember correctly NPC AI ------------------------------------------------------------------------------------------------------------------------------ - Improvements to NPC AI pertaining to the use of JA-exclusive abilities... NPCs only use Force Rage if close to the player and if have > 25% HP, only kick if close to the player, only use katas if close to the player - NPC Jedi will try very hard to dodge your attacks if you knock their saber throw to the ground (before they were more apt to just stand there) - NPC Jedi get up much more quickly from knockdown on higher difficulties (no easy marios for the win) - NPC Jedi will activate their saber very quickly after being gripped or drained based on difficulty and rank - Force-only Cultists react properly to explosives, sniper shots, and saber throws now - Force-only Cultists will very rarely throw in a quick punch if you get right in their face - Non-saber wielding NPCs with Class_Reborn try extra hard to dodge saber attacks and throws (because they can't block) - Light Jedi with non-dark Jedi AI (class_reborn, class_desann, etc.) classes don't attack surrendered or unarmed enemies now at all - **Grenadier Grans will alternate punches/thermal detonators even if your saber is out if you are really close to them - **NPCs surrender more like JK2 (the animation is more consistent, once they decide to surrender they will usually stay surrendered) - Allied NPCs receive 150%/125%/100% HP for Padawan/Jedi/Jedi Knight difficulties now instead of 100%/125%/150% like enemies - Assassin Droids now fire even with their shields up - Class_Rodian with E11 and Class_Imperial at commander rank use alt-fire now always Saber System (activated with g_saberNewCombat 1) ------------------------------------------------------------------------------------------------------------------------------ - Saber Offense gives a base "attack power" (AP) (+2/+4/+6) - Saber Defense gives a base "defense power" (DP) (+2/+4/+6) and a number of block points (BP, is equal to 1 + your SD level IIRC) - "attack power" is modified by saber style (-2/0/+2/-1/+1/-1/+1 for Fast/Med/Strong/Duals/Staff/Tavion/Desann) - Desann style is as strong as Red if you are CLASS_DESANN, otherwise it does not cause knockdown as often as Red, and is slightly weaker - style attack chaining altered: can only chain 2 slashes if running, staff and duals cannot chain infinitely (5 slash maximum now), chain counts are also not random (Medium can always chain 5 slashes while walking for example) How saber combat then works: - AP > DP = attack blocked but lose a number of BP equivalent to AP - DP - all BP lost = guard crushed - BPs regenerate about 1 per second if walking/standing still (total BP = your Saber Def. level + 1 if I remember correctly) - special attacks ignore BP: either crush guard or are blocked partially Other saber-related changes (always active regardless of g_saberNewCombat) - player's ability to parry saber attacks and blaster fire is improved while walking or standing still for Medium and Strong styles - Saber Defense 0 no longer causes blaster fire to pass through the player - A saber with autoblocking 0 now has a very narrow blocking arc for the player (so you can't cheat and block super easy) - Holding Use and standing still will let you try to manual block blaster bolts as it currently does in Base JA, however the arc is super narrow Melee changes -------------------------------------------------------------------------------------------------------------------------------- - Player can use kicks with any saber type by default, you must use +forcefocus to saberthrow (bind this to a key, maybe your mousewheel click-down) - Player's melee abilities determined by Saber Offense level (1 = punches and kicks, 2 = katas, 3 = spin kicks) - if you're not cheating (using g_debugMelee or iknowkungfu)... Player melee katas have less range, must be aimed more precisely, and do not work on certain types of enemies - Spin/Flip kicks are only enabled for Saber Offense 3 but do slightly more damage - Spin Kicks are possible on demand by holding Use and pressing the Alt Attack button, however costs 10 FP (the auto version doesn't cost any) - **Knockdown from a kick to Jedi happens only if your Saber Offense >= their Saber Defense - Player punches do 7/5 damage now instead of 6/3 and aren't randomized - **Force Speed punching is more consistent now and less cheap (never did actually test) - **Heavy/Slow Melee punching is specifically associated with Chewbacca, Class_Gran, and Class_Trandoshan, other NPC types will punch more quickly but weakly if given WP_MELEE Other additions ---------------------------------------------------------------------------------------------------------------------------- - visual effect for blocking Force Lightning with your lightsaber (it's subtle but there, it just plays a reverse-direction version of the Lightning level 1 effect, will make this a separate file) - rolls and acrobatics are possible in 1st Person now Future ideas ---------------------------------------------------------------------------------------------------------------------------- Things to do - - *savegame screenshots - *separate cvar for player HP and Shields - reborn masters with debounce to limit constant saber throwing + lightning - *NPCs avoid cliffs - *extra fields in Weapons.dat such as NPCDamageMult, NPCAltDamageMult, saber ignition/deignition time - force push strong version, mindtrick changes - doing a full slash when starting saber off regardless of movement - *camera controls (1st, 2nd, 3rd, 4th person) - better AI for NPCs deciding to surrender * would like to implement into OpenJK ** not completely tested but should work *** incomplete/unfinished/not working completely
  24. Dusty
    Besides the projects for the game's code, there are so many others are included! They are... Assets, ALL_BUILD, ZERO_CHECK, INSTALL, PACKAGE, bundled_libjpeg, bundled_libpng, bundled_minizip, bundled_zlib, GetExeSymbolDir, GetPdbSymbolDir. I tried generating the solution without some of the default options checked but I would get errors when I would do that. There didn't use to be so many projects! Are all of these necessary to compile OpenJK without installing any extra libraries?
  25. Dusty
    So usually nav mesh doesn't need to be explicitly set up by the mapper? In that case that sounds really cool. My apologies for not understanding sooner.
×
×
  • Create New...