Like RTCW Single Player but together ! | Currently there is nobody on 7 available servers. (While there are 3 private servers running)
You are not logged in. Please login or register.
RTCW COOP → Posts by nate
I wrote this now:
Extended version;
http://code.google.com/p/bzzwolfsp/wiki … dedVersion
Simple version;
http://code.google.com/p/bzzwolfsp/wiki … rverSimple
It's not a full blown hold you by your hands guide, but it should cover enough to get you rolling with some effort from your side.
You don't need to do anything for the moment as I can hardcode markers for local testing..)
Emphasising on local. 
It's less work to add new stuff then deal with potential bugs it would cause when modifying existing stuff and yeah, it's simple to add markers but you have to be spec if using /where command as otherwise it gives wrong coordinates. One thing to note is that there probably wont go over occupying 20 or so slots..as there are game limits etc.
But yeah, I'll see if I can squeeze this in my schedule this week and sort it out. FYI: You don't need to do anything for the moment as I can hardcode markers for local testing and all depends when I'll have time.
There's not much difference between both methods, yours is just more sane since it leaves less space for errors on the end user. But you're right, instead of passing coordinates, mapper could sort those places and simply pass list of those markers.
In fact, that stuff could reside in an a separate script for which would then server on map load time simply check if it's there and if it is, grab the stuff and randomize and populate values. That would mean mapper would control it all so any error could only be done on that side and easily fixed by deleting marker from the script by owner so that value would never be populated - solves the longevity support as end users aren't depended of mappers if/when they wont be around.
Additionally this method would give owner a chance to run default game (by removing the script) or a randomized one etc.
EDIT: Nah, ignore default locations..those should be reserved for persistent ai's..ones that are by default expected to be there..albeit nothing is stopping you to add a marker near it..and for the record - 1 marker would = 1 spawn. Function would count the sum of all markers and then take half (rounded up) or third of them that would be used to spawn AI's in..that could easily be skill depended so at lower skills it spawns less random players then at high where etc 60% of available markers would be occupied (in use)..naturally needs some more math but just to give an idea.
It's clear what's your idea, it's how in theory it could be implemented that's bit of a challenge. 
The way I imagine is that mapper would export list of available entities (soldiers) and list of available zones. Owner would then etc select few zones and pass entities and zones to the game by etc config, game would grab both of that lists and then randomly put X amount of entities (soldiers) at available random spots.
That way mapper would have full control over which entities (ai wise) should be left intact since they're wired to a trigger/action and simply add more ai's that aren't tied to any special function and aren't trigger depended to any action..they're just random AI's that spawn at one of available locations that was randomly selected from list of (available) parsed zones and injected at load time as virtually created game script that's just additional layer on top of existing script etc.
So basically full control and map options are what mapper decides and owner only works with list of available options that mapper pre-set and are allowed to be randomized so in that way, owner nor game can't mess with base line of how mapper envisioned the game flow.
That's the simplest, fastest and most elegant solution (at least in theory) I can think of currently. In practice it would probably mean that location would be passed as vectors (YXZ + angle) so that would mean that maps without a source would be painful to sort as one would have to go in game and establish 4 vectors by using /where command as spectator to form a square from vectors which would then be passed to a game as location and random value of X ai's would spawn in it. For maps with source it's easier since you can get vectors directly from map editor etc.
The only real work if even, is to find a way how to parse all available guarding points- that would probably fall on a mapper.. Rest is just in g_InitGame (map load) by parsing all available guarding points for that map, randomizing them (rand()) and then intercepting those new spawns at G_CallSpawn function. No rocket science, just some thinking and then tweaking it..
That would additionally mean that until map is (re)loaded guarding points stay the same..which means that, if a typical map_restart is introduced later on rather then map load (on failed mission) guarding points would stay the same till different map or new map is reloaded..so in that case, regulars would quite quickly figure out that if they fail to finish the map they'll have it somewhat easier the next try as they know where they should expect AI patrolling..so it's a "little" helper if going gets too though etc.
I'll have time all day today so if you wish add me on skype- nate.afk@gmail.com and we can try and address this over team viewer.
TL-SF1008D is a switch not a router, there shouldn't be any port forwarding issues there. You have to open the ports on your router if you have any.
In case if your switch actually has port settings which is rare for low level switches then simply go into port forwarding and set Port 27960 and UDP to allow/enabled, as well as just to avoid any problems add 27961 so you're sure and that's about it.
Run the server normally and see if it's visible on master list, if it is, you should have more or less stuff set.
I'm not sure if there's dedicated 1 (lan) option (memory holes) but if it is, you can set it as lan server and simply give IP to your friends so server is not visible on master list. Other two options are; Changing master server address as variable is open for writing but I wouldn't recommend it and one I would recommend is passworded server - in that case server is visible on master list but no one without a password can join.
Again if my memory serves me right you set password with g_needpass 1 and g_password "password".
Parsing needs to be replaced/modified as line breaks always by default clears out any colors. It's doable.
Are you binding custom port?
Actually, how are you starting it? - with batch?
If so, post the command line arguments.
Try alt-tab'ing the window to make sure it's in foreground.
I can compile everything else just fine. io Mp, wolfx etc.. only SP/coop causes issues. I'll take a look into what packages I have set in cygwin when I'll tackle that box and report back.
SP and COOP do not work the same. Coop is a modification that's somewhere between SP and MP, as such there are things that work the same and than there are things that work completely different.
I'll update it and report back. I was testing a while ago so ain't even sure which revision was it.
Edit:: Stil broken;
Error: Must define or find WINDRES, CC, and CXX
Win7/cygwin & Linux
On linux make works fine but cross compile returns same problem.
Nope. It's completely optional since it's an ugly fast fix. For SVN it should be done properly - by adding GSKILL_CUSTOM so UI can tie too it and reports back custom difficulty servers in server browser etc.
It's not hard to do a proper version, just needs little more work but I was low on time. Maybe in following days I can wrap up a proper one and commit it. Albeit due io migration there's no VS solution and cross compile was broken (when I was testing it) so would, may need to solve that first.
Now looking back, cutscenes could be solved with a new state- that would solve AI actions as well as other problems since most of actions are tied to specific states/events.
Nah, just a thought no plans.
That only means you successfully pinged master server.
In order to run a server you need to allow Incoming and Outgoing connections.
- Incoming = players that connect to your server
- Outgoing = your server communicating with players
If you have incoming port blocked you will be able to ping the master server but any player that will try to connect to your server will not be able to enter because your router or firewall will ignore Incoming (their) connection.
If you have outgoing port blocked your server wont ever reach the internet because any attempt your server (game) to connect master server and advertise your game server will be blocked by router or firewall.
----------
You need to open the following UDP port on router for incoming and outgoing: 27960
The same applies for firewall. Add (allow) rule for UDP port 27960 in incoming (inbound) and outgoing (outbound) section.
Additionally: Game assigns port automatically by starting with 27960 and each new instance of the game adds 1 on top of the last instance used. Meaning that if you run your game to play you will get 27960 port assigned. If you run another instance of the game, that game will auto assign port 27961 (27960 + 1) and 3rd instance will assign 27962 (27961 + 1) etc..so make sure that you first run the server otherwise server will listen on port 27961 and wont work because you unblocked port 27960.
For router settings: DMZ sometimes work and sometimes doesn't. Cheap routers produce "cheap" problems. In port forwarding section of your router open UDP for incoming and outgoing for local IP and port 27960.
----------
This is a complete explanation. All that's left now is for you (if you don't know how) to google how to add rules to your router (depends of the model) and/or google how to add rules to firewall.
If this is to hard for you, then I guess you should stop trying to run a server because it's simply to much for you and rather play on servers that are already up.
LEFT : KNIFE with Skin
RIGHT : MP40 with Skin
http://s6.postimg.org/jgbl6mxg1/RTCW_COOP_Skin_BUG.jpg
Knife is not a bug, it's your problem. Don't use custom skins and there wont be any skin issues.
COOP was made for defaut skins and so far afaik they work. No one is preventing you to use or even make your own skinks but if they don't work it's not COOP's issue, it's skin pack issue or to put it plainly, your issue and not a COOP bug.
So unless if you're using default packs there's no point reporting it here, otherwise by all means feel free.
Knife is not a bug, it's your problem. Don't use custom skins and there wont be any skin issues.
And please stop shouting, we're not deaf here the last time I checked.
Whatever works for you is fine.
If you can compile it, I can add a cvar for gameskill so ones that wish can run a customized difficulty - assuming fretn is fine with it?
Although custom skill would require full patch all around, a fast hack to offer change can be introduced for time being in repository so anyone that wishes can compile it, till the next release where naturally it should be patched on all ends to correspond in menu etc..
----------------
EDIT:
Here's a nasty patch for anyone that wishes to use it. Just apply it and compile your bin and you should be good to go (didn't test it but should work).
----------------
New options are:
g_customSkill | 1 = enable it, 0 = will use default game skill set (easy, hard..)
g_customSkillAim | Value between .1 and 1.0 for AI aim level
g_customSkillAtt | Value between .1 and 1.0 for AI aggression level (attack)
Grab the source, unlock the cvar and recompile it. It's a few min process.
And how to open PORTS 27960 UDP and TCP on your router/firewall ?
I only know where to block APPS for FIREWALL .
Depends which router you have but it's quite straight forward and generic approach in all routers. Go to port forwarding and simply add 27960 both udp and tcp (depends of router you may need to add it twice - once udp and once tcp or if it's supported only once with "both" option).
Check manual of your router or google it. Don't bother posting your router model and stuff as no one will do it for you as it's easy and requires few minutes of your life.
RTCW COOP → Posts by nate
