eezstreet

My C/C++ tutorial is complete and it explains a lot of the syntax. I didn't get around to writing a guide on a bunch of the functions like Com_Printf or anything like that but if that's also needed I will work on that.

I've been pondering over writing a different type of coding tutorial, one that doesn't involve "how to do X" but instead explains some of the better points of programming for the game, not a how-to tutorial. I've already got a tutorial in the works that explains C/C++ on the context of JKA programming. Instead of throwing the book at people (literally) this one is more specialized and shows more by doing than by explaining. My question is, what needs explaining exactly? I want to hear input from other programmers and people who would benefit from the tutorials. tl;dr #1: I'm writing some coding tutorials that aren't how-to or copy/paste guides and need some input. Already writing one about C++. tl;dr #2: no, I'm not writing an SP version of X tutorial or "how to do Y". Too specialized and existing tutorials cover most of the subject matter anyway.

I think everyone else has said all that needs to be said.

JA++ is an MP mod. The crash alluded to in the OP is from the singleplayer. The problems shouldn't be related.

It's because you aren't updating the video card drivers. Windows Key + R, type "dxdiag.exe" and give us some specs.

The contrast is too high. Other than that, looks fine.

This sounds like something good for an article. Wink Wink, Nudge Nudge @@SiLink

This thread is inspiring because you took criticism and actually learned how to model. Most people don't do that. Hats off to you.

I don't know. Why don't you compile it and find out?

Yes but there's still anims in the _humanoid.gla which are almost never seen. Alora's flips come to mind.

Are you getting an issue when using JAMP? Does OpenJK work fine without MB2? It might be an issue on their end.

Did you update your drivers?

To maximize memory conservation you'd need to have a setup basically identical to what @@DT85 suggests. A set of base animations which is used by every model (weapon stances, running, jumping) with several animation "packs" like lightsabers, acrobatics, force, and probably several ones which are incredibly specific to cutscenes. JKA and JK2 are pretty wasteful when it comes to animation use here because their _humanoid.gla contains every animation that's ever seen in the game ever, even if it's just briefly seen in a cutscene. On the console ports they had to effectively cut the RAM usage in half (since XBOX has only 64MB RAM and the PC version requires 128MB minimum) and one way they did this was to eliminate these animations entirely in favor of pre-rendered cutscenes which were recorded on the PC version onto BINK videos, among other things.

weapons.dat can't be edited to do this, just to clarify. He's saying you need to edit the code involved with weapons.dat. Add a new fire function that does kicking. This should be easy-ish for a beginner, provided you want to take the time.

Because in my opinion the original GLA doesn't belong there. It's not a model of a player, it's an animation of a player.

Why keep animations in a models/ directory?

No. The issue is because of a too complex model. MP uses twice as large of a transform stack as SP, so if a model works in MP, it isn't necessarily working in SP. Use OpenJK. This issue is fixed there.

You will have to generate visemes for the Raven skeleton, otherwise the process is the same. The skeleton alteration isn't strictly speaking necessary to have the new lip sync system, but it sure does make it a lot less ugly.

I'm not sure. I can't even remember what the format is supposed to be. Which data are we talking about here, the viseme data or the spoken data?

This guy gets it. If the field isn't specified in the worldspawn, it could revert to the default color. No need for two versions. Or this behavior could be cvared.

I think my idea and Xycaleth's are the best. What you're asking for here is really impossible.

It draws a colored rectangle if your view is underwater. That's basically the extent of what it knows. All shader parsing is handled on the renderer. cgame can't sample textures. Brushes on cgame don't even have shader handles attached to them. What you're asking for as a solution is basically utterly impossible without restructuring the engine in ways that would break backwards mod compatibility. I have an alternative idea. Add a new field to the worldspawn which controls global water fog color. It wouldn't be good if there's multiple different colors of water, but very few maps would take issue with this.

How would you propose the cgame code be able to determine that? The cgame has no concept of what renderer is currently loaded. The best you could do is check the cl_renderer cvar and compare the string value, but that's yet another hardcoded check that's really ugly.

Locked because OP is using warez. We don't condone illegal activity here.

You have been issued a warning for multiaccounting. The tells are obvious. Thread locked. EDIT: And you're now suspended for harassing an administrator through private message.