Jump to content

Raz0r

Members
  • Posts

    1,135
  • Joined

  • Last visited

Everything posted by Raz0r

  1. Are you definitely using the JA++ client-side? It's required for weapon duels. Vanilla/other client mods constantly try to reset the weapon back to saber each frame when you're in a duel. That explains why you can't see their saber (because the server is telling you they have a weapon) but you can each see yourself holding a saber.
  2. Worth checking your GPU vendor's control panel for any "profiles" applied, like forcing anti-aliasing etc.
  3. The only real answer is: talk to your lawyer if/when you're serious about releasing anything, especially commercially. No one on the internet can really give you the legal advice you need. That being said, my advice is steer clear. My other advice is start with ioquake3 (same engine JK2+JKA are built on) and work from there, to avoid "Star Wars" (read: Disney and their infinite financial + legal resources) coming to bite you. I'd also steer clear of "laser swords" and "magic" which could be reasonably argued by lawyers to no end. You'll need a lot of coding experience either way you go. JKA is specifically a legal grey area, given the source was pulled and a gag order given by Our Great Overlords specifically over licensing/legality concerns. There are a few other threads discussing this and similar ideas. Quick search showed these will be of interest: https://jkhub.org/forums/topic/1974-openjk-general-topic/?tab=comments#comment-23405 https://jkhub.org/forums/topic/1986-why-cant-you-use-assets-in-non-commercial-standalone-games-exactly/
  4. Late to the party, but is there _any_ more information in the error message or console? 99% chance it's an issue with the mod referencing a filename or name of a model/shader/sound/etc that's simply too long.
  5. For posterity, JA++ code has been at https://github.com/Razish/japp since ~2013. No one ever got JA+ code from Slider as far as I know, he hasn't been active in the community for a long time.
  6. Pretty sure it's `cg_saberContact 0` and possibly `cg_saberModelTraceEffect 0` + `cg_saberClientVisualCompensation 0` Appears to be handled by cgame/cg_players.c -> CG_AddSaberBlade
  7. Thanks for the report, added to JA++ as of commit 23ea718
  8. Glad you figured it out. I've now built this into JA++ as of commit ec26a23 ?
  9. Raz0r

    Operating Systems

    Not sure if serious. Android port of JA has been done (xlava, ent, couple others). I think mobile and browser platforms are just nowhere near practical enough to warrant that kind of effort - 3 people dicking around for 5 minutes is hardly worth it. kungfooman may put in effort for wasm, he's working on an ioq3-based wasm/webgl thingy. Pull requests are welcome ?
  10. What's the exact command you're entering? I would start by checking for warnings/errors in the server console when loading a map. That will probably tell you exactly why. Then remove all mods and reintroduce them one by one until the issue occurs again. It may be a corrupt mod or simply a size limit.
  11. Raz0r

    ModWooty

  12. The QALIGN there is to do with https://en.wikipedia.org/wiki/Data_structure_alignment so increasing that won't help. You need to increase the value of SHADER_MAX_INDEXES / SHADER_MAX_VERTEXES / NUM_TEX_COORDS
  13. More likely you'll cause the game to crash or render weird things. That error is a precaution, because if you index an array out of bounds and write to it you may write to a protected memory page and cause an access violation/segfault, probably the most common type of crash. Let's look at how these indexes are stored: struct shaderCommands_s { glIndex_t indexes[SHADER_MAX_INDEXES] QALIGN(16); vec4_t xyz[SHADER_MAX_VERTEXES] QALIGN(16); vec4_t normal[SHADER_MAX_VERTEXES] QALIGN(16); vec2_t texCoords[SHADER_MAX_VERTEXES][NUM_TEX_COORDS] QALIGN(16); // ... }You haven't actually raised the limit on how many indices, vertices, normals or UV coords a model can use, you've just stopped it alerting you when you load a model that's too big to fit in the pre-allocated memory. So if you do manage to load that model and it has too many indices for basejk, you'll start overwriting the positions of your vertices (because that's the next item in the struct). You probably won't get a crash in this case but your models will get royally fucked up. Note there is no "error" or bug or issue here, everything is working 100% as intended. There is only a certain amount of memory allocated for loading models. It errors out instead of loading/rendering corrupted data. A better solution would be to increase the amount of memory allocated (e.g. by increasing that define) or rewrite how models are loaded entirely (e.g. sparse/lazy allocation instead of pre-allocated chunks).
×
×
  • Create New...