ensiform

What do we need to do for a release to happen still?

Testing? Bugs? SP fixes? Licenses & Icons, Installer?

Perhaps use the debugger  Or read the other code a bit better?

Blindly using vectors in gentity_t will make it non-POD/standard layout and thus offsetof etc will no longer function.

It is independant to OS bitness. Use int64_t.

@ensiform, if he is making new weapons then save games compatibility is out of question - it's definitely won't be compatible anyways. I am sure he knows that.

But is he distributing a new engine or just a mod?  Engine changes is required to make either/any solution work.

And you now have to change that ENTIRE stat array to int64_t if you want to go with ent's option.  Plus the MSG_read/write functions also do not support > 32 so more changes required there as well.

Level transitions code in engine also blindly assumes the stats array is a regular int when reading/writing to the cvars.

There is no EASY solution for this.  The best imo, is to add STAT_WEAPONS2 but then you also have to create some functions for bit setting and bit checking and removing etc and replace all areas where STAT_WEAPONS is used with those functions to use the correct STAT_WEAPONS or STAT_WEAPONS2.  That one place you've shown is not the only location you need to look at unfortunately.  I cannot really help you with this right now sorry.

Something like this:

You'd have to use these everywhere pretty much though in place of the equivalent final line in each respective function.  And I'm not sure how that would work for the function you listed yet as it gets a bit more complicated.

qboolean BG_WeaponArrayCheck( const playerState_t *ps, int value )
{
	int choice = STAT_WEAPONS;
	if ( value > 31 )
	{
		choice = STAT_WEAPONS2;
		value -= 32;
	}

	return (ps->stats[choice] & (1 << value)) ? qtrue : qfalse;
}

void BG_WeaponArraySet( playerState_t *ps, int value )
{
	int choice = STAT_WEAPONS;
	if ( value > 31 )
	{
		choice = STAT_WEAPONS2;
		value -= 32;
	}

	ps->stats[choice] |= (1 << value);
}

void BG_WeaponArrayRemove( playerState_t *ps, int value )
{
	int choice = STAT_WEAPONS;
	if ( value > 31 )
	{
		choice = STAT_WEAPONS2;
		value -= 32;
	}

	ps->stats[choice] &= ~(1 << value);
}

Who told you it can "only" have 32?

Adding new structures (or changing their object size) to clients will cause save game incompatibilities, sadly.  And in SP this field is engine-wide not mod-only.

The other option to avoid needing int64_t would be adding an extra STAT_WEAPONS field.  And using some bit storage checks to determine which array is currently being used.

Don't know anything about the AI stuff sorry.

I concur though.  The CGame will have a field day with any sort of changes of that way.  Think of how the trap calls to loadmap will be affected and inline models/bmodels.

Only thing that worries me about selecting D3/Q4 formats is they are very heavily biased to the old corridor running maps. They would overcome a lot of limits I imagine, but are not really suited to anything like a large star wars universe. When JKA was created there really wasn't anything better, but now I think we could find something more generic and yet common.

These constraints are not going to mysteriously vanish from the engine though even if the map editor and potential compiler can do more.

I wouldn't choose source engine, hammer is so shit to use. I dunno whether it's the map or the game, but I really hate that little loading thing that happens in HL2 SP.  I'd rather Doom 3/Quake 4 because I know the Quake 4 editor is built into Quake 4 itself and we could do the same thing.

 

Would we need to match licenses or can we just implement any format @@ensiform @@Raz0r @@Xycaleth?

Realistically implementing the renderer and or editor together shouldn't be very difficult to do in the long run if starting from scratch. 

(You can't use this but just showing you that its been done)

https://github.com/TheDushan/OWEngine/blob/master/code/Engine/gphysics/bullet/btp_staticMapLoader.cpp

I've already seen bullet used with q3 bsp/maps.

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.