eezstreet

Very super early WIP but there will be the functionality to edit .menu files from ingame so it's easier to make quick adjustments to the menus. Controls You need to have the cvar "developer" set to 1 in order to use this. F11 - Enable/Disable ingame UI editor F12 - Take screenshot Main controls MOUSE1 - Select itemDefMOUSE2 - DeselectN - Create new itemDefDELETE - Delete itemDefP - Toggle Property Window for selectionArrow keys - Move selected itemDefI / K - Stretch/shrink itemDef verticallyJ / L - Stretch/shrink itemDef horizontallyProperty window controls ENTER - Edit propertyUp/Down arrow keys - Scroll through propertiesPAGE UP/PAGE DOWN - Scroll through properties (faster) The properties window, creating new itemDefs, deleting itemDefs, and saving are not currently done yet. I made a Developer Menu to test this feature out on, which will also have cheats and stuff.

As per the pinned thread:

Added a video to the first post to demonstrate this feature (apologies for poor video quality, seems like YouTube butchered it)

It doesn't exactly take it away, it makes it different, and active all the time. Basically the core (not the glow) is the only thing that blurs, and it uses a different shader for the trail to make it look like it is blurred. I'm not sure how to describe it easily, but it's very cinematic looking.

The GL2 renderer (rend2) will use realtime lighting as an option in addition to lightmaps. Which of course means that you can preview your lights and get the mood just right, unlike in Radiant. There will be an ingame lighting editor which you can use to add, remove, and adjust lights on your level. These lights will get saved to a .rtl file with the same name as the map (t2_trip.rtl for instance). A .rtl will get automatically generated at level start if one does not exist, based on a special "realtime_light" entity (which gets discarded after map load, so it doesn't affect the entity limit). No screenshots of this yet, just code, which I need @@SomaZ to assist me in finishing. I've got the code written, except for the saving and loading. Just the basic console commands for right now. https://pastebin.com/StwxpyiK It's currently set up like a gamecode file - you'll want it to probably live on the client.

Yeah - that's fair enough, we can implement that stuff later. I think it's fine if the interaction doesn't match up on the map, it's never going to look great for ammo dispensers etc without some kind of complete overhaul to how those work.

It works, yeah. But not all of the code that I want externalized, is externalized. Basically I want to get the weapons and force powers separated into external scripts or something else, so that the new weapons and force powers can be considered a scripted aspect specific to JK:E, and not part of the "engine" so to speak. If you think you're going to be ok with some more upstream pulls, then go for it. There's also a rend2-sp branch as well, and a lot of our code is in common there.

I will mark it as yellow for now until I know for sure. Are you doing any other weapons?

Does it have all of the animations listed in this thread?

I'm thinking about implementing a series of configuration files that can be used to enable/disable certain features at startup, instead of making these all cvars as I feel like it would lead to unnecessary cvar bloat (also, autoexec.cfg for instance tends to be finnicky for developing stuff with). Here's an example of what I'm thinking of, using the base game's method of parsing files: detachable_eweb { featureEnabled 1 explosionEffect env/explosion } Some of the base game's cvars can be migrated to such a system: swappable_sabers { featureEnabled 1 } manual_blocking { featureEnabled 1 blockButton BUTTON_ALT_ATTACK } I want them to be pretty convenient to handle in code too, for our purposes. Force powers and weapons wouldn't be an example of something that can be configured in this system, instead I am thinking of making those into external files/scripts somehow.

The Enhanced Development Platform is the base which Jedi Knight: Enhanced is developed on, and it's designed to be used by other modders as well. It is based on OpenJK and is targeting singleplayer only. So what will EDP offer you as a modder that isn't offered by OpenJK or JAMP? Well... Better graphics, and better performance too. EDP offers two renderers: GL1 and GL2 (better known as rend2). GL1 is similar to the original game's renderer but runs better. GL2/rend2 is a modern renderer with enough new features to warrant its own thread. On top of that, we will be focusing on changing the renderer pipeline to eliminate some of the greatest bottlenecks in the engine. And on top of that, we've added some novelty quality of life features like SFX sabers, holstering, and more. And on top of that you have this all running on OpenJK, which has all kinds of nice performance boosts.Ingame editing tools. Many of the new modding features in EDP can be accessed entirely ingame. The AI workshop lets you debug AI scripts with ease, or just screw around, if that's what you want to do. An updated waypoint editor lets you develop the navigation of the map without recompiling, and you can view your results live with the AI workshop. There are more tools coming, and these are just the start.More things, to be added in the future. I have a lot of crazy ideas which I want to implement. This is just the start. Documentation: Downloading and installing the Enhanced Development Platform, the easy wayDownloading and installing EDP, from sourceSetting up your projectAdding new weaponsMaterial workflow: .mtr and youDeploying your projectCVAR list, rend2(If a piece of documentation doesn't have a link, that means it's still being written!)

Old news, but needs to be documented: EDP has support for SFX Sabers. SFX Sabers are dramatically higher quality than the base game lightsaber rendering and can be toggled with the cg_sfxSabers cvar. Available for both JK2 and JKA. Original Lightsabers: SFX Sabers: Video comparison: Perhaps this answers your question, @@DT85 ?

Since the Enhanced Development Platform is now going to be a major part of the project, I am thinking about doing some housekeeping on these forums and making it a lot easier for people to understand. Here are some of the changes which I am proposing: Condense JK:E Weapons, Player Models, Coding and Missions sections into one forum section: JK:E Content Development which is for discussion of all development stuffMove News to the topOn top of that, I am thinking of making a new Mod Projects forum or a new forum that's part of this mod projects area, for modders to discuss the Enhanced Development Platform and to ask questions/get help, etc etc etc @@Circa @@redsaurus

Removed a lot of stuff which is specific features of EDP.

Updated roadmap.

It's based on the tool that you're using. You'd want to learn how to animate with whatever tool you're using, not anything JKA specific.

The problem is that there is no way to code for this, because servers have all kinds of ways of faking bots as players.

Thread moved to Modding Assistance

Methodology/Why I'm doing this I've spent a lot of time thinking about how the project should be organized. There's two separate, yet important goals that I want to accomplish with this project: Create a solid platform for people to base their mods off of, similar to OpenJK but taking more risks, breaking compatibility entirely with old save games and so on. Create the best possible experience for JK2 and JKA yet still retain a similar feel to opening the box for the first time.However these two goals have wildly different demands and expectations. We'll refer to the game people should play as "the mod" and the game people should develop on as "the platform" in this list: The mod should be relatively bug-free, and therefore necessitate very strongly-vetted releases. As a platform, this does not matter as much. The mod should be released in different channels than a platform; a mod should be in public download areas like on JKHub, whereas a platform release belongs more on a forum. The platform needs loads of documentation to ship with it, so developers know how to use it. This would be completely unnecessary and even confusing on a mod release. A mod release should ship with all of the best assets, whereas a platform release should come only with testing assets. A platform release, ideally, should have material relating to both games (JK2/JKA) and all of the different renderers shipped with it. A mod release only should target one game, and ship with two renderers, maximum. A platform release would be shipping with .map files, model source and source code, which is wholly unnecessary for a mod release.Therefore, it makes sense to distribute two separate versions. There will be JK:Enhanced (which will have JK2:Enhanced and JA:Enhanced as "child" mods) as well as The Enhanced Development Platform What is the Enhanced Development Platform? The Enhanced Development Platform is a modding-oriented codebase. It is based and design on the concept of OpenJK. The main difference between this and OpenJK however is that we're generally going to be breaking savegame compatibility on purpose and be more open to feature requests. The philosophy will also be different, since we are targeting modders specifically, and not players and modders like OpenJK is. (OpenJK is also targeting Multiplayer and Singleplayer. We are targeting only singleplayer.) Releases on the Enhanced Development Platform will be frequent and available for all three major OSes (Windows/Mac/Linux). The EDP opens up a lot of the hardcoded stuff and makes that more accessible to the modder. Information on this will be forthcoming. There will almost certainly be a lot of bugs and possibly crashes or worse. We aren't focusing on making the platform stable. However, "stable" releases will be marked as such. What does the EDP offer me, as a modder? It's a stable codebase, like OpenJK is, but there's a lot more experimental/interesting stuff that's been implemented. A lot of this breaks compatibility with the original savegames and can't be implemented on the main branch of OpenJK. A non-exhaustive list of things that will be offered in the EDP, in both JK2 and JKA: rend2 - A modern renderer that utilizes Physically Based Rendering and advanced techniques like normal/bump mapping, real time shadows and specular mapping. (More information / Announcement)Aspect ratio correction for fonts/text/some imagesSFX Sabers - These saber blades, most notable for appearing in Moviebattles and originally appearing in OJP, are a vast improvement over the original saber rendering technique.JSON Weapon System - Swap out your weapons.dat for a new JSON file which loads faster and can be changed ingame with a cvar. It also has more fields that can be modified.GHOUL2 First Person Weapons - Use the power of the game's GHOUL2 model format to create animated first person weapons.The AI workshop - Manipulate NPCs with console commands (More information)Ingame Navigation Editor - Alter the game's waypoints/point_combat places ingame without recompiling the map..eent files - Add extra entities to maps without modifying the BSPWeapon Holstering - Weapons can show up on your player.TrueView 2.0 - View your feet in first person, or just view from the third person model's head/spawn command - Spawn entities ingame, like Lugormod's /place commandPerformance Improvements, Bug Fixes - FPS has been improved across the board. Lots of minor bugs in the game have been corrected, thanks to being based on OpenJK.Sample Library - All of the map samples, sound effects, script sources, etc are wrangled up in one place. When will EDP be available? Technically, the code for it has always been available (https://github.com/JKEnhanced/OpenJK) but over the coming months there will be some changes to the code, new documentation written and automatic code deployment to help make things easier. What does this mean for JK:Enhanced/the mod? It's a good thing, since the development will be streamlined and we can appeal to modelers/mappers who want to help out. My time will probably be taken up by writing documentation, but I've been idle for a lot of the time anyway because much of what needs to be done is art assets. Plus it totally gives me a good excuse/motivation to work on actually neat/crazy stuff that will never be seen by the players anyway, like an ingame scripting system or something crazy. These forums are going to get reorganized as well.

The angle of how it's held is mostly what bothers me. It should match the original game better.

Well, OpenJK supports an external .ent file, but I just bake it right into the .bsp. So basically yeah, it's compiled into the BSP. What I do is pretty simple, and I'm surprised nobody has written a tutorial on this: Decompile the original map using q3map2 Modify the entities from the .map using Radiant Run q3map2 -onlyents Bam, you've modified the map's entities.

Well, this is its own source fork...so....?

Erm, depends. I was the one who wrote the original XInput code that was in OpenJK before, but you had to compile with that feature enabled.

Like?