Hyper.nl Unreal Services

swagman · Joined: 17 Jan 2005 Posts: 36

I want to do a modification of hyper's EndMutator so it will work with Jcoop4. 1 problem though.. The Jcoop console commands are NOT serverside like mcoop. Therefore I cannot get the mutator to execute those commands :-( . Is there any way I can get the "End on/off" commands working on the server log and/or mutator?

Hyper · Posted: Wed Jan 19, 2005 10:15 am Post subject:

I got the same problem when I tried it in MCoop2 for the first time, the "blockend" command only works in game, but there also is a "_blockend" command that works from the server console. When JCoop does not have this kind of double commands, you'll have to find a piece of code, or exec script to block/unblock the end in another way.

But when you want to do it an easier way, you can also decide to use MCoop2 instead of JCoop4. Nowadays, MCoop2 contains most of the features of JCoop4, plus a large number of features uniquely available in MCoop2.
_________________
Alter your reality...forever.
Hyper.nl Unreal Services
unreal://hypercoop.tk

swagman · Joined: 17 Jan 2005 Posts: 36

That's It!! I'm switching over to mcoop2. I'm just not too sure about people being monsters... I don't want players being monsters all the time, Is there any way I could disable being monsters on mcoop2?

Hyper · Posted: Wed Jan 19, 2005 11:34 am Post subject:

I'm not sure. I think it's not possible to disable monster players, but you should ask Winged Unicorn.

But my experience of my server is that most players like to play as human instead of monster, but that's also because of the other mods I use.
_________________
Alter your reality...forever.
Hyper.nl Unreal Services
unreal://hypercoop.tk

Zombie · Joined: 27 Jan 2004 Posts: 295

It is possible to disable/enable the end teleporter without such functions. You can design a mutator to save the end teleporters to variables and disable them by changing "bEnabled". Then set a timer for whatever time period needed before it then re-enables those teleporters (setting bEnabled True) to be touched. For a JCoop4 sepcific mutator you would want to consider toying with the "bDontEnd" variable from the gametype. Since the normal JCoop4 package is stripped you can change it using a ConsoleCommand("set jcoopgame bdontend True/false");

Anyway, MCoop2 is definitly far superior to JCoop4 in terms of security, logging, commands, and developer friendlyness. On the other hand, I'm currently soon to begin working on a JCoop5f (shocker?

) that will include most of my server's features, fixes, security improvements, and enhancements from my personal gametype add-on. Joss essentially gave me permission to take over finishing the JCoop project months ago through an e-mail ...just that I've held that off for other things.

I plan to shortly start some post threads on some common message boards regarding JCoop feature requests. When I do that you're welcome to invite anybody to come post their ideas and suggestions for a next release.

-Zombie

Hyper · Posted: Wed Jan 19, 2005 11:11 pm Post subject:

Quite nice that JCoop5 will finally see the daylight. It's always a bad thing when highly anticipated projects end rotting on a harddrive. There are still many JCoop4 users left so there still is a 'market' for JCoop5.
_________________
Alter your reality...forever.
Hyper.nl Unreal Services
unreal://hypercoop.tk

Zombie · Joined: 27 Jan 2004 Posts: 295

JCoop is a much lighter "fixup gametype" with bonus features for coop then anything else. I think the reason why so many server admins opt to continue using JCoop4 is because it's a reletively simple, low-resource, less dazzle mod to use and the package size is about half of MCoop2. Overall it basicaly is supposed to be a 'CoopGame' upgrade rather then including actual new gameplay routes.

I beleive a more modular aproach to a gametype attracts users since then they have options to not use certain extra accessories. MCoop2 for instance might have been more attractive to admins if the added MCoop Pawns were put in a separate package as an option. With JCoop5 I might be able to figure out some special MCoop pawn support if developers extract the classes from MCoop2 as a tag-on package (with Wing's permission of course). Otherwise I could attempt something like what }TCP{Wolf is doing with his own 'MultiMesh' support. In that sense I'm assuming a player only uses one pawn class, but choose other monster meshes like "costumes" to change their appearance/physical strengths.

One of the sad parts about contact with Joss (completey non-existant now) is that I never received the last 'b4' sources which already had most of the script proxied to a serverside portion.

So I have to go through the b3 sourcecode and do that all over myself and then merge my DZ sources to it.

Here is pretty much the last contact Oblivion and I have had with Joss for those wondering:

Hyper · Posted: Thu Jan 20, 2005 10:00 am Post subject:

I probably still have parts of the beta JCoop5 in cache, from the time the beta builds ran on Joss' server. But of course this would only count for the client downloaded part. (When you are interested in these cache files, let me know, and give me a search string when possible.)
_________________
Alter your reality...forever.
Hyper.nl Unreal Services
unreal://hypercoop.tk

Zombie · Joined: 27 Jan 2004 Posts: 295

Thanks for the offer, if I'll need it.

I have the JCoop5 b4 client portion, but I lack the more important server-side source to that build. I've been told that Joss did leave 1-2 admins with a complete 'b4' and a lesser known 'b5' build, but I still need to find out if they have it. If anyone has the complete builds of those please e-mail them to me.

-Zombie

swagman · Joined: 17 Jan 2005 Posts: 36

I have a feature suggestion for Jcoop5: ServerSide commands :-D

swagman · Joined: 17 Jan 2005 Posts: 36

Sorry for the double post but I have been able to make a mod of your end mutator that works with any coop gametype. I call it AFZendmut, It basicly stops players from going near the end teleporter. In the next version I am going to add configurable end on/off messages. Oh.... Wait... I need hosting :-( I am unable to host it at UnrealSanctuary. May I email it to you Hyper?

EDIT: UnrealSanctuary is able to host it, http://us.merchant.on.net/off-site_stuff/AFZendmut.zip

Zombie · Joined: 27 Jan 2004 Posts: 295

Zombie · Joined: 27 Jan 2004 Posts: 295

Ok I just looked at the uscript that you two have and I can see some potential problems. One of them is the use of "ConsoleCommand" functions to do some of the things. The other is the string comparison operations of the map names.

In Swagmans uscript he sets an actor variable to make the teleporter block players (collide to teleporter) using a ConsoleCommand function call. Doing this will not only block the end teleporter, but also any other teleporter that may be in the map that simply re-locates the player. The individual end teleporters should be cyphered out for adjustment (they use an "#" char in their URL, look at script snippets above to see ways).

Now the string comparison operations you guys have use "==". In string comparing that requires both strings to be EXACT down to the case sensitivity. Using "~=" operations will ignore case sensitivity to where you won't need to include every possible name case for comparing. Besides if any admin happened to switch the level manualy and used odd casing like "PaSsAGe" then the end timer would probably fail for that map unless you also included that exact string casing.

-Zombie

Hyper · Posted: Fri Jan 21, 2005 1:30 pm Post subject:

Zombie · Joined: 27 Jan 2004 Posts: 295

I don't think anybody who started at the beginning used it at first. ;) It's only when you start needing to do some more advanced string manipulating that you look into case sensitivity and some convient operations.

Just remember that "~=" will only work if the comparison is both string or float values. When comparing float values the operation only looks at the numbers before the decimal and only three right after it to get a match.

-Zombie