[Merlijn]

MetHy, on 24 March 2014 - 01:40 PM, said:

I'm sad to hear that but I understand. How much exactly have you built? Are you really sure you won't have time to put anything together at all? There are still quite a few weeks left.
If you're really sure you won't be able to make it, can you send what you've done so far anyway or is it not worth it ?

You know what, I'm going to give it another shot tonight. Who knows, it might become something contructive (probably not a coctail bar, I tried that and it just didn't work).
If I don't make it, don't delay the project just for me though.

[MetHy]

Paul B, on 24 March 2014 - 07:51 PM, said:

I'm also curious to know why it really matters having Co-op Dukes start with a pistol in hand? Does it make that much of a difference to the levels? I can see the reasoning behind single player but for Co-op it shouldn't be much of a show stopper should it?

The problem isn't that they start with a pistol. The problem is that, as long as one doesn't die, he will keep all of his weapons and ammo from the previous levels WHILE the first player will always lose everything. You can imagine how terrible that becomes with more than 10 maps, the first player will constantly be lower on everything while the others will be running arsenals. If we do it for the first player, we have to do it for everybody.

Also, it might even create game breaking moments like in your map, where the coop players will be able to use the shrinker at the start of the map without even having to find it in the secret.

I didn't think of telefraggring though. Does telefraggring really works in coop even when being able to arm your coop partners is disabled?
But I'm sure we'll come up with something.

Edit : glad to see palette behaviour is back to normal! I didn't notice there was a new eduke32 (i thought the program was supposed to warn you when there is a new one), so I won't have to put eduke32 with the episode

[MetHy]

About the telefragging, what if we make every teleporting point around the elevator/staircase (where the players get automatically teleported after spawning) a small sector? Like this, each player will be in a different sector and it should avoid the issue.
There is no way we can make hurt floor for 8 players due to how the corridor is but we could definitly make 7 small sectors.

Btw - earlier I said I would do it 4 players only; but I was thinking, isn't the spawn point a random one out of the 8 ones when a player dies? Does that mean that, we HAVE to make 8 spawn points because the game is programmed to make the player spawn in any of the spawn point out of the 8? So we can't actually limit the number of players; or can we really make only 4 spawn points and the game will do according to those 4 and not glitch due to looking for the 4 missing ones ?

[Dukebot]

Hi guys, I would like to join in this project. I had the idea of doing The butcher's floor. The place where live a serial killer that likes to mutilate his victims. The place will be dark and scary. Do you like the idea?

[Kyanos]

4 co op starts is fine, limits it to 4 players. There is a max limit of 16 aplayer sprites. If you go over it will glitch.

About those automatic updates, I think it adds to a website hit counter or something cause it does not ever update eduke. I don't like it.

[MetHy]

Dukebot, on 25 March 2014 - 03:50 AM, said:

Hi guys, I would like to join in this project. I had the idea of doing The butcher's floor. The place where live a serial killer that likes to mutilate his victims. The place will be dark and scary. Do you like the idea?

You're welcome to join in, but if you do, make sure you have enough time and motivation to build a good map rather quickly. You're coming in 2 months late.

Drek, on 25 March 2014 - 04:12 AM, said:

4 co op starts is fine, limits it to 4 players. There is a max limit of 16 aplayer sprites. If you go over it will glitch.

Good to know, thanks!

[Dukebot]

MetHy, on 25 March 2014 - 04:25 AM, said:

You're welcome to join in, but if you do, make sure you have enough time and motivation to build a good map rather quickly. You're coming in 2 months late.


Good to know, thanks!

Thanks! How many time I have to build my map? I think I can have it in two weeks, is that okey?

[Forge]

You're setting it up so all the players start without weapons to match player 1

now what about things like weapons in the map?

take my hunk of junk; it's geared specifically for one player.
there's only one weapon and a tiny bit of ammo in the first portion of the level, the rest of the players are going to be sitting around with their thumb up their butt because they can't fight or progress.

[MetHy]

That's not how weapons work in coop. The weapon sprite remains and every player can take it once.

I will try to get someone to betatest the episode in coop with me when it's done.

Dukebot, on 25 March 2014 - 05:54 AM, said:

Thanks! How many time I have to build my map? I think I can have it in two weeks, is that okey?

Two weeks is totally okay, you probably have a little more than that

[Paul B]

MetHy, on 25 March 2014 - 01:45 AM, said:

Edit : glad to see palette behaviour is back to normal! I didn't notice there was a new eduke32 (i thought the program was supposed to warn you when there is a new one), so I won't have to put eduke32 with the episode

Yea I don't know what the hell is going on with Eduke, I thought it was suppose to get updated through Windows Updates patch Tuesday! WTF! I also thought Eduke makes sandwiches? I'm still waiting for my sandwich!

[Forge]

MetHy, on 25 March 2014 - 05:56 AM, said:

That's not how weapons work in coop. The weapon sprite remains and every player can take it once.

learn something new every day. mission accomplished, now i can go back to bed

[Paul B]

MetHy, on 25 March 2014 - 03:08 AM, said:

About the telefragging, what if we make every teleporting point around the elevator/staircase (where the players get automatically teleported after spawning) a small sector? Like this, each player will be in a different sector and it should avoid the issue.

Methy, regarless of what we are trying to achieve it still yields the same results. We will need separate sectors for each Duke Co-op Player. So, I've made tiny little sectors around the perimeter of the elevator room for the Co-op Aplayers without the need for teleporting. I have yet to test this, but I'm sure it will work just fine as long as the Aplayer start position is within the child sector of the hurt tile. This will avoid the problems caused by teleporting. Unless you absolutely want all 7 Players in a remote sector and have each player teleport into the level one at a time while trying to avoid tele-fragging and this is far from ideal.

Once I'm done editing my start locations, I'll send you a copy of my map so you can see what I've done. (Not tested yet)

Having said that, if you're still set on teleporting, we could always have a totally separate sector that we could dress up like the inside of the Elevator with all 7 Co-op Duke start Players. Then have each player teleport out one at a time through a one way teleport to where the first player Duke starts. What's your thoughts on that? I'm willing to work with you on this opening sequence, whatever works for everyone else with minimal changes to any one's particular map is probably our best solution.

Just thinking out loud but maybe we could build a teleporter inside the elevator and have a door around it to prevent telefragging. Once a player enters the teleported sector the door closes immediate behind Duke but opens again after duke leaves the destination sector. I think this can be accomplished by double activators and touch plates or by using a two way train.

When I get home tonight, I have some ideas of how we can make this work. Let me play around with some ideas and i'll get back to you.

[MetHy]

Actually I just had a look at the map since we're going for 4 players and not 8, we can totally fit them all in the starting sector (with hurt floor) and without teleporting.

it was only an issue with 8 players, but since it's been confirmed we can stick to 4 aplayers (and that, really, the episode wouldn't be playable with more than 4 people AND i wouldn't see anyone do coop with more than 3 other people even if it was possible anyway), there is no issue at all.

Edit : no problem at all. Should just probably make them all face the door and it's done

Attached thumbnail(s)

• 
• 

[Forge]

you could probably fit 3 more if you use the center sector under the light

[Paul B]

MetHy, on 25 March 2014 - 10:37 AM, said:

Actually I just had a look at the map since we're going for 4 players and not 8, we can totally fit them all in the starting sector (with hurt floor) and without teleporting.

it was only an issue with 8 players, but since it's been confirmed we can stick to 4 aplayers (and that, really, the episode wouldn't be playable with more than 4 people AND i wouldn't see anyone do coop with more than 3 other people even if it was possible anyway), there is no issue at all.

Edit : no problem at all. Should just probably make them all face the door and it's done

Just remember to give your Duke Co-op Aplayer sprites a lowtag of 1. Why does it matter that the Aplayer sprites be pointed at the wall? Has duke been a naughty boy?

[Jblade]

My 2 cents - add all 8 starts, as you just know somebody will probably complain at some point, but just make it explicit that it's not supported and the max intended player cap is 4 players.

[The Commander]

The hurt tile sector shouldn't have to be that big.
It should still work if it was 75% smaller (could be tested on a SP test map) also the APLAYER sprites can be safely positioned 2 sector grids apart instead of 6.

That should allow you to add 8 COOP start points. (Because someone will try to play it with more than 4 players)

[Paul B]

The Commander, on 25 March 2014 - 01:36 PM, said:

That should allow you to add 8 COOP start points. (Because someone will try to play it with more than 4 players)

Don't flatter yourself commander like you have that many friends. =P

[Forge]

The Commander, on 25 March 2014 - 01:36 PM, said:

The hurt tile sector shouldn't have to be that big.
It should still work if it was 75% smaller (could be tested on a SP test map) also the APLAYER sprites can be safely positioned 2 sector grids apart instead of 6.

i don't know enough about it, but it should only have to be big enough to cover the start position arrow?

if you could reduce the hurt sector from 4x4 to 3x3 then you could squeeze in all eight positions

edit: i guess so. i actually reduced the start block from 4x4 to 2x2 and centered the player start position. worked fine for starting with no weapons - for single player.

if you can test to see if 2x2 works on co-op multiplayer, then you can easily fit 8 start positions in that room

[Paul B]

Forge, on 25 March 2014 - 07:15 PM, said:

i don't know enough about it, but it should only have to be big enough to cover the start position arrow?

if you could reduce the hurt sector from 4x4 to 3x3 then you could squeeze in all eight positions

edit: i guess so. i actually reduced the start block from 4x4 to 2x2 and centered the player start position. worked fine for starting with no weapons - for single player.

if you can test to see if 2x2 works on co-op multiplayer, then you can easily fit 8 start positions in that room

Oops! I've made a mistake. On the smallest grid size 8x8 is how i've placed my Aplayer sprites and I've included all 7 Aplayer starting positions in my map in the same small area. But having that many players in such a small map would be a bit too close for comfort. My map has some really tight areas as it is and doesn't cater well to that many players as I tried to make everything to scale, its a pretty tight little map but all Dukes are present never the less.

Okay so i've spent countless hours and many late nights working away on this map project. I need to catch up on much needed sleep now. I'll be stepping away from mapping and checking back once in a blue moon. I've provided Methy with my final version of the map. Happy mapping and Good luck to everyone whose still slaving away.

My buddy and I are looking forward to playing through the entire Episode Cooperatively... When it's Done!

[MetHy]

I'm sorry but there is a huge difference between "someone WILL complain" and willing to make his map playable for 8 players.

What I mean is, does anyone REALLY think it's a good idea to play his map with more than 4 players?

I'm not shitting on my floor only because otherwise some retard complains it's not shitty enough. Put 8 Aplayers in your map if you want, but I won't. The only reason I said in the rules to put 8 aplayers for coop was because i thought it was mandatory to have those 8 aplayers even just for 2 players coop. I mean, considering the size of the maps and the rooms, EVEN 4 players is too much.

Plus, I actually, I don't believe anyone is going to complain about that or even try coop with more than 4 players. The only two retarded complains I know we could get are that it's not compatible with the HRP and that it wasn't made with dukeplus in mind, and I couldn't care less about that.

[Jblade]

You don't have to make the pack playable with 8 players, I'm just saying I suggest sticking the starts in so that people who try it won't get problems or modify the maps themselves (leading to modified versions floating around) Trying to worry about balance or anything like that in co-op is a pointless exercise anyway because the game doesn't give you any control over what happens beyond simple skill level and 'is it multiplayer' stuff. There's no need to get worked up over it.

[Forge]

whatever. this is dumb.

not everyone made a canned map like i did. You could easily run eight players through Paul's, but more than two players in mine would be stupid.

are you going to paste that start area into everyone's map, or are you going to re-issue a new template and tell everyone to start over?

[MetHy]

Okay fine - I'll manually put 8 aplayers with hurt floor in every map start, unless of course more mappers want to do it themselves because they either think I'm too dumb to do it or that I'm somehow going to break their map, in this case just do it yourself that's always less work for me (even though it really doesn't take long to make).

Ideally I wouldn't make the the hurt floor too small, because the smaller the sprite floor above it will be, the worse it will look on the ground floor (a 512x512 square is the natural look of the ground texture hence why that's how it is, but with 8 players they need to be a bit smaller), but whatever it's your maps after all

Forge, on 26 March 2014 - 03:15 AM, said:

You could easily run eight players through Paul's, but more than two players in mine would be stupid.

You can RUN any map with 8 players. It's just that, 5 players out of the 8 will ultimately only follow the others with nothing to shoot at, nothing to do, and will only serve the purpose of bothering the few players who'd actually get the chance to do something in the map. But anyway, I don't believe ANYONE is going to play this episode 8 players coop in any case, so why not.

[Forge]

well if you're too dumb, then maybe you need more practice at mapping rookie


edit: and don't forget to orient the floor texture with the sprites. the original template is off

double edit: here's a modified template with 8 start points, but it'd probably be just as easy to modify a current one than to copy this one.
the only advantage is i already aligned the sprites and the floor texture

Attached File(s)

•  CBPtemplate_Cage.rar (4.98K)
  Number of downloads: 120

[MetHy]

Has eduke32 got anything more advanced than classic Duke as far as sprites on moving sector are concerned?

I have quite a few sprites on subway sectors in my map. They look perfect in eduke32. I just tested the map both in dos duke3D and in megaton and in both cases, most of the sprites aren't where I put them (inside the vehicule) but instead, are behind or in front of the vehicule and still move while flickering all the time (even flickers during a stop). It's really weird.

Also you'll notice that the "H" of the hotel is misaligned but only in megaton so I take that's a misbehaviour of megaton.

Ultimelately the episode is designed for eduke32 so I'm not too concerned, but if possible i'd stil like everything to look fine on any platform (mainly dos duke...), anybody knwos anything about that?

Here is an example

Eduke32 (how it should be and how I built it)


Dos duke (you can see the driver and the wheel behind the vehicule)


Megaton (actually can't see anything because the screenshto was taken while the sprite was flickering but it's the same as in dos, i psoted this to show the hotel sign)

[Forge]

Sprites will only move with a vehicle if they are within the bounding sector containing the S. Subway Vehicles can only carry 'active' sprites (and of course the 10 intangible special sprites) without causing issues.

ref: infosuite

[MetHy]

I know that (I even built all the cars according to that, the adjacent walls aren't actually connected so that a sprite in the middle can still be in the main sector and therefore move with the car, pic related) and it has nothing to do with the issue thank you, if that was the problem the sprites wouldn't move at all instead of moving with the vehicule but meters away from it while flickering. I'm assuming this might be a 'normal' duke3D (mis)behaviour and that eduke32 somehow fixed it.

I just wish there was actually a list of things eduke32 fixed and added so I can know what I can do or not if I want everything to be compatible with any port and without a port, because i certainly wasn't aware of that sprite problem on subway sectors

Edit : oh okay I get it now. So, eduke32 made it so that ANY sprite (and not just 'active' ones) can be carried by subway sectors without issue and I was unaware of that.
So I thought that, according to that infosuite definition i HAD seen and the way things behaved in eduke32, the wheel+driver sprites counted as 'active' ones, which is why i wondered why it acted like that in non-eduke32 duke3D.

So in other words, those stupid sprites render my map (perfectly) playable in eduke32 only. Well, I could get rid of them i guess... but then again the episode is meant for eduke32. it's just a visual glitch in an unreachable area if you play in what's not recommended for the episode though, so i'll probably leave them. Kinda bothers me to know that the map only acts properly in eduke32 though, all my other maps work fine in megaton (and except for Galbadia which breaks the old limit, they all also work fine in dos duke3D).

Attached thumbnail(s)

• 

[Forge]

lose the steering wheel
replace 1356 driver with piratehalf 4516 or teddybear 4400

[MetHy]

Yeah actually i was just thinking about that