ensiform

@@Xycaleth the DMA sound backend wont go away. The both ones will just be migrated and cleaned when we get there. What mod loading problems? >> Mod menu I suppose? Though connecting to a server is actually worse than using mod menu :} And our hands are slightly tied because of svc_setgame and the fact that overrides are in pk3s.

There is 1 very large glaring issue with adding cloth as a shader parameter in that you can no longer distribute the mod as working for the original game. Because the original game's shader parser will see "cloth" and "go uhhhhh wtf is cloth", and mark the shader as defaulted. There are a few ways around this and since this is likely something to go in a non-vanilla renderer, we can always add .mtr that will get loaded with newer shader parameters and the old .shader files are used as fallback for compatibility. (SmileTheory's renderergl2 for ioquake3 does this iirc) Seems to me like it would make more sense to just fork the game and try implementing a full fledged new physics engine instead of only focusing on cloth. @@Archangel35757 Neither of those implementations seem like they're even decent fit with the existing engine.

SET_ORIGIN is probably fixable, but unfortunately move() is not, simply because it sets the entity type to being an ET_MOVER rather than ET_FX which means no more fx. In SP this is fine because its already being a ET_MOVER and it plays the effects directly from the game-side code. But because clients are using ET_FX to tell it that it needs to handle it as an FX entity we can't fix this without a compat breaking change.

Yes that would be nice @@badhex I and most here generally idle on the #jacoders on arloria irc network so faster chat etc.

"Pretty much sounds like a no-cd crack" When it has nothing to do with removing cd key checks other than its not even the same game engine anymore so that license does not apply. I don't really want to keep discussing this, so: A) The license agreement with the game will apply to assets (Nothing from the assets will be distributed with iojamp if it ever released) B) The SDK License agreement prevents you from making new mods that don't specifically also run with jamp. If you keep them compatible, then I don't see it violating this (the same applies to Quake3 mods that are still closed on the MOD SDK) C) The iojamp license is under GPL rules, not the license agreement for the jedi academy installation therefore the cd-check bits do not apply.

Whatever. Just so long as this discussion about licensing doesn't keep being brought up in a non released form of a wip project.

Just drop it kiddo, go play with the other younglings in mods-ville. You can bring up this discussion if it matters at time of release.

You're thinking this way too critically and in the wrong sense of legality bro. A drop in replacement for the core exe has no berings on the assets or the dlls as such the ONLY problem is making new mods that no longer function with JKA. If the base dll is still the base dll (completely unmodified), the "License agreement" has no say what-so-ever if I choose to load a dll from whatever. If that were the case, then I shant be allowed to link some random dll thats in the system32 folder. FYI The SDK License means absolutely shit all NOTHING when you aren't going to be using the SDK (using the dlls in assets3.pk3)

ohai I don't get why you guys think that anything raw sw related will be getting distributed with iojamp? Its a drop-in replacement for jamp.exe. While I get that some of you want mods that would be based off it, the grey area says u really can't. However the same applies to mods that are closed source on quake3 yet they will try to run on/with ioq3 or ioq3-modified builds. When everything is hunky dory it will end up being: (If by going with the above rules, you won't be able to have a 64-bit version then either and possibly not other platforms than what is already there?) (For windows anyway)