eezstreet

I'm talking about JK2 code in this thread, not JKA code.

To others: Leave him alone. If you have personally had your model stolen by him (or know of others who have had theirs stolen) in this thread, then you can confront him via private message or talk to the staff. Otherwise, stop instigating. I don't care about MB2 drama, it doesn't belong here. To T R I S T A N: Calling people morons, filth and anything else isn't helping. Don't reply to negative comments. Your thread is going to get locked if half of your comments in it are rude words towards other people. To all: Keep it civil.

There is one in the EXTREME WEAPONS PACK and one in Gunslinger's Academy.

Worldspawn is on every map, not just OpenJK. It's classified as an entity that contains various level info properties for the whole level. Worldspawn is a poor example though of what an "entity" is in this engine. Entity refers to anything in the level that isn't hard geometry - spawn points are an entity, NPCs are an entity, etc. Worldspawn does not actually get spawned, its values get copied deep into the code and discarded.

My original link is still accurate, because as far as I know, the code hasn't been merged into the JKEnhanced repository yet.

"Menu descriptions" ?

Sorry about this - I meant to try and get 1.3.0 released in January, but I've been completely swamped both with school and other projects. About the middle of the month, one of my side projects got huge exposure. I hate advertising it here, given the context, but talking about it and why it's important to me is kinda relevant to the topic at hand. About a week ago, GOG.com told me that they were releasing SWAT 4 for digital distribution (the first time it had been made available). They also went on to highlight my mod and later the mod got reported on by PC Power Play. If you're interested in what I'm working on now, you can check it out here. The next version is coming out soon. There's still not much to be done for 1.3.0 of JKG though. I think just the visual overrides and the ammo menu. There's bound to be lots of bugs though. I'll try and get back to it; it's not me walking away, I'm just really busy.

TGA and PNG are the same filesize when inside a PK3; they're both being compressed via zlib in some form or another. The difference is that PNG loads slower than TGA because PNG needs to be decompressed twice - once when pulling it out of the PK3 and once when reading the actual file. The flipside is that PNGs are easier to work with in Photoshop. You should always use TGA over PNG.

seta command is love, seta command is life. Use it instead of set, it'll archive the cvar and store it in your config.

(sounds like something @@Raz0r wanted to do too)

This is some pretty impressive work. Does it network well in multiplayer (ie no lag)? Is player collision tied to the boxes too? (ie, can you stand and jump around on them?)

Maybe he's too busy to say that he's busy.

Or...he's just busy. Cut him some slack.

The ammo stuff is finally, finally working and ingame, minus the overrides, the ammo menu, buyable special ammo, display of which ammo type you have equipped, and the physical "buy ammo" button. Whew! That's a lot of work left to do still. Either way, you can have a look at the current ammo file here: https://github.com/JKGDevs/JediKnightGalaxies/blob/develop/JKGalaxies/ext_data/ammo/JKG.ammo Here's a current list of planned fields: shortname: The name as it appears on the HUD.longname: The name as it appears on the ammo menu.max: How much (total) can be heldbasedOn: If this ammo is derived from another type, this is the base type. e.g, Incendiary Slugthrower Rounds are based on Slugthrower Rounds.pricePerUnit: How much (per ammo unit) it costs to replenish ammo. Can be fractional, 1.2 for instance will cost 120 credits to replenish 100 rounds.overrides: What this ammo type overrides. It can be things such as visuals, collision size, damage, and other things.There were two new fields added to .wpn file firing modes as well: ammoBase: The lowest base that this firing mode acceptsammoDefault: The ammo that is given upon purchasing this weapon and also with the Buy Ammo button.

Or... Add 32 to the spawnflags of your info_player_start. You'll start with the stun baton instead of the lightsaber.

This is definitely an interesting experiment and a testament to open source development. It might be adopted in the future as a base for the Phase 2 graphics enhancements. I have some questions for you about this renderer: What does Magic Detail do?Is there a chance for color-grading (LUT/Math methods), perhaps tied to specific postprocessing volumes?Could you possibly look into animMap shaders working in 2D? I understand that EpicLoyd is working on Awesomium for Warzone, but having to manually animate things through code is a pain.Thank you. Keep up the good work!

The game's "brightness" setting is a lie, it's actually raising the gamma via Windows gamma ramp. It's impossible to fix the alt-tab/crashing affecting your game brightness, and other applications have this problem as well. It's up to Microsoft to fix it unfortunately. If you set r_brightness to 1.0 (or 0.5, i can't remember) it'll reset to the default.

C L I C K B A I T

You're probably realistically going to have to use a whole new AI for something like this. It shouldn't be too bad though, if you use the Saber Droid as a base.

This has been released. There will be a scrimmage match coming in a few weeks - I have to prepare for classes first.

well?

Random question: why ioq3 over JA engine? You can have everything you want.

And I wouldn't recommend doing that anyway! The DLL in a PK3 method is just a carryover from when VMs were stored in the PK3 - it's not recommended that you put them in a PK3 because it will extract them to a temporary directory which might screw up updates.

I'm not going to bother to read all of these responses, because I'm just going to get confused. Instead I'm going to give a pretty concise explanation of where everything is supposed to go, similar to @DarthFutuza's answer although perhaps a little more robust. The following files should be in your Gamedata folder: EXE filesrd-vanillax86.dllrdsp-vanillax86.dllSDL.dllOpenAL32.dll (should already be present)The following should be in your base or fs_game folder: jagamex86.dlljampgamex86.dllcgamex86.dlluix86.dllBy switching the cvar fs_game to something else (do it with a commandline parameter, +set fs_game X) you can load the modcode (the stuff I've listed above) separately and not have to overwrite files. Alternatively all of the above (except jagamex86.dll, I think) can be placed in a PK3 loosely. The easiest method (by far) to test your code would be to run the debugger on it, which allows you to set code breakpoints that get triggered, and see the value of variables, which is a very useful thing to have. Release builds are more suited for well, releases.

Ironically this is something he critiqued in Episode 3 (or 2? I can't remember) as being a problem. I think you've got the right idea, but the example you used here isn't a great one. Showing vs Telling is all about what's appropriate for the situation. Showing is more appropriate when we're talking about the relationships between the main characters, major plot points, etc. that are incredibly pertinent to the main story. Telling is more appropriate with side characters or when the information is too complicated to explain by showing. I think a better example would be something like this (using Ep1 as an example): vs, a much better approach: