ensiform

Bullet shouldn't be too difficult if it can import the bsp data from the engine somehow without having to re-load the entire bsp another time.

Adding weapons to MP isn't that difficult but it would not work the same way in SP due to save breakage in the binary not just mod AFAIK.

I would caution against changing the maximum number of things in Single Player or adding things to some structures. This time may not affect things, but it is possible you might break save files doing so in the future In a perfect world everything under the sun would be nicely customizable by mods/script files but its not unfortunately.

@@mrwonko, Of course but the program is obviously lacking some shit that was added in 1.5/netradiant then it needs the capabilities to do those things here. The codebase is undoubtedly a nightmare. NetRadiants is at least mostly C++ but its over-engineered C++ IMO and it looks just as bad as the mixed interface in 1.4/1.6. But nobody really really wants to be the 1 person to make a new radiant from scratch when so few use the tool. Which is where one should start first anway. q3map2 essentially has to stay or else you won't get the same resulting maps.

Fixed width texture size option is also coming to 1.6 down the road:

._. Hats. And probably more teamplay modes that aren't focused solely on flags or saber duels.

Not adding g2 model rendering. Maybe @@Xycaleth wants to port the R_LoadMDXM stuff to picomodel, but its over my head.

I recently submitted a patch to GTKR 1.6 to add misc_model_static for model preview. This has been lacking for a long time. Might look into some other other stuff thats missing but was in other variants at some point.

Attempt to copy the ioq3 one for starters I would prefer if it had its own section entirely. So OJK is the main page with a logo etc.

I just created that

I don't know if they would even be available or willing Rich is not, for sure. Also @@mrwonko @@Xycaleth @@Raz0r we need to categorize some of the headers if you want them to be cleaned as far as what would go where. So far I have q_endian, q_types, q_validatehelpers.

We could use someone to fix up G2 handles usage in SP. Also cleaning up module access in SP between gamecode and engine. ALSO SP could use someone who knows how to serialize existing data structures and keep it compatible with base for savegames.

It needs to be more OpenJK specific though so users don't have to go searching. And the github one is less user friendly for people not looking to compile from source.

I'm thinking a Wiki of documentation would be a good idea? I realize we probably need some sort of offline documentation for users too in case they don't have internet etc but: http://wiki.ioquake3.org/Main_Page This has a lot of concerns addressed that we would need to be addressing to our playerbase and server admins as well.

There's a good chance that you are using an old version of rd-vanilla causing this but it's hard to verify without more information regarding the crash.

Note, openjk sp uses "autoexec_sp.cfg" to separate the autoexec configs in case you want it to do something different from MP. Quotes don't affect OpenJK either so I'm not sure what you're describing. You also don't need to use seta when using the console.

Multiplayer or Singleplayer? What were you expecting widescreen wise? What config file in base folder? In openjk the main config is called openjk.cfg and it is saved in C:\Users\USERNAME\Documents\My Games\OpenJK\base and autoexec.cfg can still be loaded from either place. You can enter this in the console for 1920x1080 (example) r_customWidth 1920 r_customHeight 1080 r_mode -1 vid_restart or r_mode -2 vid_restart Will pick your desktop resolution. OpenJK cannot change menus, its against the rules of the source being released so there is no extra resolutions in the menu for you to pick.

I can't directly help you get it up to date unless you set it up properly as a fork with upstream as a remote.

It is possible that just newer compilers / floating point optimizations have caused some sort of issue here?

I don't really know who gave you the idea that the cap was implemented, evidence from them would be nice.

It would be best if you just updated your local custom build by merging or rebasing with the upstream. If you don't have shadows turned on, the ripples will not work.

The dismember cvars are not changed in OpenJK.

What did you call the pk3? If its sorted alphabetically before assets3.pk3, of course the base one will get used first.

PK3 in gamedata will still work just fine and place it where all things are written to as I said usability is irrelevant. Priorities are the same as jamp, just the homepath was empty by default on windows.

jamp.exe copied base dlls to the (GameData/fs_game) folder too when joining a pure base server this has not changed only the location. You can put your pk3 in gamedata and it will still copy to homepath just fine. I don't see what is confusing. PK3s are loaded from both locations, writes/copies of any kind only happen in My Games now is the main difference between jamp and OpenJK.