eezstreet

You're better off making a new thread about that.

Artificial Intelligence in Jedi Knight Galaxies will use a unique two-pass psychology algorithm to process how NPCs should behave. The two passes, in a nutshell: The behavior pass is done first, and more frequently. It's done on every single NPC. It's done on both the client and the server. The behavior pass performs automatic, subliminal actions that can be observed by the player. These are things such as patrolling, walking, firing a weapon, etc. as dictated by the psychology. On the server, it can also pass signals, such as "My movement is blocked" or "I have spotted an enemy."The psychology pass is done less frequently. It also may be performed on a hive of NPCs or just a single NPC. It's only done on the server. This pass does more abstract actions often attributed to higher levels of thinking. By evaluating potential actions against a series of psychological traits (exact traits to be determined, but these are things such as "laziness", "cunning", ...), and gathering information, the psychology dictates the behavior that can be observed.Each NPC has an archetype. The archetype is similar to a JKA npc type, but not quite. Archetypes in JKG can be based on other archetypes, and overwrite properties. For instance, the archetype "Stormtrooper" may have an AI type of shockforceTrooper, 100 health, "stormtrooper" model and "stormtrooper" sound effects. The archetype "Stormtrooper_Rusty" could be based on "Stormtrooper", but with less health and a different skin. More importantly, JKG won't take the approach of JA and have weird hardcodes to specific archetypes. You might have noticed the concept of an "ai type" mentioned. These are defined primarily in the code, but could be extended at some point to Lua. These deal with the psychology pass. Depending on the ai type, multiple NPCs may be automatically assigned to a hive. Examples could include: shockforceTrooper (stormtroopers; not agile, tanks, possibly can form a hive), civilianCrowd (civilians, as part of a crowd hive), and secretJedi (jedi, tries to blend in with civilianCrowd hives, and tries to escape the player but will fight if cornered, never forms a hive) The spawning mechanism will be changing too. But this will be discussed in another thread.

There's 3, as defined by MD3_MAX_LODS (which is a misnomer - it controls both the maximum LODs for MD3s and GLMs). However this is a purely arbitrary limit, and can be increased without breaking compatibility (in OpenJK?), at least for GLM models. MD3 models, it's a different story entirely as they're separate files and get loaded differently. The GHOUL2 format allows for potentially near-infinite LODs because of how it's set up. But it'll need a minor code change to get the engine to support that many LODs. And it'll probably work just fine, with proper tuning of the cvars.

All you have to do is: a. Download the OpenJK source, and follow the tutorial to compile the code (for a dry compile, just to make sure it works) b. Find the commit(s) in redsaurus' fork that have SFX sabers in it c. Add the chunks of code that are highlighted in green, and remove the parts in red. Seriously. It's that simple, and I've been kind enough to dig through the list of commits to find where exactly it starts (it starts with this one). Every time, it's always "that seems too hard, can you just do it for me instead?" I'm tired of that. If people can't copy/paste code, there's no hope for them. My tutorial here on JKHub and the one on the OpenJK project page are more than enough to get started with basic programming like this. If there's no effort put into it, there's no point in me trying to explain. That's also tangentially why I've focused less on tutorials, because people want me to write specific tutorials to cater to their wants, instead of very general things. "Can you teach me about vector math?" is succinct enough to cover "How can I make a tri-shot blast, like the kind SBDs have in Battlefront?" yet people always ask about the kind of stuff in the latter. Likewise, I can hear the complaint "well if it's so simple, why don't you do it?" -- well, I have other things I want to work on. It takes time out of other projects that I actually want to work on, such as JKG, the Lost Mission/JK2 Enhanced, other things. Schoolwork. My life? Having a build of OpenJK with just SFX sabers doesn't benefit me at all. Sorry, but it's true. If I wanted to play JA, I'd play it with JA Enhanced, which has that feature anyway. And if I started pushing out builds with one new feature, it would easily snowball into "Can you do one that has holsters next?" "Can you do one where the hazardtrooper doesn't have bugged crouch animations?" "Can you do one where Force Repulse is a thing?" ... to the point where it would be better for me to point to JA Enhanced being used as a base. Which was ironically sorta partially the point of it in the first place. It's this lack of critical thinking and halfassed effort on multiple people's parts that makes me not want to contribute outside of large projects, because no matter how much you give, people will demand more.

I've been doing other things. So no.

It's the same assets and code. Also, to implement it is literally copy/paste, but people are too lazy to do even that, so...? (not talking about redsaurus, but the people harassing both of us about it...)

Let's try and keep identity politics out of this thread, please. I for one think that Disney has taken the right approach with Star Wars aside from the clear oversaturation. Star Wars under Lucas was stagnating and the EU was getting out of control with insane spin-offs. Killing off the EU and replacing it with new lore is something painful, but it needed to be done. I haven't been paying too much attention to Rogue One ever since they made the decision to make it a panel movie instead of taking risks.

That scoped DLT-19 isn't accurate enough at all to be considered a sniper, and it doesn't do enough damage imo. buff pls

I don't know, I think it could be in theory possible to do both a one-server, all worlds/multi-server, one world each, and just have an instance be either hosted on the same server or on a different one...I will have to think on this some more. Easygen is bad, you're right, but the game actually did have a terrain entity for RMG (unused feature) which could do heightmaps in the game itself. Auto generate is not going to look great, and it's more programmer time to develop. I'm not on IRC at all anymore, I use Discord now. As far as random generation: This. There is basically no entity limit. If there is one, it's per-Realm. You're probably correct, the 2000 figure is just a random number I made up. But the system should at least be scaleable. Basically yes, to both of those questions. You can preview a house if the client has loaded the JBSP fully, but some stuff (furniture etc that are entities) will probably not be visible. It would internally be teleporting you to somewhere else, and if the house is pretty large, you'll likely get a loading screen before the map loads up all the way. It would only be started after rend2 is in a good spot where I can use it. A lot of the things I want to do (not terrible dynamic lighting, ..) pretty much require rend2. So it's even cooler.

Sorry, I haven't quite gotten to it yet, been busy with JKG. I'm going to be out of town this week for Thanksgiving. But I will have a look at it probably after that.

Answering a few random questions: - The ent limit in Q3 is because the devs went with a static limit because it was easier to work with. - Mos Eisley won't be a separate planet, it will be part of Tatooine. - Game music won't be tied to Lua (that much..), the client will figure out what music is best for them based on the situation. - New terrain tools are possible (but b/w maps can already be used, see Easygen) - Why autogenerate terrain when you can just have it be part of the planet? (Albeit inaccessible) - Each planet being a separate server is not good, as what happens if a server goes down? Your character becomes stuck. It's more logical to handle it all on one server. Also it means that you need to disconnect from one server and reconnect to another, which is no bueno.

There really isn't a centralized set of debuffs that occur on the player, rather this is a set of things that might trigger a buff icon. Buff/debuff icons appear on the left side of the screen, along with a timer (if the event is dispelled with time) On Fire: You are on fire! Stop drop and roll, or find water.Poisoned: You are poisoned!Frozen: You have been frozen solid!Carbonite: You feel a little sluggish... *Frozen (Carbonite): You are frozen in carbonite!Sting: You feel a little sluggish... *Chilled: You feel a little sluggish...Jetpack: You are using a jetpack.Healing: You are being healed by a consumable item.Bleeding: You are bleeding.Antidote: Preventing against poison. * this effect can stack. Stack count is shown as a number over the icon.

You're right, the ent limit might be a problem. Which is why it should be removed. A vertical element is not really necessary I think, you aren't really going to need to load things vertically, but maybe.

This concept needs to be started on early, because it's important, and affects over 90% (or more) of how the game functions. And I also need a lot of input and direction. So let's start off with the basics. The world, as defined by the server, will exist in dimensions, or Realms. Each dimension has a Realm associated with it. The Realm can be either a Planet (more on this) or a static bsp. For all intents and purposes, the game as it stands right now, is a single dimension, static bsp realm. There are a large number of realms, and a near infinite number of players on the server at once, but capped to a reasonable amount (2000?) to keep server taxing low. A realm is classified as an instance (may be destroyed and has a limited number of player slots) or a static world (infinite number of players). An example server, with its Realms: Realm 0: TatooineRealm 1: Upper CoruscantRealm 2: Lower CoruscantRealm 3: Coruscant UndercityRealm 4: KorribanRealm 5: DantooineRealm 6: Interspace ZoneRealm 7: Tatooine Arena Instance ID#FE0 (players: 3/16)Realm 8: Jawa Fortress Instance ID#A4B (players: 1/16)Realm 9: Player Housing Tatooine ID#00D (players: 1/16)When a realm has no players in it, logic is not performed in that realm, to conserve server performance. A realm can be either a Planet or a static BSP. Realms can contain planets or static BSPs, which are instances, player housing, ... But a Planet is really a misnomer. A planet can represent the vastness of space, or the planet of Tatooine. What a planet really is, is a collection of new JBSP files, loaded into a grid. These JBSPs are modular in nature and can have specific lumps, including: PVS dataLightingGeometryAI Waypointing/NavmeshSound InformationPhysics informationThey'd be created with a new jkgmap program that operates similar to q3map2. After a JBSP has been created (actually, you'll need a lot. probably 81 for a 9x9 grid), the artist can place the grid pieces into the JKGalaxies World Editor program. From there, interior locations (which are JBSPs, but have open leaf PVS nodes that can connect to the outside world, so places like Mos Eisley won't lag your machine to pieces with all the interiors) are linked to the world grid. When a player changes Realms, it may trigger a map change. But only for the client. The server doesn't need to change maps...it has them all loaded! The client keeps a cache of JBSP files that have been loaded and cycles through them. Map loading times are dramatically lower because levels are effectively streamed from the hard drive. When you get close to an instance gate, the other level will start loading in the background so it can load quicker if the user decides to go into that level. Outdoor lighting is dynamic. But not the broken kind like in JKA - the good kind like most modern game engines do. The server can set the time of day in the world (per realm!), and since all planets are using the same clock, an effort can be made to keep all of the planets in correct sync. What are the benefits? Much faster map loading. Vastly increased FPS in outdoor environments. No joining servers for each map. This is probably the biggest one here, but we're not talking a vast array of servers running all kinds of different maps here, we're talking one server running all of the maps at the same time. In some respects this means a much easier thing to create, since all servers can have their own account system and not have to tap into some kind of shared JKGalaxies account, but in some respects this is a much harder thing to create simply because of how much insane nonsense is going to need to be programmed. Let's be clear, this is a pretty bold plan, but it's based on how MMOs operate already. It'll require a significant amount of retooling to do, and it's a daunting task for sure. You can (in theory) fly a ship directly into space. Yeah. That. No more need for "shuttles" - space battles could potentially just be handled by a series of interspace realms, such as "Coruscant Airspace" or "Tatooine Airspace", with a few linking ones between them. That's of course, if we decide to pull the trigger with space combat, which will require quite a bit of work, but it could be pulled off. Much faster asset creation. No more 8+ hour compiles for huge ass desert maps. No more running out of memory when compiling maps. Cross-planet communication. You can for instance, open up the possibility for features such as a Looking for Group feature, or perhaps an announcer for the Tatooine Arena. Or whisper to a friend on another planet. All of those would be difficult if not impossible to do on a cross-server setup.

Just an update, this patch is set to release sometime in January. These patch notes are slightly outdated and don't reflect everything that's in 1.3.0, they will be updated when we're a bit closer in. There's one more patch to the game that's coming in early December, 1.2.2. You can find more information on that here: https://jkhub.org/topic/8602-upcoming-jkgalaxies-patch-122/ The development time isn't split between these two versions, the priority is on 1.3.0, but immediate fixes and major bugs go towards 1.2.x. Balance is not a priority as 1.3.0 will significantly alter the gameplay.

The Dresselian Projectile Rifle?

This is the last patch until 1.3.0, which is on track to release in January. The primary focus is getting the Mac version working, and fixing some stray bugs that were not addressed in the last patch. There are a few minor balance changes as well, but we've avoided making that many as 1.3.0 will intensely shake up the gameplay. Bug Fixes Mac version no longer requires SDL to be installed by the user - it's bundled in.(Possibly) fixed a bug that caused thermal detonators to crash other clients (it still seems a bit random)Fixed a server crash from clients without the map pack connecting to a server which was on a map pack mapYou can no longer "claim" your own bounty or a teammate's bounty (You never could, it would just trigger the chat message)You can no longer acquire bounties from killing teammates.Fixed a potential divide-by-zero error in weapon indicatorsInput is now processed before the logic, instead of afterwards. The most noticeable effect is smoother input at low FPS rates. (upstream OpenJK fix)Fixed a potential divide-by-zero error in input code (upstream OpenJK fix)Removed sv_blockJumpSelectsv_autoDemo has been updated to match newest OpenJK settings.Can no longer buy items from the shop while dead or a spectatorRemoved legacy commands: gc and thedestroyerSome commands which did not exist can no longer trigger the "Cannot use that while in intermission" text.Fixed a potential exploit with some nefarious /say commands crashing the server.New Features Freeze and carbonite effects will now be seen on your first person gun.Added a new cvar: jkg_killsPerBounty (number of kills required to trigger a bounty; 2 by default)Security: Stateless challenge requests, for less potential of D/DOS. (upstream OpenJK fix)New command processor on the server, including new commands: butterfingers - drops the player's lightsaber dismember - dismembers the player's joints handcut - kills yourself and cuts off your hand in a dramatic fashion headexplodey - does exactly what you think it does holdme - body-dragging testing feature knockmedown - knocks yourself down loveandpeace - locking emote testing feature pay - give someone else your credits relax - ragdolls the player wrists - does the same thing as handcut All commands except pay require cheats to be active on the server. Balance Punching no longer drains stamina (5 -> 0), but requires 5 stamina to use (0 -> 5).Stamina thresholds reduced for rolling and jumping (20 -> 15)Kicking now requires 5 stamina to use (0 -> 5)ELG-3A: "Charged" mode changed to "Stun"Fixed a problem with E-11b Carbine and Rifle where it fired four shots at once in full-auto modeScoped DLT-19 got improved base accuracy for the Heavy blaster mode (18 -> 15)Scoped DLT-19 got improved aim-down-sight accuracy for both firing modes (0.55 -> 0.35 for Heavy; 0.55 -> 0.45 for Light)Scoped DLT-19 got increased damage (15 -> 18) in "Light" firing mode.KYD-21: Renamed alternate firemode ("Sting" -> "Paralyzer Beam"), no change in effect

?

I'll defer to @@Pande on this one.

Which BlasTech rifle? There are a lot.

Timescale, probably.

Well played! Next time we will be recording demos to make a gameplay video, and there will possibly be another patch to address some long-standing issues with thermal detonators, among a few new bugs that we found. Overall it was very stable/fun, hope you had fun!

The encore match will be starting in two hours! @Willdo @Noodle @NubSmoo @Silverfang @Xycaleth @DT85 @Darth Futuza @Onysfx @SiLink @Obsidian @MagSul @Evian @dankswagmaster @Stoiss @nyarl @Ramikad @Circa @therfiles @Pande @ooxavenue

It's back up, under JKG USA