-
Posts
1,626 -
Joined
-
Last visited
Content Type
Profiles
News Articles
Tutorials
Forums
Downloads
Everything posted by ensiform
-
Okay well, any code portions of the project you release must be open source because the code license is GNU GPLv2 so I don't see why you bother leaving it closed to start with. Only makes it harder later and now you don't have history of changes etc. And github does not allow you to create forked private repositories from public repositories, plus private repositories cost money.
-
I really recommend learning to program a bit plus figuring out things like finding relevant places in code that might relate to what you are working on and maybe using a site that hosts code like github for storing stuff so changes are easily available instead of just code snippets on here which will inevitably get lost. Github also has the gist feature for posting code snippets/files with syntax highlighting and tied to your github account which can be linked to or made private.
-
Enough with the octree shit archangel... We get it, you want something else besides just BSP or along with. Stop pushing that other people are making slight hints about it too.
-
In what way? The BSP is not changing simply because of the renderer being used.
-
Are we also waiting for SDL 2.0.4 so that the externally blocked issues are fixed?
-
Its not really a high priority. You have yet to convince me there is anything out there mod wise that is truly broken on base as of yet. The cvars support is not a new section in the save file. They will still load just fine just without the cvar being set. As they are just variables in icarus. The checks can be done earlier but I think the game should be able to look too as a last ditch especially for people who do not install via installer.
-
#706 is not a requirement for a release in any way shape or form. Why would it be? Verifying JA stuff can and probably will happen during the games startup ?
-
Well, MAX_SABER_VICTIMS is definitely not the same problem since its just an array size not floating point data.
-
Dismemberment has not changed. Nor has the value of MAX_SABER_VICTIMS. There isn't any sort of comparison happening that I could see that would make it relate to MAX_PATCH_PLANES error directly. MAX_PATCH_PLANES was fixed back on January 24th. FWIW the newer compilers aren't doing anything specifically wrong.
-
JK2 is irrelevant at this point in the discussion but JASP still is of course. https://github.com/JACoders/OpenJK/issues/699 (closed) https://github.com/JACoders/OpenJK/issues/696 (open) https://github.com/JACoders/OpenJK/issues/697 (open) https://github.com/JACoders/OpenJK/issues/698 (open) https://github.com/JACoders/OpenJK/issues/707 (open, jk2) Dunno if all of the open ones are still valid or not.
-
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.
-
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.
-
Revival of JKA's modding community
ensiform replied to Xycaleth's topic in General Modding Discussions
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. -
Revival of JKA's modding community
ensiform replied to Xycaleth's topic in General Modding Discussions
These constraints are not going to mysteriously vanish from the engine though even if the map editor and potential compiler can do more. 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.