Jump to content

Futuza

Members
  • Posts

    1,891
  • Joined

  • Last visited

Posts posted by Futuza

  1. 10 hours ago, Bongrip said:

    Futuza, as for hacking, well yes. PC players were intentionally hijacking rcon and spawning rancors and generally griefing our entire servers. Intentionally crashing them as well, and one time a password was put on each server. Ironic, because we can't plug in a keyboard to type in a dialog box, nor did our digital ps4 keyboards let us even try to guess. Yeah, some PC players were intentionally griefing

    That's unfortunate, guess there'll always be dicks wherever there are vulnerabilities.  I think the rancor bit is a bit funny at least, had some good times having everyone team up to kill rancors on pc, but yeah screwing with your game is unfortunate.

  2. Personally, I wouldn't recommend depriving yourself of the fun experience of beating the game the way it was designed to be, but if you insist you could do a couple of things to make Desaan a wimp.

    The most straight forward to what you're asking is to edit his npc file.  You can find a tutorial about how to do this here (note might vary slighty as this is for JKA not Outcast, but its basically the same format):

      Note, that you probably want to make a seperate pk3 to store the modified Desaan .npc in, so as to not overwrite the original gamefiles permanently.  The easiest way to make him a scrub is change his health value to 1hp, but have fun trying out all the new stuff.  You could change his class, or lower his accuracy, aggression, etc.  Keep in mind doing this will probably mess up your save file, so don't mod until you have a backup save.

    Smoo, Lancelot and rlcrum17 like this
  3. I'm not much a fan of the code bracket coloring, it's very hard to read. 

     

    #define MOO COW
    //Consider the following:
    void SomeFunc(int x) 
    {
      if("COW" == MOO)
        return;
      else
        SomeFunc(x);
    }
    
    
    
    
    

    The blue and purples have a pretty bad contrast.  If the colors were lightened a bit it'd be a lot better, it looks like these were designed for light theme not dark.  (My favorite dark theme color code is probably vscode's default if you need some inspiration).

     

     

    Spoiler

    EDIT: For those not using the default dark theme:
    spacer.png

     

    Smoo and Circa like this
  4. I know Discord integration was kinda popular on this poll, and now that JKHub 2.0 is basically here, I thought I'd mention that WidgetBot is a thing that exists.  I use it for JKG's announcement feed, but it can do a lot more (such as an iframe with a the integrated Discord inside of it).  Not necessarily sure such a thing is necessary/fits, but just wanted to let you know that that's an option that is free (though they do have a patreon that let's you get early access to the next version and do more customization etc).

    Smoo likes this
  5. Just to be clear, I totally think it's fine to use clip brushes when you have some sort of object/thing that physically appears to block the way.  For example, in the poorly drawn map below, you have some spikey rocks that are covered by a clip brush preventing the player from actually moving past them. 

    spacer.png

    But yeah Buoy's should work great with the fish, I was thinking something like this, but that works too.  Heck even map edges like water that just plummets off the edge of a flat earth might also be interesting.  Like this. 

     

    SephFF likes this
  6. 7 hours ago, SephFF said:

     

    im torn on the idea of limiting players with clip brush....I personally prefer I am free to go where I want in a map, leave clipping to stairs or weird edges to stop players from getting stuck.

    Would people prefer they are limited to a small section of the map? or have the whole thing open to them? I can understand reason for it, to keep game play to certain areas only. Just would like opinions on this.

    What I would suggest when it comes to map borders, if it isn't too much work (granted that clips are way easier and less time consuming), is creating natural borders that fit within the map itself to prevent you from going further.  There's a couple of things you could do with an island map. Consider some examples: a strong current in the water that pulls players who go too far out into a whirlpool which kills them, piranhas that kill people (an area full of fish that do more and more damage if you don't leave it), jagged rocks that are too steep to navigate, trees/buildings/kelp that block the path, etc.  It's fine to use the clips, so long as you justify not being able to move past it with something physical/real.  One of my map pet peeves is invisible walls.

    SephFF likes this
  7. We're more than halfway through another year and with it a new set of features is coming to Jedi Knight Galaxies with version 1.3.23.  You can try out the new release by going to the download page here.  A subsequent beta patch will likely be made in a few weeks, but we hope to move our focus onto development of the next major milestone v1.4 (yep that's lightsabers!).  You can find a list of full patch notes here.

    A blaster overheats in the desert air.

    Here are some of the new features!


    New/Improved Systems:

    • Falloff Damage.  Guns now feature falloff damage, meaning that if you fire at something beyond the weapon's range rating, damage will be exponentially decreased over distance.
    • Toggleable crouching has been added!  You can now set a binding (Ctrl by default) to set and forget (c still uses the old method of hold to crouch).
    • Overheating has been improved both mechanically and visually.  Each gun that generates heat (most blasters), has a custom defined threshold (default: 75% heat) at which point you will begin to hear a warning noise and see steam coming off the gun.  If the gun reaches 100% heat it will overheat disabling use of the weapon until it can cool down to the threshold level (more steam efx will also occur during this point).  Additionally it takes longer to swap to a different weapon if the weapon has more than 50% heat built up on it.
    • More debuff/buff types added.  This includes some new ones with new movement mechanics: slow and haste.  Sting blast weapons will add a stacking (up to 50%) slow debuff to targets hit by it.  This also includes EMP debuffs which will short out certain equipment preventing their use for its duration (such as jetpacks).  Other buffs can also affect movement in different ways, such as taking spice which poisons you but also increases your movement speed.
    • Updated Lua API/system to reflect current game features introduced in recent years: can now use new features like shields, debuffs, etc.  This is not going to affect current gameplay much, but lays a good groundwork for later Phase II systems for things such as quests.
    • The Lua admin system has been improved and lots of bugs with it have been fixed.  New commands and functionality has been added, use /admhelp cmd in game for more information.
    • The emote system has been readded.  You can type in /emotehelp to get a list of different emotes that are usable .  Using 'u' will give you access to the action chat menu which emotes can be called from directly (along with other cmds).  For example, try out /thumbsUp to gesture with a thumbs up.
    • Most items now have item description with interesting factoids or lore information.  Note: This feature is still in development and will be improved in subsequent versions, especially with UI changes down the road.
    • Weapon descriptions now display what type of ammo they are compatible with.
    • Dice rolling system.  Want to gamble, play D&D, or yatzee inside of JKG?  Now you can with the dice rolling lua minigame.  Use the cmd /roll in the chat or console to try it.
    • The client's server browser now shows which version of JKG each server is running (uses the 'gameversion' cvar).
    • Deathmessage improvements.  Centerprint death messages brought back, and the game will inform you if you got a headblow (or were killed by a headblow).
    • Melee mode is now toggleable for each individual ACI slot, instead of globally.  You can now set an ACI slot to melee and leave the other ACI slots unchanged (or have multiple slots assigned to melee).
    • Pray and Spray.  Automatic and burst weaponry can now be fired while rolling (but good luck hitting anything!)
    • Item Tiers.  While this feature will be mostly unused in this patch, items can now be assigned a tier to help player's determine their value/rarity.  See this concept thread for more information about how tiers will work in the future.
    • Knockdown Stuns.  The standard-stun debuff now causes knockdown instead of freezing the player in place.  The old style has been restylized as 'stasis-stun', and is much less commonly used.
    • Healing Grenades (such as the bacta grenade) now have a different armed sound, to help you tell the difference between helpful grenades and dangerous ones.
    • ACP Weapon Type implemented.  The ACP damage type can partially bypass shields, with a % of their damage piercing through any active shield to do direct damage.  The default ratio is 50% (half impacts on the shield and the other half does direct damage).
    • Weapon swap time is no longer hard coded (swap time is how long it takes for you to switch between weapons in your ACI), and can now be specified manually by each weapon file. Additionally Grenades, melee, and pistols have 25% reduced swap times from other weapons.

    New Items:

    • The IR-5 Intimidator Blaster Carbine. This cheap automatic blaster provides potent firepower for the fraction of the cost of higher quality carbines such as the E-11, however it is prone to overheating.  We hope this weapon will provide a good blaster alternative to compete with the Lt-60 Carbine in the early stages of matches.  A slightly more expensive version features a scope, with slightly better stats and heat management.
    • Bacta Grenades have technically been in the game in the while, but have been missing their models.  They are now all properly dressed up now!  They also now heal more aggressively over time, and less instantaneously.
    • Jetpacks: Merr-Sonn V-Burst Jetpacks have received their own model, and a JT-12 Jetpack (made famous by Jango Fett - model by Neomarz) has also been added.
    • New clothing has been added including: Pilot Goggles, Capes, Gloves, a new rebel helmet (forest camo), and an Imperial Officer's hat.
    • New Armor Set: Kessler Armor created by Noodle.  Designed for Bounty Hunters or mercenaries.  Provides decent protection for an affordable price.
    • New Armor Set: Galinolo Huntsman (model by Neomarz and HellKobra, skin by Darth Phae) armor created by Noodle.  Designed for Bounty Hunters or mercenaries.  Slightly more expensive, but better protection than Kessler armor.
    • Other misc armor items: Boba Fett's helmet, Bousshh's helmet, a Mabari Helmet (Zam Wessel's), and a traditional Weequay Cuirass.
    • Westar Blaster Pistol.  Jango Fett's famous blaster pistol. It provides a very good fire rate and reload time, but also runs a little hot. While a little more expensive, it remains useful against even blaster carbines or rifles. By Silverfang (model).
    • A simple Spice variant has been added and can now be used to give yourself a speed boost at the risk of poisoning yourself.

    Map Changes:

    • Most maps have had new vendors added to them (or the vendor locations adjusted).  Most will feature different types of vendors in each base, such as medical vendors (which sell first aid equipment like bacta), supply vendors (which offer equipment like grenades of ammunition types), etc.
    • Maps now have an ambient heat value (default is 100), hotter maps make it harder to cool down overheating weapons, and fire debuffs are more effective.  Cooler maps allow weapons to cooldown faster, while making cold debuffs more effective, etc.
    • JKG_Spaceport now has turrets.
    • All maps except JKG_Taris (and those already with CTF Flags) have had CTF flags added in.
    • Fixed JKG_Nightfall spawns (no more spawning in the enemy shop!)
    • Fixed floating Tusken vendor in JKG_Jawa_Fortress

    Bug Fixes, Quality of Life Improvements, and Balance Changes:

    • Across the board balance changes to all weapons, most weapons have been buffed in some way either by being made more accurate, damaging, better cooling rates, or less expensive.
    • Weapon accuracy improved across the board.  Especially for rifles or snipers or when using ADS (aim down sight).
    • Several crashes fixed.
    • Bacta now checks if client is at full health before allowing consumption.
    • Bacta is now more reliant on a healing over time (buff) than instant heal.
    • Carbonite debuff now also reduces damage received by 50%.
    • Fixed tripmines chain explosions (along with other entities)
    • Items now have weight (this doesn't affect anything yet).  You can check this by using /debuginventory.
    • Fixed jetpack x-axis orientation acceleration not applying.  Jetpacks are now much easier to use.
    • Consumables now have item descriptions.
    • Fixed rolling from a fall or jump not removing fire debuffs
    • Fixed dodge rolls and optimized code.
    • Fixed some broken Lua animation handlers
    • Player names now have drop shadow in the pazaak UI.
    • Entities can now be marked with the 'busy' flag (such as when they are playing pazaak, or shopping). eg: If you challenge a player currently in another game, you'll receive a busy response.
    • Removed "Press E to pick up weapon" messages on base weapons.
    • Shader's for poison efx are no longer partially visible through/behind walls.
    • Added a binding set for next/previous weapon in the control menu.
    • Shields and Jetpacks can now be equipped to ACI with the number keys.
    • It was possible for standard-stun to penetrate shields in certain circumstances, this is now fixed and shields should now always protect you from stunning as long as they have a charge. This bug would also cause the player to be frozen indefinitely.
    • You can no longer change equipment while stunned/frozen by movement locking debuffs (such as standard-stun).
    • Fixed exploits regarding using jetpacks or shields to gain an extra ACI slot.
    • If you purchased/equipped a new shield, while you still had current shield charge and the new shield's max capacity, was less than your current shield charge, the shield would not be fully charged unless it was at exactly 100%.  This no longer happens.
    • Shields now protect from fire debuff, but will not remove the debuff if the shield recharges while the player is still on fire.
    • Fixed: Bacta grenades do not let you switch weapons until after they detonate.  Unfortunately this bug made it in and survived.
    • Grenades are no longer in melee mode by default.  (This occurred after changing to individual melee aci slot assignment from a global system).
    • While cooking a grenade, you are no longer able to sprint.  Thanks to Awec for reporting this, and George for the fix!
    • Fixed crashes from invalid gametypes, you can no longer vote for invalid gametypes either.
    • Fixed can't switch back to weapons with mousewheel after switching to melee
    • Fixed exploit allowing multiple armors to be stacked on the same location.
    • Assists and some other notices can now be seen while dead.  (For example if you kill another player after dying, you can see the notification for it now).
    • Fixed exploit with armor not removing extra hp after unequipped.
    • When at maxhp, and swapping armor sets, if the the new set increases maxhp, your current hp is now set to the new maxhp.
    • Fixed player's names being hidden by certain armor sets.
    • Armor vendors are now possible.
    • All item descriptions have been improved with more accurate and useful information.
    • Fixed bug where a spectator viewing a player that is killed would have their chat message cut off (like what happens to the player who died mid message).
    • Fixes for various exploits regarding /pay command.
    • Fixed various lua exploits.
    • Fixed various auto aci assignment exploits.
    • Fixed disintegration efx's not showing up on players.
    • Fixed cinbuild.
    • New item types added
    • New filtering options for inventories/shops added
    • Fixed ammo overrides not working with certain ammo hierarchies. 
    • Fixed bad behavior when overheating in the middle of a burst round.
    • Ammo overrides now also override 1st person efx (such as the muzzleflash).
    • Jetpacks can no longer be activated while the player has an emp debuff active.
    • And much more!

      JKG Contributors and Credits


    Both new assets, binaries, and most maps will need to be updated (we have updated both of the map packs).  Follow the instructions on the download page to patch/install. 

    As a note, aside from a follow up patch (v1.3.25) for major bugs or balance issues discovered during the beta test, this will be the last planned major release for version 1.3, then we will be transitioning our focus to v1.4 (some work has already been done for that).  v1.4 will introduce the highly anticipated saber combat elements of JKG and we think all of us are looking forward to that.  v1.4 will be a big step in bringing JKG closer to the end of Phase I, and closer to the completing the core combat gameplay, after that there will be only a few more core elements left (such as skills, skill trees, force powers, etc) before we are ready to start working on Phase II.  Those interested may want to view our project roadmap located here.  We want to again express our appreciation for everyone that helps contribute to and support our favorite modding project. 

    May the force be with you!

  8. Was wondering if anyone was interested in adding new tutorials to this guide?  Especially for the missing ones (such as the whole Level Distribution section).  I could maybe write something, but I'm not much of a mapper so you'd all probably get a bunch of MS Paint pictures to explain the concept.  (Will the real mappers please stand up, please stand up?)

    Smoo and Asgarath83 like this
  9. Hi Stark, sorry it took so long for me to notice your posts (I don't check the forums very often).  There are a few servers available, but usually the best way to try out the mod is to join the discord and set up a match with other people.  The community isn't super active at the moment, so we don't have players 24/7 like some of the other larger mods, but there are still a lot of other people that want to play - you just need to arrange a time.  I'd suggest joining the discord and joining the 481st group and trying to setup a match with some of those players (there are about 30+ of them that are down to play as often as possible).  We'll have a larger announcement within the next two weeks which will probably also involve some official community scrimmages. 

    If you want to setup a server, it works fairly similar to a baseJ KA server, but if you need help with anything feel free to ask.  Don't forget the basic stuff like opening up ports, setting up your cfg file, etc.

    Smoo likes this
  10. Hey @STARK NPCs are basically partially disabled in Phase 1, some of the old lua scripts, such as the jkg_arena_tatooine one no longer work because a lot of the lua functionality has changed a lot since that script was written.  You can spawn NPCs directly via console, via `npc spawn npcname`, but most of the npc behavior has been disabled since they aren't complete yet (for example we haven't hooked up NPCs to the JKG Weapon system yet so they don't know how to use the new items).  JKG_Arena_Tatooine is also an old map that has been replaced by newer ones.

    Anyway, some of these things we have actually been working on in preparation for Phase 2, but it'll be sometime before they're ready for release.  Our focus is mainly on getting the next version (v1.3.23) out first, however I may have a bit of a teaser available soon in regard to dialogue and using NPCs in otherways other than as shopkeepers. 

    Also if you want more up to date information or have further questions, you'll be better off asking on the Discord as I only infrequently check the forums.

    Smoo likes this
  11. 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.

    Awec likes this
  12. 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

     

     

     

    Noodle and Citrom like this
  13. 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.

  14. 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 NPCNPC 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.

      1. 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.

      2. 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.

      3. 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

      4. 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.

      5. 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. 

      6. 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.

     

    z3filus likes this
×
×
  • Create New...