Like RTCW Single Player but together ! | Currently there is nobody on 4 available servers. (While there are 2 private servers running)
You are not logged in. Please login or register.
Schnoog, over on Splatterladder, posted some really interesting news from the guys of the =KT= Clan. They've been playing RTCW since "day one" and they've just released their "Evo Wolf" upgrade for RTCW MP, I'm sure that this will interest Nate, here's the details and screenshots:
Is there any way that these awesome effects could be incorporated in RTCW COOP, Fretn?
is this is possible, MANATARMS offered me the code long time ago, but it hasn't been a priority I wanted to get rtcwcoop stable first.
Maybe its something for next releases
..................but it hasn't been a priority I wanted to get rtcwcoop stable first.
A sensible approach, Fretn. It's always wise to make sure that the foundations are well built first, then you can add to it. =KT= SuperRetardo posted the download link for the latest version here:
http://www.ktclan.com/forums/index.php? … ne-update/
They're very talented guys.
Maybe its something for next releases
That would be epic indeed 
. It never ceases to amaze me, after all these years since RTCW was released, just how many developers still have a real love for this superb game. Eugeny, over on the Volfshantse website, is in the process of making a RTCW HD retexture pack, the screenshots look awesome:
http://volfshantse.netorn.ru/forum/view … amp;t=3043
Long live Return to Castle Wolfenstein 
.
"No more "Too Many Shaders" Error Bug"
If this is same as shader overflow; that eg. when you shoot, random shaders pop up in your screen. Applying this fix for COOP would bring heaven down to earth for Tobruk project. There comes no "error message" with it thought, so I am unaware if this is same. This bug is the most annoying thing in whole SP mapping scene! Took me months to tweak Tobruk1 to get rid of the bug on it, same problem still appears to be fixed in 2 other maps too. 
Fretn, I actually talked to you about this SP bug a LOONG time ago. 
Yes I know, but I never came around to fix this, I even forgot how you can fix this
Shader bug is not really tied to engine, it's tied to maps as some maps produce their own shaders and peak the upper limit.
You can avoid shader bug by making the map correctly as well as link to correct existing asset instead of producing new models, lightning and other stuff via map. Alternatively, shader limit could be upped but as anything, it would come with a price, poorly optimized maps could as result, lag - that is if project still aims to support low end computers.
As for EVO project it self, it doesn't bring nothing to the table I wouldn't already done or ported months ago. wolfX already has bloom, http downloads, an actual guid handling with authentication (ioquake guid can easily be broken so it's unreliable for tracking and global banning).
Also wolfX has it's own mod base, as it's not aiming to be compatible with any version, so I was/am free to do what I want as such, it was expected that I produce an alternative logic since no mod exists for wolfX yet, so most of shrub, osp and alike settings are already in wolfX main mod available by default along with other enhancements, so any modder has a lot of stuff already in and as such, modding is simplified.
Although, wolfX is currently migrating from default engine to iortcw one (ioq3 ported by M4N4T4RMS). I already successfully merged wolfX logic with iortcw engine as well as ported some of engine changes to it and fixed some of the bugs. Although project requires to stray away from iortcw as underlying philosophy is different (I don't care about legacy support since I'm aiming to standalone version in a long run) I am keeping it sync'ed with iortcw. M4N4T4RMS did a great job with porting ioq3 to rtcw, so currently pretty much most of stuff is available - voip, openAL (surround sound support), 3D vision, updated and alternative render, MD5 support (models), linux-32/64bit - mac - windows32/64 bit support and bunch of other stuff. You can check the upcoming release here: http://rtcwx.com/media.html (Upcoming screenshots) etc.
In either case, while EVO may not be useful to me, it's nice to see there's other people working on rtcw as well.
Shader bug is not really tied to engine, it's tied to maps as some maps produce their own shaders and peak the upper limit.
You can avoid shader bug by making the map correctly as well as link to correct existing asset instead of producing new models, lightning and other stuff via map. Alternatively, shader limit could be upped but as anything, it would come with a price, poorly optimized maps could as result, lag - that is if project still aims to support low end computers.
You are right about some aspects, but you are really closing your eyes on something.
First of all, the maps in RTCW have been compiled with Q3MAP. Maps today are compiled with Q3MAP2 created by Ydnar. Q3MAP code handles this issue a lot better than Q3MAP2, however going back to Q3MAP would be a HUGE disadvantage. I would rather go back to ET mapping than go back to Q3MAP. Still improving and optimising is good.
Secondly, yes the problem is tied to maps. More specifically it is the number of unique lightmapped shader combinations. However, this is major pain in the ass. Because if we even want to make a map that compares to something that has been made 11-12 years ago, we must spend HORRIBLY A LOT OF TIME per map on tweaking pretty useless things. You won't really see it much on other than the bug, honestly you will not notice a real difference on FPS. If we don't want to tweak, we must get rid of some parts of the map. Also can you imagine if one (and most probably WILL) want to push it a little further than 11-12 years ago, because we really can do so.
Some stats:
I have mapped for over 6 years, I have spent hundreds and hundreds of hours on just researching ANYTHING about mapping. I always spend most of the project time tweaking things and I work really clean.
2 first maps in Capuzzo were originally one map in ET. I had to divide it into two maps for SP (City and Airport). It took me many months to get rid of the bug. I had to tweak both maps A LOT after divide. All this because of this shader bug. I probably would have totally saved 6 months in the project, that counts in the time I quit with it for this. Capuzzo has been tweaked since 2009, so there is not really anything to get rid or improve anymore.
Tobruk. Originally 1 ET map. Divided into 3 maps for COOP, because of this bug. I battled with the bug in the first map for months, and gave up for a while. Eventually got it fixed on the first map. The second and third part still goes over enourmously with about 100-150 shaders and they even still miss a lot of stuff. Is pretty demotivating to begin with it. So yes, I can get it to work, with months and months of work, or I might get rid of some parts of the maps. But the maps are not big, and I cannot really give up parts of the maps. Yes I could remove even more used textures, but that count is not big either, so it would make the map look boring.
Next big step would be to get AAS compiled. Any map that can compile AAS, WILL perform well enough. So your point about the FPS kinda dissapears. However this is entirely because of BSPC tool that has been last updated 2001 and this has nothing to do with shader issue. AAS also forced me to divide maps and tweak for ages.
Shader bug is not really tied to engine, it's tied to maps as some maps produce their own shaders and peak the upper limit.
You can avoid shader bug by making the map correctly as well as link to correct existing asset instead of producing new models, lightning and other stuff via map. Alternatively, shader limit could be upped but as anything, it would come with a price, poorly optimized maps could as result, lag - that is if project still aims to support low end computers.
You are right about some aspects, but you are really closing your eyes on something.
First of all, the maps in RTCW have been compiled with Q3MAP. Maps today are compiled with Q3MAP2 created by Ydnar. Q3MAP code handles this issue a lot better than Q3MAP2, however going back to Q3MAP would be a HUGE disadvantage. I would rather go back to ET mapping than go back to Q3MAP. Still improving and optimising is good.
Secondly, yes the problem is tied to maps. More specifically it is the number of unique lightmapped shader combinations. However, this is major pain in the ass. Because if we even want to make a map that compares to something that has been made 11-12 years ago, we must spend HORRIBLY A LOT OF TIME per map on tweaking pretty useless things. You won't really see it much on other than the bug, honestly you will not notice a real difference on FPS. If we don't want to tweak, we must get rid of some parts of the map. Also can you imagine if one (and most probably WILL) want to push it a little further than 11-12 years ago, because we really can do so.
Some stats:
I have mapped for over 6 years, I have spent hundreds and hundreds of hours on just researching ANYTHING about mapping. I always spend most of the project time tweaking things and I work really clean.
2 first maps in Capuzzo were originally one map in ET. I had to divide it into two maps for SP (City and Airport). It took me many months to get rid of the bug. I had to tweak both maps A LOT after divide. All this because of this shader bug. I probably would have totally saved 6 months in the project, that counts in the time I quit with it for this. Capuzzo has been tweaked since 2009, so there is not really anything to get rid or improve anymore.
Tobruk. Originally 1 ET map. Divided into 3 maps for COOP, because of this bug. I battled with the bug in the first map for months, and gave up for a while. Eventually got it fixed on the first map. The second and third part still goes over enourmously with about 100-150 shaders and they even still miss a lot of stuff. Is pretty demotivating to begin with it. So yes, I can get it to work, with months and months of work, or I might get rid of some parts of the maps. But the maps are not big, and I cannot really give up parts of the maps. Yes I could remove even more used textures, but that count is not big either, so it would make the map look boring.
Next big step would be to get AAS compiled. Any map that can compile AAS, WILL perform well enough. So your point about the FPS kinda dissapears. However this is entirely because of BSPC tool that has been last updated 2001 and this has nothing to do with shader issue. AAS also forced me to divide maps and tweak for ages.
There's no arguing that rtcw is horribly outdated when it comes to mapping - code wise and tool wise. I wont go into mapping it self as that's really not my area at all so I would give little if any valid input on it.
But while I do agree that shaders are a problem there's also one thing that's overlooked. You're referring to ET style of mapping, ET is not rtcw and as such, you will experience problems with converting any map from it the same way as converting rtcw map to default q3.
I mean don't get me wrong, yes it would make sense to update the code in that area as well and with it, potentially make coop compatible with latest radiant version (1.6 if I recall right?) that's still maintained at some pace and surely less buggy then tools you have to work with now. That would make your job as a mapper 100 times easier and also open the doors for various other things. But to get to that level, it would require much more then just upping the limit for shaders.
I mean in a long run, AAS code will, should need to be updated as well as render probably and maybe new physics integrated, that would surely be a game changer. But in reality all I wanted to say was, that by upping the shader limit to get rid of shader error, problem wont go away as it's tied to much more then just that.
There's no arguing that rtcw is horribly outdated when it comes to mapping - code wise and tool wise. I wont go into mapping it self as that's really not my area at all so I would give little if any valid input on it.
But while I do agree that shaders are a problem there's also one thing that's overlooked. You're referring to ET style of mapping, ET is not rtcw and as such, you will experience problems with converting any map from it the same way as converting rtcw map to default q3.
I am not talking about 1 day converting the map so you can run in it. I'm talking about taking months and months to really converting all the shaders, remaking all the entities and pretty much recreating the map. At that point the only difference is that the map is actually bigger. Once 1 map is divided into 2, there is absolutely no matter if it was made for rtcw or et in the first place. Capuzzo SP project has been more or less actively under work for 3 years now and I created the third map from the scratch for SP. So, give me an example what is the big difference you are talking about...
Also I can tell you, that even tho Ttimo (who originally was making radiant) is working on 1.6.x it does not make any real difference with us. The map file will still turn out the same way, maybe via a little different route. And I don't think Q3MAP2 will ever see any real changes to this, since the problem appears in SP code. The old compiler is just little more trusty on this issue. Any Radiant version compatible with SP is perfectly compatible with COOP, and also IF you compile separately, any "not-compatible" radiant version will work for SP/COOP, if you can remember the entities by heart. Editor and compiler are 2 totally different programs, as you probably know.
I mean in a long run, AAS code will, should need to be updated as well as render probably and maybe new physics integrated, that would surely be a game changer. But in reality all I wanted to say was, that by upping the shader limit to get rid of shader error, problem wont go away as it's tied to much more then just that.
Ofc we could update everything and be heroes. But if we want to be realistic and keep the game easily mapped/ported etc, there is not much to do.
Only real thing in AAS compiler (BSPC) would need to be changed is the max planes limit, which is just changing one number and then fixing the memory crash, which I think is todo with a memory limit or something like that. This was done for some game and/or generally by a random community, but it either did not run or was impossible to find. AAS code is VERY unstable and buggy to compile. How ever this is something that can be worked with!
I have no idea how the shader bug would be fixed. I don't think it is just one line, I am not saying that. Just that is the cause for it. It would be enough to just fix it on the game end, where the bug lies. These things really just affect the custom content, as far as I can tell, shader bug is very rarely happening in the original maps.
The potential for making amazing things with a decent performance is limited by a few singular smallish things. Bugs or outdated limits. Generally the game, engine and tools have much greater possibilities mapping and shaderwise that we are limited to right now.
Ps. Here is some home work about the Shader overflow bug. I hope we atleast talk about the same bug. http://www.katsbits.com/tutorials/idtec … at=15&