-
Posts
1,458 -
Joined
-
Last visited
Content Type
Profiles
News Articles
Tutorials
Forums
Downloads
Everything posted by Xycaleth
-
This usually happens when you have too many particles from efx on-screen. I think you can increase r_maxpolys to something bigger (don't go wild, just increase it until the warning goes away) to fix the problem.
-
No, neither cgamex86.dll, jampgamex86.dll nor uix86.dll should ever be in GameData. Ever. I downloaded MB2 just now to test things out and it works fine for me. Can you check that you have the GameData/MBII/MBII.pk3 file? In there should be cgamex86.dll, jampgamex86.dll and uix86.dll.
-
I think I've identified the problem then. OpenJK (and jamp) used to incorrectly load game DLLs from the GameData/ folder as the first place to look. This would override all mod/base folder DLLs. I fixed this problem a few months ago, but it seems like MB2 hasn't been updated to include my fix. I think the question then is how those DLLs ended up in your GameData folder
-
The client mismatch error comes from the incorrect cgamex86.dll file being loaded, so deleting any config files won't help here. When you say mentioned the "GameData folder", were you actually referring to "GameData/base"? That's what it sounds like from your response here. Okay, that's fine. @@Tx606 mentioned that the launcher actually chooses not to use the My Games folder which is something I hadn't realised. So no problems here. This doesn't make sense to me. OpenJK will load DLLs from the mod folder first, and only if it can't find the DLLs there, it will load the DLLs from the base/ folder. If you look in the console, you should see that some cgame DLLs failed to load (after connecting to a server). Can you post that list here please? Don't take this the wrong way, but if you can't be bothered to sign up to the MBII forums, why do you expect them to sign up here?
-
Just to add to this further, I don't believe any of the active MB2 devs regularly visit these forums. So anyone here (I guess with the exception of Tx606) is basically waving our arms grasping for anything that might be wrong.
-
Neither of those DLLs should be in the GameData folder, unless you're referring to GameData/MBII. What folders do you see in the My Games/OpenJK/ folder? If you're running MBII then I would expect to see an MBII folder in there. This has nothing to do with the mod, this folder is created by OpenJK and the mod has no control over whether or not it gets created. On the flip side, what folders do you see in your GameData/ folder? I'd also expect to see an MBII folder in here, containing all of the mod files.
-
Which DLL?
-
Yep, should be available from next build (Monday evening). Your save games should work too
-
I've not actually managed to test what happens if rend2 doesn't load properly so this might be it. What graphics card do you have and are the drivers for it up to date? Rend2 requires a minimum of opengl 3.2 support
-
This should be fixed now
-
That's a pretty trivial change to make if I ever get around to adding MD3 support But thanks for pointing that out!
-
Could you post a screenshot of the problem?
-
I'm pretty sure the OpenJK packaged with MB2 is just the same as regular OpenJK, with a few changes for their master server.
-
The big killer in the lighting stage is -bounce. This attempts to simulate how lights reflects off of surfaces and illuminates nearby objects and I think will take the majority of the compile time.
-
Did you paste the right files? They're both the same!
-
HI Pierry. Sorry to hear you're having problems with OpenJK. Just to be clear, you're getting poor performance when using an AMD graphics chip and Intel runs okay but dynamic glow is wrong. Does that sound right? We can try a few things. When you've loaded up OpenJK with your AMD chip, can you run "/condump logfile.txt" in the console? It will write a file called logfile.txt in My Games/OpenJK/MBII/. Do the same when loading using your Intel chip (change logfile.txt to logfile2.txt) and then paste both files here That should give me a bit more information about what could be causing your problems.
-
Aw, I forgot about this again Too many projects going on! But I'm glad you could make good use of it, @@Cerez
-
I think I can have a look at some point this week Can you upload a save file starting at a point before the crash would happen? It just saves me having to play through everything and means I can be sure I'm setup the same way as you to make a crash happen!
-
So this really highlights the importance of using texture compression. In the screenshot in my previous post, texture compression wasn't enabled. Here's a new screenshot with texture compression enabled. You can see that we get roughly 70% savings in texture memory usage And don't forget that all the models have to be stored as well and they use quite a bit of memory too!
-
So this was slightly unexpected:
-
cgame doesn't have access to this information. As soon as you bring cgame into the mix then rend2 has to start relying on a specific behaviour set by cgame and it's not going to be something I'm going to consider at all.
-
Rend2 doesn't know which square is for water, or if there even is a square for the water (like I mentioned in a previous post, a mod's cgame might do something different). You can guess which blue square it might be, but you might get it wrong, and end up ruining some mod's effect, and won't even work if cgame isn't rendering a blue square but a blue watery texture instead. Modifying cgame itself doesn't break compatibility. Compatibility is broken with existing mods because rend2 now relies on that cgame change. If you load up JA+ in rend2, you will get the blue square (which you can't get rid of) as well as rend2's water effects. EDIT: I think the best we could do is to add the fog effect in rend2 (without any colour), and let cgame tint everything blue. Still won't be great, but it would be better.
-
Right. From what I can tell, there's no way of doing it reliably. OpenJK mods still need to maintain backwards compatibility with jamp.exe, and existing mods needs to be compatible with the OpenJK engine, so changing cgame is a no go.
-
Not quite. The renderer has no context as to what the blue square is for. It could be for something other than water. Other mods may even try to draw something else instead of the blue square to make the water look better.
-
Ignoring cgame's rectangle, yes, rend2 would have to handle this if it were to be done correctly. EDIT: But this won't work with existing mods that have their own cgame. That's who we are catering for here. Existing mods.