[Helixhorned]

MAXTILES-1 and MAXTILES-2 are used for the fake RoR texture. MAXTILES is 15360.

[Jblade]

Huh, I haven't gotten to that limit just yet - I'll have to do some testing to figure out what's causing this oddity; it looks completely fine in a normal atomic Duke install but in my mod's build directory I get this:

might it be a palette issue or something? I can't test it ingame yet as TX is still running some tests on his fix for the con compilitation errors I was getting but I imagine it'd be the same ingame.

EDIT: Solved it! It was changing to tile number 13 which I'd stuck a tile in. Removing that sorted the problem.

[Fox]

Helixhorned, on 19 May 2011 - 02:44 AM, said:

MAXTILES-1 and MAXTILES-2 are used for the fake RoR texture. MAXTILES is 15360.

Interesting, would it work if you set it to MIRROR texture? That seems somewhat appropriate

[m210®]

Can I join too independent sector with TROR?



And reconstruction of second ROR on Blood E1M1 map is imposible

[Helixhorned]

Fox, on 19 May 2011 - 03:16 AM, said:

Interesting, would it work if you set it to MIRROR texture? That seems somewhat appropriate

MIRROR isn't completely translucent as far as I can see.

M210, on 20 May 2011 - 02:37 AM, said:

Can I join too independent sector with TROR?

No, right now you have to do all the mapping in a forward fashion.

[Jblade]

Now I can use this ingame with the coding bug TX fixed this is really amazing - I can't beleive how ridiculously easy this actually is to work with. It's actually EASIER to make water now since you don't need to bother with copying and pasting sectors all over; it's not something that can be chucked in on old work however but by itself it's really easy to make cool 3D level styles now. I've had a blast adding it to areas of the AMC TC. Thanks again for this Helixhorned, it's given me some more mapping spirit now (I just have to wait for a day off from work so I can actually get to grips with it )

[Hendricks266]

What about the old FOF tile? It's completely transparent, and it's right next to the mirror tile.

[fgsfds]

Helixhorned, on 20 May 2011 - 02:42 AM, said:

M210, on 20 May 2011 - 02:37 AM, said:

Can I join too independent sector with TROR?

No, right now you have to do all the mapping in a forward fashion.

Will it be possible in the future?

[Helixhorned]

Hendricks266, on 20 May 2011 - 04:25 AM, said:

What about the old FOF tile? It's completely transparent, and it's right next to the mirror tile.

You mean #562? That would work, but I still prefer a non-allocated tile because I can imagine it being a tad faster. If the conflict with the FOF tile (which is #13 btw) is such a big concern, I could code a search for the first void tile the very first time it attempts to draw a RORed ceiling or floor.

empy, on 20 May 2011 - 04:53 AM, said:

Will it be possible in the future?

I'm planning this, but it's not without problems. For example, how sophisticated should that joining be? Should it only join bunches of ceilings and floors that are already positioned properly, or should it attempt to displace one of them? The latter case is obviously a bit more complicated.

[m210®]

Helixhorned, on 20 May 2011 - 09:23 AM, said:

or should it attempt to displace one of them?

I thinks there is no need for this. And may be more convenient to mark the sector with textures helps and not to provide them with RALT + LMB unnecessarily sometimes it is very difficult to do.

[Stabs]

cant seem to get these newer ROR versions to work with WGR2, keeps giving me table.dat errors, i think it only wants duke3d.grp and thats it atm

[m210®]

I don't know why, but newer version of mapster can load other grp files through -grp key.
You need rewrite command -gWGR2/WGR2.GRP to -grp WGR2/WGR2.GRP. and it will works

mapster32.exe -grp WGR2/WGR2.GRP -game_dir WGR2 -hwgr2.def

[Jblade]

saw last night that you added in rudimentary polymost support helixhorned; it's not perfect but it's still great that you added it in so soon - I can use it freely without worrying that certain users are going to get left out now

[Micky C]

It's about the same as the 8-bit renderer as far as I can tell with the map I'm working on. They're both slightly buggy, although it's early on, and maybe they'll get better over time. I'm hoping though that polymer will be able to draw everything 100% correctly.

[Stabs]

M210, on 22 May 2011 - 10:49 PM, said:

I don't know why, but newer version of mapster can load other grp files through -grp key.
You need rewrite command -gWGR2/WGR2.GRP to -grp WGR2/WGR2.GRP. and it will works

mapster32.exe -grp WGR2/WGR2.GRP -game_dir WGR2 -hwgr2.def

ta enjoy a rep cookie

[Helixhorned]

DanM, on 22 May 2011 - 07:38 PM, said:

cant seem to get these newer ROR versions to work with WGR2, keeps giving me table.dat errors, i think it only wants duke3d.grp and thats it atm

Do you mean that WGR2 doesn't start with the new revision? It works for me. Maybe you have a wrong DUKE3D.GRP around? Usually it contains TABLES.DAT.

Micky C, on 23 May 2011 - 12:44 AM, said:

It's about the same as the 8-bit renderer as far as I can tell with the map I'm working on. They're both slightly buggy, although it's early on, and maybe they'll get better over time. I'm hoping though that polymer will be able to draw everything 100% correctly.

Classic support is much more complete. If you walk around the test level, you'll see dozens of places with overdraw problems etc...
It's interesting that those are almost always the same glitches that needed to be taken care of for 8-bit, which nicely demonstrates that Polymost is conceptually the classic renderer on OpenGL.

[Stabs]

So whats the deal with putting a white walled sector in between a tror, is there a special way to do that? because it looks all glitchy

[Helixhorned]

Fuck, don't use that and splitting for now! I broke it when I fixed sector deleting.

edit: alright, fixed. To answer your question, joining loops will do that, yes. To get around it, draw a line once more so that the sectors are now split and apply masking (not 1-sided masking, which behaves like a white wall in many respects). I always saw loop joining as a necessary step to splitting sectors in those cases rather than a useful feature in its own right anyway.

[Stabs]

so will there be plans to allow you to raise / lower red sectors within a TROR bunch? ive used the masking feature but it takes 3 levels to make a floating cube, if i could raise the internal red sector it would only be 2, this kinda works by starting the tror sector with a white sector within it and turning it into a red sector after the 2nd layer has been added

[Micky C]

I'd be extremely grateful if what DanM suggested could be implemented.

[Helixhorned]

That would put quite a few assumptions upside down, so the chance of it happening is rather slim. Meanwhile, enjoy joining sectors .
edit: also, in 2D mode, Ctrl-U now clears extensions from all sectors of a bunch, so there's no need to delete one for that any more.

[Master Fibbles]

That was one of the first things I had to learn how to work around. It adds more work but I don't have a huge problem with it. It also requires more planning ahead, which, in general, might not be a bad thing.

[TerminX]

Jeez Helixhorned, you're on fire!

[Gambini]

Sorry to say but I lost track of how this works, there are a couple of terms that are completely new to the 15 years old Build Dictionary, like extensions and bunchs. The whole concept is pretty unique and unusual to what we could have expected it to be like. I love the fact that, finally, there´s a fully working ROR for Duke, plus it puts the software renderer ahead of the other ones.

But: Is this stacking sectors system a requeriment for your new ROR to work? Or it´s just the way you thought it would be better to put it in use? Since now, sectors above other sectors are where they should be (one above the other). Because at this point with all these new tricks, names, combinations and map format; I began to think that, maybe, the classic tag system would have been simpler.

Don´t get me wrong, I´m loving every single progress you´re introducing into Mapster32. But I have to clear this doubt. Have you designed this TROR this way because you thought it would be better to have these combined sectors physically where they should be or it´s a technical limitation?

[Plagman]

Let's say it's both a technical limitation and common sense. I would claim I designed this system if there was really any sort design to it: when you want to link two sectors in BUILD, you put them side to side with a red wall between them, right? Well, when you want RoR you just put one sector above another and link them with a red floor or ceiling (and they form a "bunch" in helix's implementation). It's the exact same thing and is way more straightforward than working on an exploded copy of your map. It just makes it a real feature of the engine and editor instead of being a game feature with some SEs. It's both easier to work with and visualize and a lot easier to render with Polymer, so there's a technical aspect to it also.

You think that the old way is simpler because you're used to it; if you catch a mapper that doesn't know about Duke3D and force him to use Mapster32 for a while, by the time he gets the basic hang of things (after trying to run away a few times) if you present him the two approaches for RoR (levels in different parts of the maps with SEs to link them and stacked sectors) I can't see why he would pick the first one. It might be quite simple if you only have a few levels with a single sector connecting them together (assuming you never want to change the shape of that sector), but this allows editing a lot more complex stuff in a more reliable way.

[Gambini]

Thanks. Knowing the whys helps to understand the hows

Quote

when you want to link two sectors in BUILD, you put them side to side with a red wall between them, right? Well, when you want RoR you just put one sector above another and link them with a red floor or ceiling

That´s true but unlike with walls, you do not have a perfect point of view to control the joint and the surrounding elements. The sideview combined with the 3d mode helps a lot but it is a little bit awkward compared to the top view of 2d mode.

However, I understand that since Polymer is an actual 3d engine, it will make more sense to have this true linking-spaces system. That´s why i wanted to know if it was a technical limitation. I´ll have to learn the new techniques and get used to them.

Quote

(after trying to run away a few times)

lol. That´s also quite right, but most current mappers have learned to map the old way. As a last thougth: It would be really cool if we could build our sectors separately and then merge them by dragging one of the parts into the other (assuming we had the care to respect shapes and height).

[Plagman]

I think helix just added a feature where if you have two sectors that happen to touch vertically, you can join them like you said.

http://eduke32.svn.s...5&view=revision says it's CTRL-J.

[Jblade]

speaking as someone who's been building since 1999 I think this is the easiest implantation yet

[Micky C]

When sectors are grayed out, their vertices can still be moved if they're selected with right shift, which makes moving sectors around on different floors very difficult, even impossible when working on more than two or three layers.It's not just the bunch vertices, even standard single sector vertices are moved, is there any way to constrain right shift vertex selection to the confined z-coordinates?

[Jimmy]

I haven't toyed with this yet, but I think it could be useful to implement a "layers" system, much like photoshop. Like you could make the different levels count as layers, and you could toggle them invisible so you can work on one area without the other clogging up. Don't know if that's viable, or if it makes sense or what.