eezstreet

GitHub is not really the most user friendly website though. And it's not simple for the uninitiated to install at all, unless you want to take the dirty approach of dropping it into your Gamedata folder directly. I agree, every mod should be using CI, but CI is a pain to set up and get working correctly. Consider this approach to be CI and an updater all in one, that uses less bandwidth to boot. If a mod doesn't compile, then it doesn't compile. Another nice problem this launcher could fix is have a bug reporter built into it like with JKG's old launcher that would create a GitHub issue without the user having to get a GitHub account. If a build fails for that repo, it can create an issue titled "Won't compile on <platform>" with the output of gcc as issue text.

I mentioned it in an edit, I think JKHub just shit the bed lol. The thing I'm trying to solve is the issue that modmakers need CI or need to have somewhere to host their builds. With this launcher, the need for CI to provide builds is effectively eliminated (although whether or not it compiles, you still need to determine on a local copy). Also with this launcher, you could provide a curated list of repositories for people to try out without them having to hunt down the modmaker to provide builds, follow dodgy install instructions, etc and serve as a launchpad for other features, such as achievements and a larger JKHub API. Basically, I want to solve the problem of both difficult installs for new users and modmakers to provide hosted builds.

To be clear, it would be downloading the source code via Git or something similar that uses delta compression techniques, so you wouldn't be redownloading the entire source code every single time you need to update, you would just be downloading the changes. I think you are confused with how that particular optimization would work. If it becomes an issue that downloading the source code and compiling it becomes such a huge burden for people (it really isn't, there have been big advances in things like delta compression and compiler design to where it would only take a minute or two to compile), the first person whose client would compile the game on a particular platform would upload the build in the background, and other clients can use that instead of compiling the source code. But I seriously doubt that's an improvement, it seems like a downgrade even. Like I said - look at how much Git downloads whenever you pull for updates. It's maybe ten kilobytes, max, vs a whole new client, which is several megabytes. Disk space is cheap, bandwidth is expensive.

It's not supposed to be faster. In fact maybe an improvement would be to have the first client download the source, compile it, and upload to some kind of website?

It solves the problem of having to provide precompiled binaries for people to use for each platform. Traditional CI is just not optimal for 90% of projects which are too small to warrant setting up appveyor or Travis CI or other services for them. This makes it easier for people to find binaries and makes it easier for programmers to provide them. Likewise, it guarantees an easy install for mods, and people could supply compiler options such as VEH_CONTROL_SCHEME or other stuff that's disabled normally. It solves multiple problems, not just one. The point isn't to make this a launcher specific to OpenJK, but one that's capable of running any OpenJK based project. Ideally someone can simply say "I want this specific fork" and compile it on their machine using the launcher, rather than having to see if that person has builds for it. It makes finding mods much easier when they're in one nice little housing. Honestly a lot of your points sound like organizational issues of OpenJK, and not issues with this launcher. If OpenJK doesn't have a stable branch, that's a problem of OpenJK, not a problem with my idea.

kdiff works. You need to set up a remote for the OpenJK repository if you haven't already. Here's how you would do it: git remote add openjk https://github.com/JACoders/OpenJK Switch to 'develop' branch: git checkout develop Pull from OpenJK: git pull openjk master Resolve conflicts: git mergetool

O_O @@Darth Futuza

Just pull and resolve conflicts using mergetool. Make the software do the work.

Use OpenJK. The MiniHeap issue is fixed in it.

So after a bit of a discussion with @@Caelum about this over Discord, I had an idea in my head for a while. What if everyone could compile OpenJK? Yes, I mean obviously, everyone can compile OpenJK, there's a whole tutorial about it and everything. But what if that was the primary way to install it? The idea is very simple. You have a launcher with several options. Each of these options corresponds to an OpenJK repo, like those in the fork megathread. The program would then clone the code from that repository, compile it, and stash it for safekeeping. You can then launch the compiled code (if it compiled successfully, of course!) with some options like fs_game, etc. Every time you switch, it compares the stashed compiled stuff's git hash to the current head so you wouldn't be compiling the code every single time you run the game, unless there's updates. Pros: Effectively eliminates the need for CIAnyone can compile and run any repo, no need to ask for current compiles.Can act as a springboard for other features, such as server browser, chat, JKHub API platform, etcEveryone is always updated to the latest versionCons: Not really useful for serversNot sure how to package a C++ compiler, cmake, scons, etc within an app and have it work well.It's more work to do.tl;dr how it would work: Get URL of repo that you want to play with (http://github.com/JACoders/OpenJK for instance) and branchHit magic "compile" buttonSet your fs_game and run the gameYou are now pro-g®amerpinging some coders @@Xycaleth @@ensiform @@Raz0r @@mrwonko pinging some players @

I don't really put a price on jobs, because there's always the possibility that it could turn into a massive debugging nightmare of 5+ hours dealing with it. I really don't anticipate that happening though. Give me your files in a PM and I will give you a quote. I'm not. I'm somewhat of an expert when it comes to this sort of thing, I expect to be paid like one, especially since said task would be cutting out of my own time.

How about a compromise: you have to talk to people to acquire the missions, but actually go to the ship to execute them. That way, you can get all of your missions in one go, compare them at your ship, and don't have to bother running around the temple again after you finish them.

I don't know what the work you want me to do is. I generally charge $20/hour for any freelance coding that I do.

How much?

To clarify: Asteroids was made by a Raven Software employee, not officially released by Raven. I'd consider tackling vehicles if it meant first person models for controlling the vehicles. Dogfights are just so much better when you're behind the controls.

Linear? Or non-linear? That is what we should decide first.

Thread moved to Modding Assistance

I can't find anything that suggests a difference immediately. Maybe you could try with my JK2 Enhanced alpha.

Well, the weapons.dat is replaced with a weapons.json, that can be swapped out with a cvar. Maybe not in the current version of Academy, but definitely in Outcast. It's always been my intention to have "infinite" weapons which use some kind of external script for logic. I originally tried this in Angelscript and then in Pawn, but I want to try at least a few other options (including a homebrew functional programming language-like Haskell) before (probably) settling on Lua. So consider this "something we always planned for"

You can't use the SDK at all with singleplayer. Use OpenJK instead. My tutorial has everything you need to get started on Windows with it but it might be slightly out of date (Git for example is now required).

I could maybe do the crane, yeah. I was thinking about ditching the supports and making a large crane with a magnet. Basically, here's how it would work. The crane is mounted on the walls just below the ceiling via guide rails. The crane itself consists of a magnet device that is mounted in between two pairs of rails. When the crane moves left/right or forward/back, one set of rails moves in a direction. When the crane moves up/down, the magnet is lowered from a cylindrical housing positioned between the rails. Easy way to visualize: make a peace sign with one hand, and then another. Using your hands, make a square. The magnet housing would be in this square. So in order for this to work, there's going to need to be a few entities: - two sets of rails, each pair being a func_static. - magnet housing and the magnet itself - one func_static - Four ref_tags representing the bounds of where the crane can move left/right/forward/back I need to ask a few questions before I can think further: - Should the crates be an equal size? - They should stack in one block, correct?

Areaportalling is really a last-minute optimization, we don't have to worry about it right now. And yeah, I knew about the maglocks. It's a similar situation to ns_hideout I believe which has maglocks added so the player can navigate easier. The player movement controlling the crane is something that I could write code for, but it's really not necessary. A much easier way to do it would be to make a grid. I have some ideas for scripting the crane puzzle without using any code.

Um, who told you this? Lol. You can't include the original game assets with any mod, legally, because they are part of the Jedi Knight 2/Jedi Academy intellectual property. You can include modified assets with a mod because it becomes your own intellectual property. Whether or not your mod uses OpenJK is completely irrelevant. See: Jedi Academy Enhanced, which shipped with both modified assets and OpenJK compiled. Where I think you're getting confused is with including modified assets with the source code. It's generally considered to be non-kosher to include modified stuff (.menu files, etc) that weren't part of the original release because these files were not originally licensed under the GNU GPL. It's not the OpenJK devs decision to relicense the UI stuff in particular. This doesn't apply to MB2, which uses the SDK license. They can absolutely pass those files around. The SDK license (as opposed to the GNU GPL) also reserves the rights for the owners to refuse to provide source code. MB2 of course can't use any OpenJK modcode fixes without being relicensed as GNU GPL. Different debate on that. tl;dr just don't pass around .menus in your source code unless you're licensed under SDK, which MB2 is.

GLM is an extension of the MD3 format with the following differences: * Bone-based animation (as opposed to vertex based) in a separate skeleton file (as opposed to embedded in the file itself) * Textures are specified in an external .skin file as opposed to embedded in the file. * LODs are embedded into the file, as opposed to being separate models. GLM is superior in almost every way to MD3 because of its design. The only place it makes sense is for static map objects - these get converted into brushes (or more specifically, patches) which have their own LODs.

Yes, but I'd prefer it if the +forward etc were just hardwired to the controls.