Scooper

For pony! =3 Welcome to the jkhub forums.

Will MUG take Caelum back?

Will Caelum finally find out about his unborn child?!

Find out next week, on JKHub! Only on the internet.

I have no number for how expensive, but it's more expensive than skipping them, which is what I said. This collision system is from the q3 engine, so in the older days it was probably a bigger issue than it is now. But the bounding box is supposed to be used by objects that do not require any greater precision, so correct method chosen to keep things as cheap and effective as possible. But JKA obviously supports more sophisticated collisions, as shown by the brush model system. The issue is that we haven't really been given great ways of accessing better collision methods if we need them.

The engine patch that will allow for bounding boxes to rotate will need to be applied on both server and client for predictions to be correct. I have not attempted anything further than the server side, so the current results I have seen have had incorrect client predictions.

Might be that the initial limitations for JKA were too outdated as well. This goes for pretty much everything, triangle limit etc. Though I have no proof or facts to base this on, it's just speculation.

Aww, this looks fun. Some of those costumes are awesome. And I appreciate the effort put into some of them, cuz I like the characters a lot, even if it isn't perfect. =p

Yes, but I posted that post before I explained it on IRC.

In terms of bounding boxes, normally it would be correct to assume that they would not be rotatable. But JKA's collision system uses the brush model system to perform bounding box collisions as well. It does this by using a 6 sides brush model that reshapes to fit whatever bounding box configuration the colliding object has. And it purposely disables more expensive operations such as rotations for this type of collision model.

So eezstreets assumption in the beginning that this wouldn't be easily possible was the safest assumption, and would normally have been correct. Unless you have looked into the collision system, and discovered the above-mentioned method that it actually uses.

So for those interested in this topic the conclusion is that rotating bounding boxes in JKA is possible because they function as limited brush models. And it's possible to alter the engine code in a way to enable bounding boxes to perform these rotation checks.

Looks pretty good, and I love that you've chosen a Portal theme =3. But there are a few stuff I'd nitpick upon. You also said it's WIP, so I'm not sure exactly how much else you are planning to change. I can only give feedback on what I see. I haven't seen any of your previous work, so I don't know what to expect of the final result. (If there's some on the forum somewhere that I've missed I'm sorry.)

Anyways, some nitpicking:

The texture resolution on the floor/wall tiles seems to be too low. The lines are really blurry, and it doesn't strike me as "real".

This actually goes for all the textures I can see, but it's most visible on the tiles.

You seem to be using some metal/brushed metal texture to overlay on the door. This doesn't look right to me. The door kind of looks like coarse grey cloth instead of metal.

I would suggest you created a tutorial and submitted it to jkhub. This way anyone who is interested can learn from your experience. This community isn't really here for a master-student learning setup. Knowledge to the masses!

Recruiting people for your project is fine though =]

This project sounds very familiar. I have been approached for assistance on something like this on a few occasions.

Do you mind listing the current development team? Name and roles please =p

Well I'm not sure what they can legally demand in their agreement. But the demands I've seen so far seem within reason.

If you are compiling the SDK normally with jamp.exe as the intended program to run it, there is no way that it can be prosecuted if it happens to work on iojamp as well. But if you are intentionally including features that will only work on iojamp, then it is no longer created to be only used by jamp.exe. So it will be against the license agreement.

And just making sure that it is compatible with both of them in this situation isn't enough. For instance the situation we discussed off-site eez: Adding additional trap calls by utilizing new engine features in the iojamp project. It should be possible to make it compatible with jamp.exe by disabling the new features if this is the program that runs it. But there is no denying that this mod project was now created with iojamp in mind, thus breaking the license agreement, and you are no longer allowed to use the source code provided in the JKA SDK to make this mod which is intended for iojamp.

Unfortunately it seems to be pretty conclusive that this is the intention of the mentioned section of the SDK license agreement. It seems like a reasonable demand, and I can't think of any arguments to get around it. Neither have I seen any arguments mentioned here that would allow us to get around it.

Still, the JKA SDK license agreement does not pose a threat to the actual iojamp project. Just its actual practical use after its completion. Though there might be some copyright issues that can cause problems for the project. And I think the only safe method to get around this is to get conclusive answers from lucasart/ravensoftware about what is allowed and what isn't.

Or people can just break the license agreement at their own risk.

"for operation only with the full version of the software game Jedi Academy"

This thing is nasty when it comes to using the SDK to code mods for iojamp.

BURN HER, BURN HER!

 

How do you know he is a witch?

HE LOOKS LIKE ONE!

Well, I have a bachelor degree in Game Programming, if that counts? 3rd level linkedin connections to gabe newell and lots of other valve employees + other companies (probably). My game programming teacher has a lot of contacts apparently. =p

I used to be base defence. =3

ctfkill.cfg

seta CTFKill "force_forcepowerother; wait 10; force_healother; wait 10; kill"
bind - "vstr CTFKill"
bind v "vstr CTFKill"

^ I still have this in my base folder.

Hey welcome. I remember your name too =o I also remember some other guy with an S name from CTF, but don't think that was you.

I had a discussion about this topic with eezstreet yesterday @Defiant. And as far as I'm concerned we did conclude there to be some issues as you pointed out.

But the issue isn't with the iojamp project itself. Since it uses original code or open source code from the q3 engine, and no parts of the JKA SDK; it doesn't fall under the SDK license agreement.

The issue is with the goal of iojamp, which is to liberate mods from the limitations of using the closed source engine. This basically means that new mods can be created utilizing new or improved features in the iojamp project. This goes against that section of the SDK agreement. Since using these improved/new features would make the mod aimed towards a different program than the "full version of the software game Jedi Academy".

So there is no legal issues in this section about creating the iojamp project. But it presents problems for people who wish to use it for their mods. And that can destroy the reason for the project to be created in the first place.

But we're talking about bounding boxes, not brush models.

I haven't looked into any details for the iojamp project, but they are recreating the jamp.exe. So it won't be necessary to distribute the .DLL files, and it's not using any code or tools from the JKA SDK. (Again, this is my current assumption, sorry if I'm wrong)

The section you are quoting is for the use of the JKA SDK to create new .dll files, and about distributing these new dll files. And the part towards the end which says "only with the full version of the software game Jedi Academy..." would basically mean that modders aren't allowed to create mods intended for the iojamp project. But if iojamp supports the usage of SDK created dll files, that's not something the .dll authors can be blamed for.

So I don't see a problem, feel free to elaborate if you disagree with me =]

Hey there, and welcome =]

The only thing a .glm exporter is good for is weapons, unless you found some way to export while going around the compile process that was used by the very developers of this game which was .xsi 3.x->assimilate->.glm that calls for the _humanoid.gla.

Yes my exporter eliminates the need for that compile process. All you need to do is File -> Export, export as .glm, and it's ready for use in the game.

Edit: And if it's still not clear: This is mainly for player models. I haven't tested it at all for weapons yet.

Considering how easy it is to actually enable rotatable bounding boxes I have no issue with telling you the process I used. I'm convinced you'd be able to do it yourself if you researched it a little. But if this is all you wanted then instead of making the prone feature I'll tell you on IRC how it's done =p Less work.

The point is that it's been requested, and multiple people have shown interest.

The exporter will allow you to export a model from 3DS max to .glm format, which will be directly useable by jka/jk2. How is that not useful?

The importer allows you to import a model from .glm format properly weighted and rigged into 3DS max. You just have to specify the correct .gla file which holds the skeleton used. For the base _humanoid.gla I will probably make it so you don't have to specify it.

There is a pair of importer/exporters for blender created by mrwonko, which it seems like you're aware of. So if that's your preference, you can simply use those.

Edit:

And 3DS max supports a bunch of formats, and many people create plugins for it. So you can probably find a way to get the model into any editor you prefer, to work on it there. I'm just providing an effective method to do the modeling process in JKA/JK2, for 3DS max.

Hey Tritoch, I remember you!

OMG, you need to email him back asap, if they still have info on the model compiler then they may have a way to properly decompile .glm and .gla files into say Softimage since the basemodels that were released by Keshire are all borked and import with no bones where the nonhumanoidmodels like rancor and such all import with full heirarchy, bones, envelope weights and animations.

 

While with the source models files someone like myself COULD compile every animation with a model rigged to it into 1 file with each animation labeled in the mixer but it would take FOREVER.

I'll be finishing up the .glm importer / exporter plugins for 3DS max soon.

I didn't know I had a reputation for being a liar. =/ Anyways, I guess I could give it a go if you must have the evidence.

Hopefully it works the same for player bounding box. There is a capsule collision method that I can't really remember where/how is used. If it's used for player and is very different from normal bounding boxes it could cause an issue for the prone feature. But what I've been telling you about is rotatable bounding boxes in general.