eezstreet

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.

I was thinking that maybe the crane is necessary to unlock the doors on the other side of the giant lift. When the lift has a certain amount of weight on it, the lift will raise and the opposite doors will unlock. A numeric display (with different textures: "0/45", "15/45", "30/45", "45/45") indicates how much weight is on the lift. I think if it comes down to it, I might use cinematics for the crane movement so the player can see what they're doing. So perhaps room placement won't be an issue.

Got it. Sorry, for some reason it didn't mark the thread as unread! Here's my impressions of the map: Entry room: very nice, very well lit. It seems like you used some more precise shadows. What was your q3map2 line like?First room, generators and flanking stormtroopers: Missing texture on the buttons that control the lifts. The blue power lines (the hole in the floor that you can get into) don't seem to connect into the walls all the way. I would've picked a different texture for the floor here also.All of the doors don't have sound, and there's lots of areaportalling problems. More of a quirk/optimization problem. The tall green doors seem to open a bit quick, but the rectangular grey ones are awesome.Goodie room: I really like what you did with these rooms. They have such a dark and forboding presence. Really good job. I have no complaints. Every time I look, there's always some minor detail that catches my eye. Amazing stuff.Stairway room: I think the cylindrical crate in the middle of the floor was a bit odd, it maybe perhaps should've been to the side. In order to improve gameplay, consider adding some crates next to the stairs that the player can take cover behind. The stairs also need to be moved a bit, because the player can slide between the stairs and the wall. I have a feeling that some people will get stuck here.Stairway room, upstairs. One of the grates was bugged and I can pass through it, while the other one was properly breakable. Otherwise, I have no qualms. Looks great.Proceeding upwards. The side areas of each T-junction feel a bit drab, like perhaps they need something on the floor. They all sorta felt the same and it would be pretty hard to tell what room I was in. I also feel like the breakable section of floor was not very noticeable at all, and perhaps needs something a bit more obvious. I like what you did with the little power pipes, I thought it was a nice touch.Proceeding down the rabbit hole. I really like these hallways. They have lots of color and vary just the right amount. The area that they spill out into though, felt a bit drab. Again, maybe it needs just objects on the floor here, like control panels or something. The lift didn't seem to work, so I'm using noclip here.Oh my gosh. This control room is awesome. I really really love it! The top floor is really well done. I think the bottom floor could use a bit darker lighting though for more contrast between the upper floor and lower floor. What do you think of this idea? Also, something about the walls coming up from the lower level on the ramp bothered me, but I don't know why.The room that this leads to is also really awesome, and I have no complaints about it. Pretty much none. I really love what you did with the pipes.The pit has a bit too bright of lighting. Also there needs to be some way to get to cairn_reactor from there. Maybe some doors or something.In terms of level flow though, I'm a bit concerned. I'm not sure how we're going to work the crane puzzle in. Maybe it's required to open the doors on the other side of the big stockpile lift?

You should submit a pull request with those changes to the code, if you haven't already. Also I'm about 90% sure that issues with SDL are fixed in latest OpenJK.

Except when the situation isn't ideal for it. OP, what are you using the vector for?

KOTF had a few scripted levels from other people's stuff. The one I remember was Kamino.

Why not make your own mod? The KOTF handle is tainted by the name. I don't understand why you didn't take other people's advice to heart.

Thread moved to Mod Requests and Suggestions Welcome to the forum. Please take the time to read any stickies in the forums before submitting a topic. @@JBuNNy

Looks very nice. I can't find many complaints. The only thing I would suggest changing is the upper level of the big room. I rather liked the old white/grey/brownish lighting, it makes it a bit different from the rest of the level. I'm not sure how you feel about that though. What's the last room that needs to be finished?