Futuza

1. So it depends on which starting weapon you use, the free one is slow on purpose because its supposed to be a sorta crappy. Other pistols are much quicker and have faster projectile speeds though, for example the Q2. Fights also tend to go a lot quicker the more people playing, so the initial pistol dueling phase tends to end a lot quicker when playing with larger groups of people. Many of the pistols actually have limited range just fyi. 2. Yeah I like that, I'm not sure if the engine will currently support icons with how we have the ui setup at the moment, but if not we could at least have text description. 3. Agreed the z-6 jetpack is overpowered, I'm working on getting some more counters to the jetpack. For example, making armor slow down speed/drain fuel faster, electrical weapons cancelling out jetpacks, etc. I don't think we'll go with the jump option though. Did you try the burst jetpacks? They work quite differently from the normal ones. 4. Unfortunately (See Silverfang's answer below) the default map is part of the original game so we can't change it up much, that said it'd be cool to see an expanded bespin map with more routes.

Oh neat. Nice work, should be interesting.

Just wanted to add that if you need more technical details for any of the menu stuff not covered in the basic tutorial, JKA's menus are basically identical to the one's listed in the Quake III documentation located here.

Sat, Oct 3 UTC 6:30PM(18:30) we will be holding a Community Scrimmage Match for fun. Additional matches will likely be held throughout the day depending on how long the community wants to play for, so if you can't make that time others will likely be playing later that day. If this is your first time trying the mod, go here to download it. Countdown: https://countingdownto.com/?c=3243617

Curious if collaboration/group entries are allowed?

Introduction: This topic means to propose the Rumor Gathering system, the developers have discussed this briefly before and I'm bringing it back up. This is for Phase II/Phase III. Q: What is Rumor Gathering? A: It is a system we will put in place to help with two things mainly: 1. Dynamic Quest requirements, helps quests be different every time while also being able to hide certain types of requirements. 2. Workload, we want dynamic quests without too much work. Basically, in summary, it allows certain dynamic NPCs conversation trees to only be explored if enough Rumor has been gathered, instead of specific bits of 'rumor' we just give out generic rumor "points" in different categories, and require a certain amount per category to allow the dialogue option to appear, otherwise the player will not see it until enough rumors have been collected. There are several possible "sources" of rumors: npcs, holocrons, holonet, books, certain quest objects, etc...it might even be possible to let players spread rumors for us! The System Categories There are a total of 4 main categories (I could think of), that we could have rumors for: Skill Rumor Knowledge Faction Rumor Knowledge People Rumor Knowledge Places Rumor Knowledge Each of these contains subcategories of their own. eg: Skill: Force, Weapons, Armor, Miscellaneous Faction: Imperial, Rebel, Local factions, Black Sun, SorruSub, Jedi Exiles, Smugglers, Miscellaneous Groups People: Local Persons, Notable Persons (ie: Emperor Palpatine, Grand Moff Tarkin, Senator Organa, etc...) Places: Tatooine, Dantooine, Taris, Korriban, Miscellaneous Locations (instances, etc) How to acquire Rumor Knowledge Find a "source of rumor" (ie: barkeeper, book, drunkard, terminal, etc...), and then begin using it or conversing with it. Eventually after exploring the correct dialogue choices, or merely by interacting with it it will increase your rumor points (usually in specific categories, but this could be randomized as well). Mostly likely implemented via a luascript/cmd. Rumor Points Rumor Points are a way of keeping track of the total amount of Rumor Gathering the player has done. Rumor Points are added each time you obtain a rumor. They can be found on one's datapad. By looking at the datapad a big list of rumors that the player has uncovered will pull up. Only special rumors will actually be listed here. Most rumors, simply give you rumor "points" and won't actually have a rumor entry in the datapad. These special rumors will be organized by date, by default or category. Often times rumors don't in themselves contain anything, but generic information that the player already knew. The player may sometimes acquire duplicate rumors, but never from the same source. We may wish to also have a large list of generic rumors by subject for all possible rumors, similar to treasure classes which could be assigned to as a list for the game to pick from when a rumor source tries to generate rumors from a certain category. Rumor points can also be negative. -Example of Rumor Point format for a "special" rumor (these are separate from just general rumors, that simply give you points): Rumor: "Heard a rumor that there are no Jedi's left in the galaxy, and the force can no longer be used." Category: Faction Knowledge, Jedi Exiles. Source: NPC Jankins, Tatooine Rumor Points: -2 Jedi Exiles Rumor: "There is a mad hermit with supposed magic powers, near Mos Eisely". Category: Faction Knowledge, Jedi Exiles Rumor Points: +5 Jedi Exiles As you can see rumors can provide positive or negative values of rumor points, so picking up rumors from the wrong sources (consulting Imperials that don't believe in Jedi's, when you are trying to find one), will hurt your overall point score in that subject (however it may be boosted in others, such as your increase in knowledge about Imperials). Players cannot see what the actual point values are for each category, this is a mystery to them. However, they see bars for each section go up and down, but without actual values presented and just a general indicator that a rumor may have made a change to their overall knowledge in that category. Having a full bar in a particular category typically means that the player knows all there is to know about that rumor subject. So let's see a whole example, without "special" rumors. Player A is trying to find more information about the Jedi Exiles faction. First he talks to an Imperial officer asking about an Imperial outpost. The Imperial knows nothing useful about the Jedi Exiles: Imperial: "How can I help you, citizen?" Player A: "How big is the garrison here?" I: "*sigh* "Almost 200 strong, we badly need reinforcements." P: "Why, been attacked?" I: "No...*sigh* smugglers, thieves, slavers, they all slip through we've never been attacked since all the Jedi Rebellion years ago during the end of the Clone Wars. We have nothing to fear. But smugglers are certainly frustrating." P: "Well I wish I could help, but I haven't the time right now. Good luck." This NPC then gives out some rumor points (objects will need some function added to them to incorporate this). What factors into the rumor point distribution: 1. How long the player conversed with the source. (How many total tree nodes we're explored from the total branches)? 2. Random Factor. 3. Limits set on what kind of rumor points the source can give out. 4. Amounts of rumor points already given out to this player from this source, as well as certain special rumors may require special cases. So in this example the Imperial could have given out any rumors pertaining to Local Imperial Knowledge, or give negative points for the Jedi Exile. ie: +1-2 points in Imperial, +3-4 Imperial, +4-5 Imperial, -1 Jedi Exiles, or +1Local Tatooine. You would likely get the +4-5 Imperial if all tree branches of that NPC had been explored. However, the random factor may still make you unlucky and give you something worse (-1 Jedi Exiles). Typically we'll only do this type of rumor point generation on npcs who do not have tree dialog (eg: they say one thing when you interact, but that's it). NPCs with dialogue trees will probably have custom rumor points given when certain dialog trees are explored. How Rumor Points will be Used Certain NPCs may only begin certain dynamic dialogue options, when the persons rumor points in a certain category are a minimal amount. Quest creators can then set certain dialog trees as being locked until the player has enough of certain rumors. Rumors represent the players efforts to essential uncover truth and will go up (or down) as they learn and gather information in the world. For example, our Imperial gives out negative Jedi Exile points because he is under the wrong and false impression that there are no more Jedi left, since Order 66, despite the fact that there are still Jed out there. Hence by denying the Jedi Exiles existence to do so, because the player may or may not be effected by the belief (simulated by a random selection). Merely by consulting a untrustworthy rumor source, the player runs the risk of decreasing his faith and belief that the rumors he has heard about that topic are actually true. Rumor Source Format Most rumors don't get put in the datapad, only special ones the writers actually want to bother writing and attaching to a particular source (quest NPC). The rest of the rumors simply add rumor points to your rumor knowledge or take it away. So again with an example with the Imperial his object file would go something like this (using pseudo json): { //Example Imperial #245 //Location of NPC: Tatooine, Mos Eisely, coord: 2, 5550, 323 "Name": "npc_imp_245_ex", //name of the object using the rumor property "Source": true, //Is this a source of rumors? true/false "Special": true, //Is this a special rumor source? "Multiple": 0, //Can this source give out more than one category rumor point at once? "Timeout": 1440, //How many minutes does it take for this source to- //-time out before it can give out rumor points again? "Categories": //start of category definition section [ { "Type": ["Imperial"], //What type of rumor point category is the first type? "Max": 5, //What is the maximum amount of points to give out? "Min": 1, //Minimum? "Weight": 50 //0-100% How often should this choice be chosen? (50% of the time). }, { "Type": ["Jedi Exile"], "Max": 0, "Min: -1, "Weight": 25 }, { "Type: ["Tatooine"], "Max": 2, "Min: "0, "Weight": 25 } ] } Other Specifications The system would also in addition to previous information, need to track to see if that "rumor" has been given already and if not allow the player to basically spam mine rumors unless it has already been given to the player. For example once Player A has spoken with Imperial_245 he is not going to give the player any more rumor points until after the 1440 minutes are up (24 hours). Some rumor sources never timeout and are only found once. Other NPCs give out multiple vague rumors and have timeouts so the player can collect new rumors from them after coming back latter. Likely these timeouts would be between 8-48 hours, this will prevent the grinding or mass spam "mining of rumors", at least from one rumor source. Some NPCs can even have multiple requirements for dialogue options to appear. ie: More than one category, or total overall rumor points. Others may require special rumors to be found from specific sources (ie: holocrons, instance npcs, etc...) [ b]Further Development Ideas (please respond with your own ideas!)[/b] - allow players to spread their own rumors? ie: if player is part of a certain faction, speaking to that player basically via chat will allow a chance to pick up rumor points covering that faction. Could run into problems if players start advertising they can give out rumor points or something and then stand all day in the city spamming everyone and giving them rumor points. -Every rumor point adds some bit of random Starwars lore in the datapad that slowly gets unlocked? -Allow player to know that rumor knowledge has been acquired. For example a, "rumor" sound effect, or a popup dialogue box similar to the darkside/lightside point boxes in KoToR. We could also in the quest log add a piece of info that says something like, ""Obtained hearsay from npcs so & so, about Jedi Exiles". -Bonus from rumor points in that skill. For example if you have lots of rumor points in Skills: Force, you get increased force points, regeneration of force points, etc..? -Skill that can be learned to increase the rate or amount of rumor points you can receive from npcs. ie: X2 Rumor points, etc... -Allow players to 'share' rumors. So for example Player A can select one player to share a rumor with. Once the rumor is shared it cannot be shared with anyone else, however, Player A can still share other rumors he hasn't already shared with the same, or different players.

So we've recently been talking a little bit about NPC design in the Discord, so I thought I'd make a discussion thread about it so we can have a place to keep the ideas around. There should be a couple of things to keep in mind regarding NPC behavior and purposes that I want to talk about first, especially in regards to their goals and purpose in the game. Most of this deals with Phase 2 and later design, so just assume we're talking about that phase here, since NPCs will have little to no use in Phase 1 (as of right now). I'm going to discuss some of my thoughts on the design, but want to hear feedback from other players/developers. NPC Purposes in JKG I think its helpful to review NPCs from a gameplay design aspect. Why are NPCs in JKG? To serve as facilitators of items. Some NPCs produce items and you can trade with them to acquire new items. eg: A shop vendor can sell you a new e-11. To serve as facilitators of skills/abilities. Some NPCs can help players unlock new skills/abilities. eg: An npc craftsman can help a player unlock the craft items skill so the player can then craft items. To serve as distributors of quests/missions. Some NPCs can help players learn about new things and give them things to do, they can also help move the story along. eg: A caravan guard on Tatooine might ask you for help when they get stranded by a Krayt Dragon attack. To serve as obstacles and antagonists, that make quests/missions more challenging and interesting. To serve as helpers or allies, that make quests/missions easier, interesting, or even more challenging. To help fill the void of a server with the semblance of life and add to the game's atmosphere when other player's are not around. Given these primary reasons, it makes sense that we should probably optimize/design NPCs around these goals. Not all NPCs are equal, and its fine to disable certain features with some NPCs to optimize. For example, shop vendors probably do not need to serve as obstacles or antagonists so they shouldn't have the overhead of trying to figure out how to kill a player like a stormtrooper might. Some NPCs should probably have scripted actions and not need to do anything other than follow a script. Others should be more dynamic and self determining. All NPCs should have a couple of different universal ways they might interact with a player: +use on an NPC will open up a dialog with the NPC as long as the NPC is not currently hostile to the player, or is not a vendor that the player has interacted with previously. There should probably be a check that goes something like: if(npc.attitude == HOSTILE)//doesn't like player, won't talk to them {return;} if(npc.quest.dialogflag == -1) //dialogflag: -1=talked to, no more interactions, 0=never talked to, 1=dialog available, 2=quest/special interactions, etc. { //do default npc action here, such as a vendor opening his shop return; } //other npc reactions below Otherwise, the NPC would open up a dialogue with the player and the player can choose how to respond. All NPCs should have an escape dialogue choice available. This will usually be the last listed and would be something like, "Goodbye" or "[Leave]". This can always be called by pressing "ESC" to close out a dialog with an NPC. NPC dialogs should be designed so that the player can leave the conversation at any moment and pick it up later (in case of a client disconnect or player backing out, whatever). Other dialog choices would be based on the NPC itself. For example when talking to a vendor for the first time, they might introduce themselves and tell you that they can sell you stuff, and one dialog option would be to look at their wares. Most vendors, should probably only do this interaction once with each player, and then set their dialogflag to -1 (meaning that if you talk to them in the future it just skips straight to the shop screen). Quest NPCs would have additional dialog choices available while the quest is available, for example a stormtrooper might give you an option to ask him about how he became a stormtrooper, which would lead into a imperial recruiting quest. Attacking an NPC will probably be a little complex, but here's some basic ideas. First, make sure the NPC is actually attackable and if not, don't bother doing anything. For example, you shouldn't be able to kill or harm certain NPCs during certain points in the game. In general though, assuming the NPC is a valid target and currently friendly toward the player the following steps should probably happen. In general, while these principles apply to player vs NPC scenarios, they might also be applicable in NPC vs NPC scenarios. Lower the NPCs attitude value toward the player. Reduce it more significantly depending on the amount of damage done or debuffs applied. eg: A stun has far less severe consequences than lighting an NPC on fire does. Doing 100 dmg, lowers the attitude far more than 10 dmg does. This attitude value might be increased through other interactions with the NPC, such as healing it, talking to it, doing quests for it, belonging to the same faction as it, etc. Any nearby NPCs that have a visual on the player and the attacked NPC should also consider if they like or dislike or are indifferent toward the action the player is taking. For example, Darth Vader would like it if the player kills a rebel NPC, but dislike it if the player kills a stormtrooper and be indifferent toward the player killing a jawa. They should then lower or increase their attitude value toward the player. This would be far less significant than the effect of a direct attack. eg: 1 point up/down, instead of 20, etc. If the attitude value remains positive, the NPC should warn the player not to do that verbally/visually, but not do anything yet. eg: similar to the warn jaden sounds If the attitude drops to negative, the NPC will begin treating the player as hostile and any other player's he is currently on a team with. NPCs with a hostile attitude may do different things depending on the who they are. For example, a stormtrooper will probably just begin attacking the player. Not all NPCs of the same class should necessarily behave the same, see below for details. If the player attacked an NPC at somewhere other than neutral/no man's land, they should also be given notoriety points, just as they would with attacking a player. Hostile NPCs: When an npc becomes hostile toward another player it may do several different things depending on its class and personality. For example: A jawa might run away in fear. A quest npc, might fail your current quest/change the requirements. A shopkeeper might refuse to trade with you. Etc. Typically most NPCs will attack the player and their allies. However there are a couple of things to factor in, the NPC will need to consider a couple of things: Does it know where the hostile player/npc is? (Does it a visual within its range?) How long ago did it last have a visual on the target? Does it have a weapon(s) to defend itself with? And does that weapon have range to hit the target? Is it outnumbered? Is it outleveled? How many of its allies has the target already killed/attacked? What is its personality? NPCs should have the option of having a random personality generated with each spawn, this way every npc is slightly different with how they approach situations to some degree. Developers can script in certain restrictions so some NPCs always react the same way, but for most the default will be just random personality biases. For example while Jawa's might tend to be more on the cowardly end of the spectrum and choosing to flee or find cover when in a hostile situation, occasionally one might have the rare chance of being born with courage and thus fight to defend itself instead of fleeing. We would generate these similar to how treasureclass's work with items, where a set of ranges is specified for each npc class and the values generated for each behavior category being within the range specified (will talk about those categories later). After evaluating the above, the hostile NPC will most likely either try to flee or fight the player. Its personality and equipment will help determine its fighting 'style'. For example, if its more cowardly, it might try to snipe the player while ducking down beneath cover if it is a considerable range away from the player. If it is completely outmatched in level, equipment, and not brave, it will probably just try to run away from the player as far as it can get. If it has other allies and feels confident in attacking the player, they might try to work together to flush the player out of hiding, by encircling the player's position for example. NPC Personality Category Ideas, these would probably be variable amounts, eg: -100 to 100, or 0 to 100, depending on the NPC's value. The npc file would determine the range generated for each category, or use a default if not specified: <Brave-----Coward> (NPC will fight or flee) <Reckless----Cautious> (NPC will abandon self preservation vs prioritize staying alive. NPCs with high reckless values will have no problem dishing out friendly fire.) <Obsessive----Tactical> (How likely the NPC is to fixate on a specific target. eg: if the player who attacked them is part of a team, will they put priority on the player who first caused them injury while putting their allies/team as secondary targets? If the NPC is "tactical", the more likely the NPC is to switch targets based on tactical reasoning. eg: if it can't see/hit the original target it will switch targets. Regardless of this setting, if a player does excessive damage to the NPC (50+% of its HP), it will switch to a new target/fixation. <Prefers Range-----Prefers Melee> (How close to the player with the NPC try to get?) <Prefers Backup----Prefers to Solo> (NPC might only fight if it has a group, or fight regardless of allies). <Friendly Fire----Save Allies> (NPC will kill its allies if it has to vs always prioritizing saving its allies instead of the player) <Curious----Indifferent> (How likely the NPC is to investigate odd things. eg: If its companion dies, does it look for a cause or if it hears something odd, or does it ignore stuff) <Darkside----Lightside> (Which spectrum is the NPC on?) <Preferred Weapon> (Does the NPC have a preferred weapon, when given a choice. eg: if an NPC has a rocket launcher, an e-11 and a grenade which one does it choose if they're all in range?) <Loves> (Is there any entity the NPC prizes above their own safety? eg: Is the NPC assigned to protect a VIP, such as the player or another NPC, and puts their safety at risk to protect the target if necessary?) <Hates> (Is there anything the NPC hates above everything else? eg: Does it hate Tusken Raiders and will focus a Tusken over a player whenever faced with both?) We also need to talk about pathfinding/routing and how that should work, but I figured I'd let Xycaleth weigh in on that first since he's been playing with it the most.

Thanks to everyone for helping us play test this new version. The play tests have concluded, we found a few bugs and appreciate all the feedback everyone has sent us. If you have additional feedback feel free to post it in the Discord or here in this thread. A hotfix for v1.3.22 has been released to deal with the more serious issues encountered, but most of the changes based on your feedback will be implemented in later updates. Thanks again!

One match left! We had some good fun games and even found the cause of the last (hopefully) server stability bug we missed, also got lots of great feedback from new players and old veterans. Its been great so far.

Hello! The beta for v1.3.22 was just released and we need your help testing it. We have three planned test scrimmage matches this coming weekend (times are UTC): Thursday, July 10th at 10:00pm UTC Saturday July 11th at 1:00am UTC Saturday July 11th at 8pm UTC To get the latest preview build, go here (you'll want both map packs as well) . More news about the scrimmage will be upcoming, to stay up to date watch the Discord #announcement channel. You'll most likely want the map packs as well!

I have also now added an OSX binary for you Mac users out there. (Special thanks to Flate for helping me with that). Scratch that it looks like we built it wrong, getting it fixed will be reuploaded once its been fixed.

JKGalaxies 1.3.22a Released! Hey everyone, the next major release of Jedi Knight Galaxies is here! This is a full release so you will need to replace existing installs, and will need to download the new assets and binaries. A patch for v1.3.23 will likely be released in the coming in a few months depending on feedback from our next scrimmage match and any new features/bug fixes we manage to cram in by then. Read the change log below to see a summarized list of changes, there's a lot since our last major release! We will be also putting the release on ModDB (and other mirrors) in due time if you're interested in that. The easiest way to download the game is through our new website. Also for your information, we release test/preview releases much more often than we do with our major stable releases which is available at the bottom of the downloads page on the site. These are announced on the Discord, which you should totally join if haven't already =p. Thanks to everyone who helped test and create this version! Links are also provided below: Downloads >Windows: Assets | Binaries >Linux: Assets | Binaries >OSX: (not available) If you need help installing JKG, please visit this page for a helpful walk through tutorial of installing JKG. To build from the source code yourself, please refer the Github page. If you're on Linux, Flate's Guide will take you through the process step-by-step . Change Log We've been through a lot of bug fixes and new developments to get the game to the current state. Here's a summary of the changes. Changes included in v1.3.21 and v1.3.22 New Features Overheating System No more automatic blaster spam! Cross hairs will begin to redden as your weapon generates heat and will stop or slow down your ability to fire once it becomes overloaded with heat. You will need to wait for it to cool down before continuing to fire or switch to a new weapon. Many automatic blasters have received a significant nerf as a result. Medicinal Healing Pellets Load a slugthrower weapon with this bacta based pellet ammunition, it will heal your target as well as cure them of poison or bleed debuffs. Toxic Gas Canisters Load poison gas into a flamethrower in order to conduct chemical warfare against the enemy team. Warning: canisters fumes are deadly to breathe in when burned and will give you a poison debuff! Incendiary Slugthrower Rounds A special type of slugthrower ammunition that is capable of igniting targets it hits, applying them with a painful fire debuff. Loading Tips The game will now display loading tips while a map is loading. EMP Blasts Jetpacks (and in the future hopefully other types of equipment) can now be disabled via emp blasts from certain damage types (sonic, ion, electronic, ionblaster, etc). You must penetrate through a player's shield to effect them. Performance Analysis System A new performance analysis system capable of displaying processor, memory and other in depth system resource usage is available with the /perf 1 command. The tool is still in its early stages, but will be expanded on more. New Map Pack! The Jawa Fortress by Yzmo, features a twisted cave complex the Jawas, native to the Tatooine desert, are currently defending from invading Tusken Raiders. The Mos Eisley Arena a perfect map for one on one duels, or insane team fights in a narrow enclosed arena, this map features a small part of a larger map that will be available in Phase 2. The map was initially created by MaceCrusherMadunusus with tweaks by Pande and Futuza. The Imperial Base map by Noodle features a rebel attack at small Imperial facility located on a very rainy planetoid. Both Mos Eisley Arena, Imperial Base and the Jawa Fortress have ctf modes available as well. Other Improved and fixed ammo overrides, buffs and debuffs are now properly applied. Some new ammo types added as a result. When browsing for servers, the "internet" source will combine all master server lists into one, rather than only pulling from Raven's (thanks to OpenJK for this fix). Only certain types of jetpacks can be activated while carrying a CTF flag (this also plays a sputter sound to indicate it won't activate - sounds based on MWLANDI's gas stove recordings. Shields will now protect you from being stunned while they hold a charge. Death message improvements: centerprint messages restored, more improvements to come. New refined-heal debuff (removes poison and bleed debuffs and has higher healing rate). Vendors announce when their stock is replaced (new cvar: jkg_announceShopRefresh, set to 0 to disable, defaults to 1). Civilian vendors can now have custom upset messages (such as when you don't have enough credits to purchase a weapon). Jetpacks can now be activated with the assigned aci button (eg: press 8 on keyboard to use jetpack on aci slot 8), as well as while in the air like before. Jetpack's and shields now autoequip themselves if you don't already have one equipped. Added the missing Jawa icon from WizardMKBK's pack available here on JKHub. Improved certain system messages to make issues such as attempting to sell a starter weapon more obvious to users. When a weapon exceeds maxHeat, it will need to cooldown to less than the heatThreshold value (default 75% of maxHeat), before you can fire again. The ambientHeatRate key value was added for use in a map's entity/worldspawn data and controls jkg_heatDissipateTime meaning that a map's ambient temperature can affect how quickly/slowly weapons cooldown when generating heat. You will also hear sound events hear associated with each of these events now as well (see below for credits). Bug Fixes and Balance Changes Balance overhaul: extensive changes intended to better balance overpowered weapons and give less used weapons more incentive to buy them. Adjusted several clip sizes, and ammo costs. Fixed LJ-70 Beam Effect. Fixed no damage area bug. Fixed missing textures/shaders in some maps. Simplified damage code to reduce bugs. Fixed bug in dodge rolls present in v1.3.19's initial release. Nerfed dlt 19 sniper to do less damage. Jetpack's fuel gauge auto fill when you spawn (no more waiting to charge them up). Simplified pay commands, you must have earned enough credits to actually be able to share credits with others (doesn't including your starting credits). Fixed shield spillover damage, that was causing bizarre healing damage. Removed extra damage done to armored opponents with ion damagetype. Adjusted some shield prices and stats for better balance. Increased damage to shields (and droids) when using electrical based weaponry. Reduced the slow effects of armor so it isn't quite so drastic. Fixed vendors attempting to autoequip items they sold. Fixed bounty split reward code, improved performance. Buffed the flamethrower slightly. Buffed arc casters slightly. Fixed autofiring bug for weapons that consume multiple ammo counts, when the weapon's clip is partially depleted. eg: DXR-6 Reduced ammo costs in general, especially for blasters and pistols. Reduced price of certain trip mines. Reduced max stack size on bacta consumables and some grenades. Shader's for certain effects such as poison no longer viewable through walls. Bounty Code Bug Fix and Optimization. Fixed bug with fallback vendor sounds, and added new sounds for new types of vendors such as Jawas or sand people as well as new gangwar team definitions for them. Fixed crash on npcs checking for shields when null. Fixed crash with consumables. Fixed ammo price calculations and labels, shop now charges reasonable amounts and doesn't lie about the price anymore. Underdog bonuses for ammo price reductions has been disabled for the time being, until they can be properly implemented in a future patch. Trip mines won't blow up on teammates on anymore. Fixed possible jetpack crashes due to sound issues. Firing mode labels have been fixed on various weapons that were missing it or had incorrect labels. Fixed obituary messages so team changes don't count as suicides anymore. Fixed bug where non-client objects (such as trip mines or glass), could no longer take damage from missile based weapons. You can shoot trip mines now, Ivan. Fixed bug where players could switch weapons while cooking a grenade resulting in funny things, like deleting the wrong item stack. Fixed bug where maxHeat was not set per weapon and all were based on 100, rather than individual weapon maxHeat values. Fixed a bug where heat could become less than 0. Fixed bug where heat values were not initialized properly when respawning. Fixed crash when npcs were targeted by EMP blast weapons. Fixed crash caused by allowing a firemode/saberstyle change while dead. Various other stability and quality of life improvements, see commit logs on Github for details. Audio Sound FX Credits Several new sounds were added to the assets to facilitate current and future development. Most are not yet in use or didn't quite make the cut. The new audio fx were based on or inspired by the following sources, in addition to public domain and self created audio: Changes included in v1.3.19 New Features Dodge Rolls By rolling you can mitigate some damage types by correctly timing your roll. Damage is reduced up to 15% if you roll out of the way. Glua damage system overhaul Script damage is now much more customizable with glua tie ins to the engine (see spice item for test) Bug Fixes and Balance Changes Improved treasure class selection Exploit: no more infinite ammo thermal detonators Fix: ammo pricing corrections for various items, no more 1 credit rocket purchases Gave the array_bryar some more love, has just enough spread now to be useful, also added a 3rd firing mode called "decimate" which fires 9 projectiles in a large spread. Proton carbine buffed a little Fixed extra undefined firing mode on launcher_e-60R (this is possibly causing rare crashes) DH-17 pistol nerfed, smaller clip size T-21 and DLT-19 adjusted to be more worth their price while also remaining distinctly useful Disable passive credit gain announcements except in debug builds Changes included in v1.3.18 New Features New Cvars g_teamsLocked : (default 0), if set to 1 will lock the teams so players cannot switch teams after 20% of the match timelimit has passed (new players have 3 minutes to pick a team). g_teamSwitchTime : (default 5), how many seconds players must wait before switching teams. Bug Fixes and Balance Changes fixed blank name on bacta grenades client data now keeps track of how much a player has spent fixed jkg_buyAnnounce so that it can be disabled, set to announce to your team, or to both teams exploit fix with pay selling back starter guns now shows correct price (1) in shop menu starting weapon ammo is now free of charge ammo for the losing team is discounted off normal price depending on how badly the team is losing by (note: unfortunately this is not displaying correctly yet, though the actual charged amount is correct) compiler fixes don't reward our own team teamkillbonuses for suicides or team kills! don't reward the teamkillbonuses if someone switches teams! increased default spawn invulnerability time to 4 seconds from 3. Changes included in v1.3.17 New Features New Vendors There are now several new types of vendors and treasure class sets, vendors can also use specific fail/buy/interaction sounds if present. You can use these in game by spawning an npc vendor with the command npc spawn vendor npc_name vendorclass eg:/npc spawn vendor vendor_medic medicalvendor Healing Buffs There are now healing buffs, presently no shop weapons actually use them, but we will soon have a number of items put in to make use of these such as bacta grenades. There are two test items currently that use healing buffs including the grenade_bacta_antidote-e grenade and the medicinal slugthrower ammo. New Efx For Poison On body hit effects for poison are now here. Bug Fixes and Balance Changes Healing plums work again! Weapons can do negative damage (healing). Price adjustments to some weapons and slight balance changes CTF Credit bonus fixes. jkg_allowDebuffKills 1 will now use debuff settings to determine whether the debuff can do a last hit and finish someone off Reorganization of some code modules for cleaner code and improved performance Reorganization of some file structures for zz_jkg_asset5.pk3 and glua/server files Added "percentage" (boolean) to debuff data, will interpret damage as a % of current health to inflict rather than a hard number (eg: 25 would do 25% of the target's current health). Ammo price adjustments Nerfed costs for some of the more expensive weapons to make them more likely to be purchased and used. Shield prices have been reevaluated based on their usefulness from play testing Healing Plums now work for items that use lua scripts (such as bacta). Changes included in v1.3.15 New Features Passive Credit System Configurable via cvars, player's will gain a small amount of credits when employed by a team every thirty seconds. Those who join late will be paid what they would have received had the been on a team from the beginning of the match. Three cvars control variables for this system: jkg_passiveCreditsAmount, defaults to 15 credits; how much to be paid each iteration jkg_passiveCreditsRate, defaults to 30000 milliseconds; how often to pay jkg_passiveCreditsWait, defaults to 60000 milliseconds; how long to wait till player's receive payments jkg_passiveUnderdogBonus, defaults 1, disabled if set to 0. If enabled gives 20% increased credits to the losing team's players when passive credits are awarded. Setting jkg_passiveCreditsAmount to 0 will disable this system on the server. Underdog Reward System For late joins introduced. Intended to help player's who join the game's losing team catch up more quickly and keep up with the opposition. jkg_underdogBonus defaults to 1, disabled if set to 0. If enabled, gives player's who join late additional starting credits depending on when they join the game consult the following table: less than 30% match complete = +10% credits 30-44% match complete = +25% credits 45-59% match complete = +40% credits 60-64% match complete = +70% credits 65-69% match complete = +80% credits 70-79% match complete = +100% credits 80-100% match complete = +125% credits Additionally if the winning team is only ahead by 2 or less points, the credit reward is halved. Team Kill Bonus System Configurable via cvar, all player's on a team will be given a bonus amount of credits anytime any player on their team gets a kill (the killer is excluded from this reward). Use jkg_teamKillBonus to set the amount to reward, if set to 0 Team Kill Bonuses are disabled. Player's who's rank (kill count) doubled is less than their death are rewarded double. Improved Bounty System A new cvar, jkg_MaxKillStreakBounty will limit the maximum amount of credits one can receive from claiming a bounty by limiting the multiplier used to determine credit rewards when claiming a bounty. The default is 7. For example: Suppose Jill kills Jack 8 times and has a killstreak of 8. Jack kills Jill but will only receive the max reward (as if Jill had a killstreak of 7). This will help better balance bounties so they don't tip the scales too drastically. Additionally whenever a bounty holder dies from natural causes (falling off a cliff, suicide, etc) the opposing team will receive the bounty divided up by the number of players on that team. Bug Fixes and Balance Changes Disabled jkg_safeTreasureClasses by default until that system can be fixed MAX_PLACEABLE_CONSUME_WPNS increased to 20 (you can now have up to 20 detonators/trip mines on the field at once). Fixed a minor problem with safeTreasureClasses attempting to read memory out of bounds Other miscellaneous bug fixes, code refactors, and optimizations. Various item price adjustments and slight damage changes for better balance. Refactored some code

Okay so I know its hard to tell what's going on from a single frame, but overheating is now affected by the map's ambient temperature (if specified by the mapper). This will lead to some fun things like energy weapons being more effective on Hoth than on Mustafar, for example. (Not that either of those planets are planned to be included, but that'd be cool if we did get maps for them some day).

Just saw this, no idea what I was referring to, maybe I posted on the wrong thread o.O

As I mentioned in the PM you sent me, have you tested it with just OpenJK to see if the same thing occurs when using OpenJK? This will help me narrow it down to whether this is a specific JKG issue or an issue with OpenJK/your hardware.

You might also try joining the Discord to see if you can get a hold of him that way if you haven't already, sounds like you could just ask for the email contact info stuff in the readmes to be blanked out, rather than the mods removed entirely.

It'll make it more difficult but they could still select it using console.

Now I can finally replace my missing Disc 1 lol.

If by hackers they mean, gaining an unfair advantage by having a mouse and being able to adjust settings like fov, I guess? I'm pretty sure most of the supposed 'hacking' happening, is at the worst, crashing the Switch servers (haven't run into any cases so far of anyone actively using an exploit to enable things like god mode etc), the majority are probably just playing with the Switch players.