[MetHy]

To Davox : Go on then!

[DavoX]

yes But I wonder if people will have to beat 31 maps before reaching mine

[Daedolon]

Just 16.

[MetHy]

Maybe more, i'll be optimistic and make it 20.

[Daedolon]

Not a good idea to cut it into two episodes and have a smaller battle in one of the mid-floors?

[Jblade]

Keeping it as one episode is the best idea, it'd feel more like a single building that way rather than having to go back to the main menu and selecting part two.

[Daedolon]

That is true, dunno how many maps will Megaton support in an episode (does it even support mods?) if people want the finished CBP to be published on Steam.

[Hendricks266]

As much as Megaton provides publicity, modding is not one of Megaton's priorities. Limiting ourselves to what Megaton can provide is not far removed from limiting ourselves to DOS v1.5.

[Lunick]

Daedolon, on 27 January 2014 - 02:13 PM, said:

That is true, dunno how many maps will Megaton support in an episode (does it even support mods?) if people want the finished CBP to be published on Steam.

You can't publish grps though and Megaton doesn't support Midi files which MetHy explained he only wants in this project. Maybe if people wanted to publish their individual maps sure...

But that's not the point, I can't wait to see all the floors created

[Daedolon]

CON files are not GRP files. But that's not the issue here. There's so many mappers on this that I have no clue what our collective preference is.

As for staying on topic, I finished the first version of my car, it's good to go as is. I'll even revise and use it for my own maps afterwards. Now back to finishing this goddamn floor...

[Paul B]

MetHy, on 27 January 2014 - 12:20 PM, said:

I don't get it

Oh I just recall that area in IT Lives that was flooded. It was really cool. Flooded scenes never seem turn out well for me when I try to create them. You need a hyperactive imagination to pull them off and since nobody mentioned a flooded floor which probably could only be in a basement level I thought Gambini would have been a good fit for the task.

[Steambull]

Map on hold because I encountered my nemesis problem: ceiling texture gets aligned differently from what it was after creating red sectors (and only inside those sectors). Why does this happen? It's a mess now...

[Micky C]

Do you have the relativity bit set?

Although now that you mention it I *think* I may have encountered the same problem as you where the relativity bit was not set but making new walls changed the alignment, but I'm not certain, I kinda discovered it afterwards like you.

[Daedolon]

It's been happening to me all throughout making of this level: Cage said he's encountered it too so I think it's an issue with the template. It will work if you just set every new texture (like I've done for 500 or so sectors). Bug reporting time:

@Helixhorned: Creating new child-sectors in this map cause the child sectors' textures (ceiling/floor) to act in a similar fashion to being set to be relative to the firstwall, although this is not true. The textures are not set relative but they never behave like the sectors surrounding them. Important!

[Micky C]

I didnt encounter it in this map, it was somewhere else.

[Steambull]

It started happening only recently on this map, so I must've changed something by accident. I'm sure that someone here knows what causes this, let's see if we can get an answer. It's way too tedious to work with this issue.

[Helixhorned]

Daedolon, on 28 January 2014 - 03:15 AM, said:

@Helixhorned: Creating new child-sectors in this map cause the child sectors' textures (ceiling/floor) to act in a similar fashion to being set to be relative to the firstwall, although this is not true. The textures are not set relative but they never behave like the sectors surrounding them. Important!

Instructions to reproduce, please. Specifically, what's the supposedly "bad" sector's index? I tried the large outer one, and splitting it did not result in the relativity bit on the ceiling being set when it wasn't before.

[Daedolon]

Helixhorned, on 28 January 2014 - 04:43 AM, said:

Instructions to reproduce, please. Specifically, what's the supposedly "bad" sector's index? I tried the large outer one, and splitting it did not result in the relativity bit on the ceiling being set when it wasn't before.

I copied the broken texture from my map onto a sector and created a child sector inside it. I didn't do anything else. Check the file and see for yourself:
 templatebroken.zip (5.98K)
Number of downloads: 180

[Helixhorned]

OK, so the two ceilings in question have different panning. Panning values are saved and restored if the TAB source is a ceiling/floor. Still, what exactly is the bug? I'm not supposed to guess how you got to that point, am I?

[Steambull]

By the way, what's our "policy" on windows that look outside? I suppose that we can do that without caring about the windows following the graphics of the textures outside (much like the maps in original Duke), because as long as the glass is unbreakable, the outside texture cannot be seen (except in F7 mode).

[Daedolon]

Helixhorned, on 28 January 2014 - 05:36 AM, said:

OK, so the two ceilings in question have different panning.

While child sectors should ALWAYS take the panning of the parent sector.

Helixhorned, on 28 January 2014 - 05:36 AM, said:

I'm not supposed to guess how you got to that point, am I?

I don't know, it just started behaving like that all of a sudden, and I want to know what causes it so I can overcome it.

[Helixhorned]

Daedolon, on 28 January 2014 - 06:18 AM, said:

While child sectors should ALWAYS take the panning of the parent sector.

Yes, agreed. I cannot reproduce what you describe though, hence my request for a step-by-step instruction.

For reference, I tried:

1. TAB-copying a ceiling in the initial room (tried 3 different ones)
2. Creating a new sector in the outer room
3. Pasting the ceiling texture to the new sector's ceiling. Repeat is kept, as expected.
4. Create a child sector inside the new sector. Repeat is kept again, no anomalities for me.

Quote

I don't know, it just started behaving like that all of a sudden, and I want to know what causes it so I can overcome it.

You mean, it behaves nondeterministically, making it impossible to provide instructions that would produce the bug on my end with high probability?

[Daedolon]

I have 294 revisions of the map, I could try to find the earliest occurrence of this issue.

[Paul B]

I'll weigh in since i'm using the template as well. At this point, I'm not experiencing any issues with the alignment of the ceiling tiles. Do you think it might be specific to a certain tile selection? (Maybe try using a ceiling tiles that doesn't have such a repetitive pattern. doh!) =P

Just kidding.

[Daedolon]

Helixhorned, on 28 January 2014 - 06:31 AM, said:

I cannot reproduce what you describe though, hence my request for a step-by-step instruction.

Create a new map, set the ceiling to #742 and change the panning to 128, 128. Create a child sector and the child sector is set to 0, 128 instead.

[MetHy]

Steambull, on 28 January 2014 - 06:03 AM, said:

By the way, what's our "policy" on windows that look outside? I suppose that we can do that without caring about the windows following the graphics of the textures outside (much like the maps in original Duke), because as long as the glass is unbreakable, the outside texture cannot be seen (except in F7 mode).

I'm not sure what you mean, you mean the textures on the outside walls of the building? I wouldn't care about that if the player can't see them in first person without having to cheat.

Edit : Mister Sinister's map is done and is really good! Pretty long too as it the final version took me 15 mins even though I had already played through a beta version.

DavoX, on 27 January 2014 - 01:11 PM, said:

yes But I wonder if people will have to beat 31 maps before reaching mine

So are you in or not?

[Helixhorned]

Daedolon, on 28 January 2014 - 08:26 AM, said:

Create a new map, set the ceiling to #742 and change the panning to 128, 128. Create a child sector and the child sector is set to 0, 128 instead.

Now I got it, and it's fixed in r4275. The problem was that in the non-Lunatic build, sector[].*xpanning is used for the bunch number, and the engine function that resets the bunch numbers of a sector's ceiling/floor unconditionally cleared them to 0. The reason why I didn't get the issue at first is that I'm usually running the Lunatic build these days. D'oh! Thanks for the explicit instructions.

Now, xpanning is always kept -- if a bunch number is reset, only a cstat bit is cleared. I find that it leaves around "garbage" that way, but it's better than the bug you expecienced, I guess.

[MetHy]

So... How can Steambull and the others fix their problems then?

[Daedolon]

Just replace all textures with the proper ones, like I've done all this time.

[DavoX]

Yes I'm in!