Dusty

I found this here, it seems like it would explain a lot of the use of vectors in JA's code. http://wiki.ioquake3.org/Vectors

Getting AI Jedi to activate Force Speed independently shouldn't be too difficult... that is, if it's possible. I haven't explicitly checked, but Raven might not have programmed what an NPC using Force Speed independently would look like. I can rummage through the code later and see what I find.

What are nav meshes exactly? Is it something a mapper must place -- is it a similar concept to an NPC-no-enter area except expanded? Or is it some kind purely AI calculated type thing? Is it what Xycaleth shows in his picture? If so, it seems kind of unnecessary to me, at least purely for solving cliff-avoidance issues, unless if you want to get more in-depth than that (walls, obstacles etc.) or more intelligent about the avoidance. I would be satisfied with just stopping at a cliff even if it leaves the NPC stuck temporarily. If you guys want to talk about nav-meshing and waypointing that's fine, but when I made the topic, I guess one thing I was wondering, was does it look like Raven's solution was going to work? It was hard for me to decipher exactly, because I'm not sure how all of their vector and trace things work...

The way I see it, waypoints would still be necessary for navigating from Point A to Point B in any intelligent sort of way. But right now they are also pretty necessary to keep NPCs from doing silly things like running off drops. There are also lots of areas in maps where it wouldn't make sense to add NPCs because there are no NPC-no enter areas to keep Jedi from running off edges. Heck even in some SP maps in areas where Jedi are supposed to be like t3_hevil there are not properly placed barriers = reborn running off edges trying to get to you. I also feel uncomfortable letting a stormtrooper run away from you if he's not using waypoints because he might just do the same thing. You can say "it's the mappers responsibility" and maybe it is, but it's a little difficult to fix/expand the waypointing of a map in JA considering we have non of the original map files. This idea Raven has seems pretty simple to me. Check if there's a large height difference in the vertical direction in my current path of travel, if so, cease any movement in that direction and turn a little bit until it's no longer true.

I found an interesting snippet of code in JASP: void NPC_AvoidWallsAndCliffs (void) { /* vec3_t forward, right, testPos, angles, mins; trace_t trace; float fwdDist, rtDist; //FIXME: set things like this forward dir once at the beginning //of a frame instead of over and over again if ( NPCInfo->aiFlags & NPCAI_NO_COLL_AVOID ) { return; } if ( ucmd.upmove > 0 || NPC->client->ps.groundEntityNum == ENTITYNUM_NONE ) {//Going to jump or in the air return; } if ( !ucmd.forwardmove && !ucmd.rightmove ) { return; } if ( fabs( AngleDelta( NPC->currentAngles[YAW], NPCInfo->desiredYaw ) ) < 5.0 )//!ucmd.angles[YAW] ) {//Not turning much, don't do this //NOTE: Should this not happen only if you're not turning AT ALL? // You could be turning slowly but moving fast, so that would // still let you walk right off a cliff... //NOTE: Or maybe it is a good idea to ALWAYS do this, regardless // of whether ot not we're turning? But why would we be walking // straight into a wall or off a cliff unless we really wanted to? return; } VectorCopy( NPC->mins, mins ); mins[2] += STEPSIZE; angles[YAW] = NPC->client->ps.viewangles[YAW];//Add ucmd.angles[YAW]? AngleVectors( angles, forward, right, NULL ); fwdDist = ((float)ucmd.forwardmove)/16.0f; rtDist = ((float)ucmd.rightmove)/16.0f; VectorMA( NPC->currentOrigin, fwdDist, forward, testPos ); VectorMA( testPos, rtDist, right, testPos ); gi.trace( &trace, NPC->currentOrigin, mins, NPC->maxs, testPos, NPC->s.number, NPC->clipmask ); if ( trace.allsolid || trace.startsolid || trace.fraction < 1.0 ) {//Going to bump into something, don't move, just turn ucmd.forwardmove = 0; ucmd.rightmove = 0; return; } VectorCopy(trace.endpos, testPos); testPos[2] -= 128; gi.trace( &trace, trace.endpos, mins, NPC->maxs, testPos, NPC->s.number, NPC->clipmask ); if ( trace.allsolid || trace.startsolid || trace.fraction < 1.0 ) {//Not going off a cliff return; } //going to fall at least 128, don't move, just turn... is this bad, though? What if we want them to drop off? ucmd.forwardmove = 0; ucmd.rightmove = 0; return;*/ } It's declared in NPC.cpp and it's called by NPC_ExecuteBState later on in the file. It wouldn't be so bad for NPCs to be able to run around outside the waypoint system here and there if we knew that they would stop before a drop or not try to run through walls.

Multiplayer only? Aww...

^If I want to be detailed in the implementation (as opposed to quickly throwing some feature together), I think coding would be the best. Maybe you get their HP down to 1, then they attack much less aggressively for a short time (maybe only 5 or 10 seconds). Some sort of visual indication would be important. Some kind of behavior signifying you "won" for the moment. Then when they are ready for action maybe they do a flourish or taunt. Then they get half or all of their HP back and start fighting normally. Or maybe all that is too detailed. Maybe it should be more left up to the player to figure out that the enemy is not completely beatable and when they get their chance to progress past or escape the enemy. Or you could always just make the NPCs ridiculously tough, but if they are defeatable that implies Jaden/the player is supposed to be stronger or more skilled than them in some way... plus that would emphasize either the NPCs being kind of cheap or the player having to be very cheap to defeat them, turning everything into a cheapness game. MB2's saber system... that would be hard for a single player game... still my altered saber system will have a few nods to MB2's style...

I remember having this conversation partially before with Eez. He said the main differences between JK2 and JA npcs were these 2 things: - JK2 maps are "waypointed" much better than JA maps - certain portions of the JA NPC code from JK2 are commented out

I always thought Jaden's supposed power level in JA was kind of ridiculous. Wouldn't it make more sense, if some enemies were "invincible" in the same way as Boba Fett? Like for example, Reborn Masters, and Jedi Masters/Trainers? Maybe they would be unable to be defeated completely? Like they get "wounded" and you have a short chance to get past them or run away from them until they start attacking again? I feel like that would be kind of cool actually. Anyone have any ideas? I just sort of thought of this a second ago. Most enemies this should work because you don't actually have to fight them. The only one is one of the Reborn Masters in the first part of Korriban you have to fight because defeating him unlocks a door...

You guys sound like you want to go crazy

So, the obvious issue with JA's NPCs is that the maps aren't waypointed nearly as well as in JK2, so NPCs seem less dynamic and smart and more stoic and not smart. Is there anything that can be done AI-wise to even things out a little? Like for example, if we let JA NPCs go outside the waypoint system a little more; example, they are allowed to stray up to 70 game units from the nearest waypoint pathway, sort of like how Jedi ignore waypoints? Anyone smarter than me *cough* @@eezstreet *cough* have any thoughts or ideas?

That's weird... Sxx was relatively nice to me in my time as an MB2 dev... maybe someone framed him... or he was just being a jerk. Dunno.

Ok, really, you guys should at least fix the link for the Movie Battles website, here it is: https://community.moviebattles.org/

So I noticed that MBII seemed to go dark for a bit a little while ago. Once I tracked down their facebook page with a google search I found they had moved all their stuff to a new domain (again): https://community.moviebattles.org I noticed though when I clicked the tiny mods button at the top of JKHub's page here for Moviebattles it still links to the old website which is a dead link. Speaking of which, shouldn't we make the bigger mods for the JK games a little more prominent? Give them a bigger button or something? They're like the life-blood of these games haha. (You know OpenJK, MBII, MovieMakers mod, etc. etc.)

Oh those bonus missions. I must do that. I've put it off for so long. That should be the next mini-mod. I've been working on the code and I think I'm making real progress. I've been making some new cvars, maybe you can guess what they're for? g_char_forcePowerMax, g_char_forceRegen, g_saberForceDrain, g_saberForceDrainAmount, g_saberDamageScale. Some of it I'm keeping a secret though

^You know a little bit about everything don't you Asgarath @@Cerez: Maybe it will come in handy for you, I believe there is a console command called "runscript". I've never tested it but I'm guessing it lets you run scripts without having to have the map trigger them.

Yeah we should really take out a lot of the unnecessary hardcodes. They are just a pain in the butt. External files are so much cleaner anyway. All NPC behavior and weapon/item stats should at least be completely externalized as far as possible in my opinion, because they're already partially externalized (in Single player anyway we have the weapons.dat, items.dat, and so on). Why are objectives hardcoded exactly? I never got that. Aren't there cvars that you can make point to whatever strings you want? Or do they not work? Well, first off, it makes the game run smoother and better. It makes external (non hard-coded cvars) save between sessions instead of being forgotten too which seems to have been a base JA bug, making some of my mods actually require OpenJK to work. Also, we have the opportunity to remove a lot of unnecessary hard-codes from a base source code the entire community can use

So I'm updating my fork of OpenJK with the latest code again to resolve some crashes and to try and fix the commits ahead/behind count, and I'm having some similar issues again. I'm going to deal with each file manually one by one and I should be able to take care of it, however, I just wanted to point something out, and ask if this is normal? Here are the merge conflicts git is saying I have: Some of these files I have never touched. Why are there merge conflicts that can't be resolved automatically in these files? For example, half of those files are multiplayer code, which I can guarantee I have not tinkered with (my mod is an SP only mod, I don't even include MP code in the solution files). EDIT: Perhaps there's some sort of setting I can change, like "overwrite local with remote if no local changes since download" or something...

I believe this is what ent-modding is for. You can mod these things by text-editing a .bsp file without having to decompile and ruin the map. Still then you can't use GTK-Radiant. Maybe you could decompile the map, do your entity mods, re-compile, then copy the text for your added entities to the old bsp file, if you want to use GTK-Radiant to create the entities rather than doing it via text-editing.

Can anyone answer this question?

EDIT: I figured it out, but I also had a side question. See end of post. Sorry to bump this after so long, but I still don't quite have it resolved. What seems to be happening, is visual studio sees all the .pdb files for jagamex86.dll, but it can't load any of them, giving an error message for each one saying "image does not match". When I try to load the pdb file manually, I click on the file and it says "a matching symbol file was not found in this folder" each time. Anyone have any idea what's up? I think this is the reason it never worked before several months ago when I first made this topic. Here are some pics if you find my explanation confusing: Side question: So as Xycaleth pointed out in the last post, my jagamex86.dll is being loaded from the Gamedata/Dusty_Patch folder, whereas all the other dlls are being loaded from the Debug folder where my source code is. Just a minor annoyance. Is there any way to change this though? What would building the INSTALL project do? EDIT : I got it working. It turns out I just needed to replace the jagamex86 in my Gamedata/Dusty_Patch folder with the latest built version because it wasn't the same which is why the pdb files didn't match. I guess that was my issue before in some form, because I didn't know at all what files were being loaded by the game when I tried to run in debug mode.