I'm thinking too about how to declare the particular monster to spawn a player as. I'm not sure you can nail it down the way coop is written. I would bet that playerspawns could be modded to lock in a particular monster but the problem becomes playerstarts are random. If you have more than one monster type, you cant really choose. You just gotta take a shot.

This has gotten me intrigued. I'm going to sleep on it tonight. Post your ideas to some other boards. Maybe I could get some help in figuring it out or confirmation of it's possibility.

The thing is though the "monster spawns" need to be pretty much random, where ever the monster is the player needs to be able to assume control of it once the monster they are playing with dies. Since that particular monster wont "respawn" they'll have to just teleport to another monster that is always spawned.

I see how you mean but to my knowledge level it isnt possible. You can't swap controllers like that. In it's reverse the players are protected by the player starts being unable to spawn monsters.

I apologize for not being able to explain things better. I'm sometimes not really good at getting my ideas across. Let me try this...

Everything in the game is cosidered an "actor". The walls, the water volume, the players, the monsters, even the spawnpoints and triggers for activating stuff. Each actor is assigned to a controller that, well obviously controls it. If you choose to change the actor as the game goes on, like killing the monster or destroying the wall, the playercontroller must be destroyed to so that the state may change. This change in playercontroller triggers whats called a broadcast handler and you get the death messages, among other things.

Now certain rules govern controllers. One being they can enter the game only in specified points. Monster classes can only enter in spawnpoints. Players can only enter in playerstarts. Also once a class is declared, you can't change without totally destroying the thing and creating a new one. The rub here is that if you want to switch to a monster, that's OK but you are going to have to "die" as your character (the playercontroller needs destroyed) and be reborn as the monster (a new playercontroller, still human but with that halloween costume on). In order to re-enter the game you must gateway through a spawnpoint as you are still a player, not really a monster, even thought you are on the opposite side.

I can demonstrate this by showing you how many maps have changing monsters without them dying: none. Changing characters? none. This is because once all the stuff is assigned, it stays until removed from the game. It's the way the Unreal engine works.

Now don't confuse this with on the fly server skin changes. That is server controlled and really all it is doing is the server is telling your client "display this". I could make a map where a pupae changes into a warlord when you, say, shoot it once BUT the new warlord would still have all the abilities of the pupae and it would be unable to fly or shoot (warlord abilities). Essentially the class remains a pupae but it is wearing a warlord costume. It will still behave like a pupae no matter what.

Whew..I hope that is better. Guys feel free to post this thread to other boards if you think someone might know better. I'm no expert by any means, just a tinkerer. There may be someone out there who knows a workaround but I have my reservations. Nothing like this exists in any form so I wonder if it's possible given the constraints of the engine.

Thank god, for a second there I thought this was going to be some counter-strike thing.

Well, it is, minus all the crappy graphics gameplay and noobs.

Sounds like a good idea here.

Can you explain this then and what makes it so different from Monster Hunt? I am pretty sure those monsters in Coop aren't "playerstarts" either.



This is how they make you join as a monster on the other team.

Skillz do me a favor and send me the exact version you are playing with. I'm going to decompile it and we can look it through together. I would really like to make this work, so let's leave no stone unturned on it.

Looking through the readme, it references admins adding playerstarts coded to the different monsters. What I think is happening is that when you select a monster it "borrows" the information from the monster spawn, gives you that class, and then spawns you. If the coder found a way to spawn through the monster spawn yet still retain the human playercontroller, I am really excited! There are any number of new possibilities with that, least of which is the ability to actively select different classes in-game. We will know for sure when I get the mod opened up. I think I had a copy but I lost it when I had to roll my computer back this past week.

The copies I have of MCoop and UTMHCoop can be found here:
http://www.planetmonsterhunt.com/mcoop-t261.html

OK I'm going to decompile them and post them back as *{Sourcecode}.zip

I slept in a little this morning but I'll start combing through the uc's tonight. Let's just see what kind of modding we can do with this puppy.

I sent you an MSN message too. There is a forum issue you might need to look at.

EDIT: Here's the sourcecode for UTMCoop=
http://agutgopostal.com/wildman/UTMCoop ... ODE%7d.zip

I'm having problems extracting MCoop. Could someone who knows the mod give me a hand? It's erroring on no set client netspeed in initial values. If you have run this particular mod successfully, let me know and I'd be forever grateful if you would see if yours will extract. I'll show you how, it'll take all of 3 minutes. Skillz I know the zip is good because I can use another program to peek inside the mod and the code is ok, it just won't decompile right. It could also very well be a "poison pill" that is put into the code by the author to prevent decompiling. I'm just not sure.

I'm afraid You'll have little luck trying to get the sources for any version of MCoop.
All versions have their sources stripped out and the author told me a few years ago that the Unreal versions were also encrypted to prevent anyone from reading / extracting the sources.

MCoop is an Unreal mod and thus it'll only work properly under Unreal. So trying to run MCoop 1.x or 2.x under MH isn't going to give much results either. After several requests by me and 3, we were able to get Winged Unicorn to make a version for UT, which happens to be UTMCoop. But due to the differences in replication and other functions between Unreal and UT, the author didn't want to make a fully working MCoop for UT. That's why UTMcoop is basically a "lite" version of the original MCoop.

I'm afraid I've lost contact with Winged Unicorn since those days and I'm not sure if he even has the source files for his old mods stashed somewhere. I'll try digging my mail archives and see what I can find.

Yeah, I thought so. I have a workaround for that but it's manual and would take a while to rebuild the source. I peeked at the classes and what you say makes sense. What I saw didn't "look" right but knowing it was an Unreal mod explains that.

If you get his permission, I'd be happy to manually rebuild the classes and begin work on it. I am pretty uncomfortable working on it now though without his OK since he did go to the trouble of making it purposely hard to extract.