OldUnreal (Engine)

hey guys

i was the guy who was talking about the web-download stuff.. anyhoot i have a question about mcoop2.

when the server starts, u can't just become any monster u want, only those who are in the map.

as admin, there's a command "addstart" which 'summons' a playerstart for the 'missing pawns'. this means everytime the server goes to the next level, i'd have to use the addstart command.

is there a way to allow all pawns at any time in any map, or would i have to use addstart everytime? (i tried autorun command, didnt work for me)

MCoop was coded in a dumb way to be honest here, (No offense to WingedUnicorn of course, this mod was pretty immense for it's time.) the reason why you can't play as monster that are "not in the map" is the lack of pathnodes, really.

Playing as a monster strictly allows only pathnodes as playerstarts, it refuses to use playerstarts or any other navigation point. (Not inventoryspot or teleporters of course...)

The only way is to redo half of Mcoop2's code to fix that. Infact the mod is still, in many ways, really flawed. And it needs a overhaul.

MCoop was coded in a dumb way to be honest here, (No offense to WingedUnicorn of course, this mod was pretty immense for it's time.) the reason why you can't play as monster that are "not in the map" is the lack of pathnodes, really.

So it's dumb now to rely on PathNodes? They are the safest and most reliable locations to consider spawning actors. They are usually numerous when placed in maps and commonly in spacious parts where scripted pawns are clearly supposed to occupy. Maybe considering InventorySpots and Teleporters did not seem reliable or proper in an SP map? Perhaps in DM maps it would not make a difference since the entire map where they may be placed is supposed to be occupied.

The only way is to redo half of Mcoop2's code to fix that. Infact the mod is still, in many ways, really flawed. And it needs a overhaul.

Well, you're very critical of the mod so you seem like a good candidate to update it. WingedUnicorn left it all open-source (minus the DLL). The code base is one of the most managable compared to many other open-source Unreal 1 mods. It's designed in a way so that anyone could make changes with minimal learning time. You'd probably find him happy if you could ask to continue where he left off. Afterall, it's not compatible with the 227 patch because of the DLL anyway.


-Zombie

what's in that DLL anyway?

either way, I had no idea he left it open source, i've only seen closed source versions.

what's in that DLL anyway?

Mainly just to manage some IP logger and getting PreLogin/Login IP-address.

either way, I had no idea he left it open source, i've only seen closed source versions.

http://pvso.net/~hypernl/viewtopic.php?t=6

The release with all sourcecode is supposed to be available, but it seems Hyper's website now only has the stripped release of the MCoop2.u package. :- / Maybe Hyper can find it and put it up for download again. If not, I may have it stored somewhere and can send it to him to put up.


-Zombie

So it's dumb now to rely on PathNodes? They are the safest and most reliable locations to consider spawning actors

It's dumb because, not everyone usually places pathnodes in maps, and the message is misleading half the time, but forum posts at Hyper.NL's forums does make it clear... Most deathmatch maps don't even place pathnodes for some reason, and alot of single player maps rarely use pathnodes sometimes because of inexpierenced mappers or just mappers who don't want a single AI to be used in-game while the map runs. The spawn code should atleast fall back to playerstarts if pathnodes are not findable, maybe even fallback to inventoryspots, but NOT teleporters.

Well, you're very critical of the mod so you seem like a good candidate to update it. WingedUnicorn left it all open-source (minus the DLL). The code base is one of the most managable compared to many other open-source Unreal 1 mods. It's designed in a way so that anyone could make changes with minimal learning time. You'd probably find him happy if you could ask to continue where he left off. Afterall, it's not compatible with the 227 patch because of the DLL anyway.

If the .DLL isn't open source how exactly would I go about changing the mod, unbinding it from the .DLL and making optional support for 227's network security features when I don't know half of what the hell I'm even doing? And also while still maintaining 224v, and 225f compatibility?

Also re-working the entire code would take alot of effort, I'm just a 16 year old kid, I can get easily agitated by erroneous code alot of the time... I may beable to fix alot of things with the spawning issues, security issues, and even the playable pawn issues, but most of that is way complicated for me to understand clearly.

And, I have no real way to contact WingedUnicorn at all, so unless I really had permission from the original author I don't feel it's right for me to really change anything really, even if I did give credit...

I have been given permission by Winged Unicorn to continue the MCoop project ([ch12462][ch12540][ch12464], you may remember that even) and I had plans with it, but I did not get around to it, hence why it was not announced in first place.

The DLL file needs to be removed altogether of course. Also I planned various of other fixes to the gametype, but it's been a long time since I looked into that...

It's dumb because, not everyone usually places pathnodes in maps, and the message is misleading half the time, but forum posts at Hyper.NL's forums does make it clear... Most deathmatch maps don't even place pathnodes for some reason, and alot of single player maps rarely use pathnodes sometimes because of inexpierenced mappers or just mappers who don't want a single AI to be used in-game while the map runs. The spawn code should atleast fall back to playerstarts if pathnodes are not findable, maybe even fallback to inventoryspots, but NOT teleporters.

Then maybe it's not too much to say those maps just are not meant for bot matches, monster coop, or monster mash. If map authors do not go the extra effort to support AI in their map then maybe they don't intend their map to be used that way. I know there are plenty of well-done maps in circulation and I've visited a few servers that have quite a good selection of pathnoded maps.

If the .DLL isn't open source how exactly would I go about changing the mod, unbinding it from the .DLL and making optional support for 227's network security features when I don't know half of what the hell I'm even doing? And also while still maintaining 224v, and 225f compatibility?
...
Also re-working the entire code would take alot of effort, I'm just a 16 year old kid, I can get easily agitated by erroneous code alot of the time... I may beable to fix alot of things with the spawning issues, security issues, and even the playable pawn issues, but most of that is way complicated for me to understand clearly

The provided DLL became obsolete from the options available now. Nevermind that now since you explained updating the mod on your own is too much for you to consider at this moment. When I see somebody who seems to have studied the workings of some mod and becomes agitated by its code usually that person knows just how to 'fix' it.

And, I have no real way to contact WingedUnicorn at all, so unless I really had permission from the original author I don't feel it's right for me to really change anything really, even if I did give credit...

Leo(T.C.K) appearently has permission. If Leo does not mind, team up with him by submitting what you can fix/change/improve.


-Zombie

Yeah WU said before (it was in 2007 when he gave me the permission, but also he wanted to check things before I release the new version, for security etc reasons) that I could even form a small team or something to do that...

Then maybe it's not too much to say those maps just are not meant for bot matches, monster coop, or monster mash. If map authors do not go the extra effort to support AI in their map then maybe they don't intend their map to be used that way. I know there are plenty of well-done maps in circulation and I've visited a few servers that have quite a good selection of pathnoded maps.

You don't really get my point, if the entire monsterplayer spawn system relies on pathnodes alone, in order to support maps in which either pathnodes are broken for whatever reason, or are absent, the ONLY WAY to solve this, is to use playerstarts or some other navigation point OTHER than teleporters, as a backup playerstart for the monster playerpawns. That's the only way I see how to fix this so that anyone can play as a monster in MCoop2 on any map available for Unreal 1.

There's no other way to fix this unless somebody has a dynamic pathing system in a 227 server going on.

well you could make an extremely lame auto-finding system that would completely eat resources with a bunt of traces trying to find open spaces, or have a way for an admin to specify a "huge" starting spot that saves to an .ini so an admin doesnt always have to be there on a map

You don't really get my point, if the entire monsterplayer spawn system relies on pathnodes alone, in order to support maps in which either pathnodes are broken for whatever reason, or are absent, the ONLY WAY to solve this, is to use playerstarts or some other navigation point OTHER than teleporters, as a backup playerstart for the monster playerpawns. That's the only way I see how to fix this so that anyone can play as a monster in MCoop2 on any map available for Unreal 1.

I understand your point, and it conflicts with my point. Certainly, some of us want something to always work no matter what circumstances.

There are definitely ways around many problems, and it depends on how much one is willing to accept ever more unconventional methods.

Personally, if I wanted to support node lacking maps I may consider writing a mutator that saves summoned mcoop2.monsterstart locations for various pawn classes somewhat like Casey said. I could probably even make the gameplay more interesting in that method by creating scenarios. The drawback of course is having to do an initial setup of each node lacking map for replay.


-Zombie

Personally, if I wanted to support node lacking maps I may consider writing a mutator that saves summoned mcoop2.monsterstart locations for various pawn classes somewhat like Casey said. I could probably even make the gameplay more interesting in that method by creating scenarios. The drawback of course is having to do an initial setup of each node lacking map for replay.

What you just said makes me think of how you get bots to work in Tribes 1 and Tribes 2, and various other games, include some simple  table information to be restored when a specific map is loaded, that is something I could cope with because that's virtually better than modifying a map and creating mismatch's.. Not a very "unconventional" way seeing it's been done in many other games, and I'm sure that's how your fixes work with DZMapM I'm guessing?

Mod's with .DLL files completely obscure me by the way...

There are non-pathed maps? Wow. I can hardly believe it, because for me, pathing is probably the best part of mapping. Connecting paths and seeing how bots do feels really good, and it's really easy to path maps, even for gametypes such as Trials (UT2004) or BunnyTrack (UT).

for those of u who remember ice lizard; he had a special type of mcoop that was programmed by dots (if i remember correctly). it was a mutator (not gametype) which ran simoltaneously with JCoop5. it was still a beta version from what i remember.. but wouldnt that be much cooler? cuz i mean.. in mcoop everyone usually plays along-side each other... unlike the intended humans vs monsters (cuz the humans had good guns, monsters just a lot of health)

There are non-pathed maps? Wow.

most maps are partially pathed, or pathed incorrectly in single player {NaliC is a good one, movers dont have liftcenter/liftexits and its not fully connected.}, i've been working on repathing maps to release in a huge package pretty slowly, but the main problem is that I want to ship bots with them so in the future if new players come around they can have help killing everything in mods, and of course this means constant AI tweaking. I have a decent beta working though for them though

for those of u who remember ice lizard; he had a special type of mcoop that was programmed by dots (if i remember correctly). it was a mutator (not gametype) which ran simoltaneously with JCoop5. it was still a beta version from what i remember.. but wouldnt that be much cooler? cuz i mean.. in mcoop everyone usually plays along-side each other... unlike the intended humans vs monsters (cuz the humans had good guns, monsters just a lot of health)

That was a sub gametype not a mutator if I recall correctly...

There's a thing that always bugged me: how do you make jumpoff spots?

In UE2, you use the "Force Paths" property. In UE1, you have to use movers or other hacks

What the hell is "Forced Paths"...?

You tell the Pathnode that if the bot is taking the path, it can safely walk to the "forced" node. Those paths work exactly like white paths (best; in UE1 they're green I guess).

I added the MCoop2 versions with sources included (The non-stripped .u files) to my downloads. The sources are in the .u files, there are no separate .uc files.

http://www.hypercoop.tk/indexd.htm

You can code a pathnode to tell a bot to move towards a jumper, and in that jump have code to only activate if that bot is going towards that {via movetarget} and it works fine :p You could also use liftcenter/exits to make them believe its a good path

Meh, I don't even understand how does AutoMag work.