Jump to content

ensiform

Members
  • Posts

    1,626
  • Joined

  • Last visited

Everything posted by ensiform

  1. They aren't going to be consulted for EA's works at all.
  2. This is comparing retail versions of both games to the best of my knowledge. @@Grab can maybe chime in more which versions were verified during testing.
  3. It doesn't need to be in any fit state to be released to go on GitHub. I won't be able to help, I don't have VS because I'm not on Windows. I also wasn't really intending to help, just wanted to see the code get released and then others can help.
  4. You should definitely upload it to GitHub or something. Then you have fewer issues with your source dying from hard drive failure. And can keep track of changes, handle releases, issues etc! https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/#platform-windows
  5. @@MGummelt what did you guys do to the efx system to cause this in JKA over JK2: https://github.com/JACoders/OpenJK/issues/908 Nobody has been to be able to notice where it's adding extra primitives when the efx files are identical.
  6. Well OJK is basically slowed to a halt lately so I wouldn't count on much getting backported even if you were able to come up with a solution that could be brought to OJK.
  7. The mac build seems to have been fixed. Hopefully new build will show up on the regularly scheduled time on Monday. Still waiting on getting appveyor to deploy the proper builds for Windows though. Hoping @@Xycaleth can work on that.
  8. mp/ctf3 has quake3 bsp format (IBSP) for some reason? Missed -game ja ? This somehow still loads in jka because the version number is 1 (But causes problems with the lightmap/lightgrid) Console alerts of mismatch. Please fix this so I can fix the plants for you in a follow-up release. mp/ctf2 still contains an info_null that should be an info_notnull. Look for the targetname of t296 and make sure its an info_notnull. info_null is removed immediately so the spectator intermission point points to a null entity. Causing G_PickTarget: target t296 not found In theory we could possibly fix the glass at some point but its going to be very difficult to figure out the surfaces and the internally stored shader instance that must be altered properly. EDIT: I have fixed the bsp format issue and the plants bug on ctf3 locally. Can talk tomorrow on Discord.
  9. But the "_n" is a suffix added on when looking for a normalmap version of "datapad". Assuming you get the same crash with debug, it looks like you have an image object in the dynamic images array that has no name somehow?
  10. Possibly, but your saves are tied to your mod. I never looked at it in depth. You could ask the author of the pull request.
  11. The SP was unfortunately not designed to be as modder friendly as we might have hoped. Even having custom models can break saves or tie saves to those models. @@Dusty, chances are your save code is probably ancient by now. There was some patches recently through a pull request to overhaul the save system (for cross platform compatibility etc) but it may have created some other issues in the process. Access violation doesn't mean you need to allocate more memory. It means you have a location in the code that is trying to access invalid memory. IE: reading a pointer which is null or garbage or going out of bounds reading an array (which is basically the same as a bad access to a pointer since somearray[index] is the same as doing *(somearray + index) I believe? May not need the *
  12. You don't have to inform us that it is the "Shift+Tab" console. That is the only real console in the game. Plus it doesn't require shift in OJK And, pretty sure its actually Shift+` not tab in JASP/JAMP anyway. Depending on your keyboard loadout. Its typically the character key left of the 1.
  13. Have you looked at why/where it hangs with a debugger attached?
  14. The HUD is rendered at virtual coords and you need to scale everything by hand. Pretty sure jaMME and joMME are the only mods that have it available fully. But neither are SP.
  15. Looks nice except it's too dark to be playable in MP. Hopefully that improves near final.
  16. brew install sdl2 ? This is a required step of OJK so that applies as well...
  17. You would still need to use the terminal to open the app package with fs_game I believe. For the time being anyway.
  18. Anything's possible with the source code but nobody's actively working on survival/horde modes currently. I know similar have been attempted in the past though.
  19. But it's also a common misconception that the games themselves are perfect untouched. We already have witnessed throughout the years how terribly the code has caused a negative shift in people's viewpoints over saber mechanics simply from recompiling the SDK or full source makes something feel different to some people. The simple fact that it's as flakey as it appears to be makes it hard to make a case as to what the true intentions are/were or if they just shipped calling it good enough.
  20. I don't really see the point in this at all. The source engine isn't that much newer I'm comparison or that revolutionary.
  21. Prove to me there are actual radical improvements going into the slow as molasses development into GTK Radiant that are actually helping bring people to older tech3. Most people today do not build with BSP hence they won't use it anyway.
×
×
  • Create New...