[Fox]

I don't think making slopes out of ortogonal view would ever be possible. Remember that the sloping system in Build is very tricky and unreliable. The slope (from both floor and ceiling) depends on a specific wall and a numerical value, rather than the combination of different polygons.

True ROR still is a 2.5d structure placed above another 2.5d structure. Creating "true slopes" on the other hand means throwing the Build engine in the trash and creating some completely new engine.

[Micky C]

Bug report, level 4 corruption.

How to reproduce:
1) Make a sector
2) Create a child sector within that sector
3) Extend the main sector, but not the child sector
4) Press alt-s on the inverse of the child sector to make a child sector in the top extension
5) There will now be a corruption for every wall of the child sector.

I've attached a simple sample map. The map has two almost identical areas: One with the corruption, and one ready for corruption (so you can do step 4 and see the corruption happen.)

Here's the relevant info from the log:

Extended ceilings of highlighted sectors, creating bunch 0
Extended ceilings of highlighted sectors, creating bunch 1
#1: WALL 21's DOWNWALL=15's reverse link wrong (expected 21, have -1)
   will set wall 21's downwall=15's upwall to 21 on tryfix
#2: WALL 22's DOWNWALL=16's reverse link wrong (expected 22, have -1)
   will set wall 22's downwall=16's upwall to 22 on tryfix
#3: WALL 23's DOWNWALL=17's reverse link wrong (expected 23, have -1)
   will set wall 23's downwall=17's upwall to 23 on tryfix
-- corruption level: 4
#1: WALL 21's DOWNWALL=15's reverse link wrong (expected 21, have -1)
   will set wall 21's downwall=15's upwall to 21 on tryfix
#2: WALL 22's DOWNWALL=16's reverse link wrong (expected 22, have -1)
   will set wall 22's downwall=16's upwall to 22 on tryfix
#3: WALL 23's DOWNWALL=17's reverse link wrong (expected 23, have -1)
   will set wall 23's downwall=17's upwall to 23 on tryfix
-- corruption level: 4
#1: WALL 21's DOWNWALL=15's reverse link wrong (expected 21, have -1)
   will set wall 21's downwall=15's upwall to 21 on tryfix
#2: WALL 22's DOWNWALL=16's reverse link wrong (expected 22, have -1)
   will set wall 22's downwall=16's upwall to 22 on tryfix
#3: WALL 23's DOWNWALL=17's reverse link wrong (expected 23, have -1)
   will set wall 23's downwall=17's upwall to 23 on tryfix
-- corruption level: 4

Attached File(s)

•  corrupt1.zip (448bytes)
  Number of downloads: 233

[Helixhorned]

Good find, it's something I often get wrong.

[Mblackwell]

 Hendricks266, on 11 September 2011 - 08:56 AM, said:

While what you said is true, it could be possible to manipulate the vertices on each end of the slope using some math. If there is a formula to display the slope in 3D mode based on only the floorz/ceilingz, firstwall, and heinum, then there could be one for side-view mode.

I guess I should have been specific: It's not that you couldn't make a matching vertex pair move (or the slope visible), but rather you couldn't make the movement independent (it would always have to be pairs related to the slope as you said).

 Helixhorned, on 11 September 2011 - 02:11 PM, said:

There's also the infinitely more trickier issue of what it actually means to be dragging a vertex vertically. Which sectors should be affected, for example? What if one affected point is the firstwall or its point2? I'm sure the feature requests are well-intentioned, but often they can only be easily implemented for corner cases.

Also this.

So it's impossible to have a free-transform, and I'd say the alternative method (of dragging the paired slope, which is really just dragging a wall) is unlikely.

[rasmus thorup]

 Fox, on 11 September 2011 - 05:56 PM, said:

I don't think making slopes out of ortogonal view would ever be possible. Remember that the sloping system in Build is very tricky and unreliable. The slope (from both floor and ceiling) depends on a specific wall and a numerical value, rather than the combination of different polygons.

True ROR still is a 2.5d structure placed above another 2.5d structure. Creating "true slopes" on the other hand means throwing the Build engine in the trash and creating some completely new engine.

How is sloping in build unreliable?

[Mblackwell]

http://wiki.eduke32....wiki/Floorslope etc

I believe the point is that the angle and direction of the slope depends entirely on the firstwall and the size of the sector. It's pretty easy to get ridiculous things to happen. Not that there's not fancy math behind it, or inconsistent results.

[rasmus thorup]

I think unreliable is the wrong word. When i started to make my outdoor nature maps, i had to learn everything about sloping in build in order to make hills work the way i wanted. And still now i find it very limited. But it is not unreliable. And the math really ain't that fancy. But it can be hard for a beginner to control it, and it takes experience to learn how to set up sectors so it looks good. It is entirely possible to perfectly slope sectors with the CON.

[Helixhorned]

 rasmus thorup, on 11 September 2011 - 04:34 PM, said:

While i have your attention helixhorned. Did you create the mkterrain state? I love it. I have a similiar system with the CON, though the only weakness it has is that it only activates while in-game. I request that you add the option for mkterrain state, to set the walls of the sectors to the same as the floor or the ceiling. You can see the little gap between the 2 sectors, which there is nothing to do about right now. If you could copy the texture and the shade to the wall from the floor/ceiling. Then it wouldn't be as noticeable. I've done it with CON. Should be even easier with mapster.

Glad to hear that you find it useful! I'm having a hard time understanding your complaint though, could you post a picture that illustrates it? The alignment should be near-perfect, limited only by the finite precision of the heinum member.

Quote

The biggest problem with sloping/making hills in build/mapster32 right now, is that it requires multiple sectors to do so. And each of those sectors require that you foresee the situation. Some hills are impossible to make.

Any hill which could be drawn as a topographical ("contour") map should also be doable with mkterrain.

[Spirrwell]

I'm sure that years down the line, the Build engine will be almost completely re-written, with these latest strides and innovations that are amazing, it just seems to be a matter of time. With new stuff, means that there needs to be a higher level of stability, it just seems highly probable that we won't be disappointed by future work at all here.

[Danukem]

 Spirrwell, on 14 September 2011 - 01:08 PM, said:

I'm sure that years down the line, the Build engine will be almost completely re-written

What do you mean by that? I'm pretty sure that you are wrong, but your meaning isn't clear.

[Spirrwell]

 DeeperThought, on 14 September 2011 - 01:23 PM, said:

What do you mean by that? I'm pretty sure that you are wrong, but your meaning isn't clear.

I was speaking to rasmus, he seemed a bit disappointed, but I think that things are going to get better and better, much more so than what we have now. And what I said about the build engine being almost completely re-written, I was speaking in general terms, that the Build engine would need to be modified to compensate for newer innovations.

[Hendricks266]

The main improvement I can think of is to rewrite the engine so that it has fully-3D sectors with all vertices independently movable along with a text-based map format and dynamically increasing sprite/sector/wall/etc limits (read: infinite). But that's a pipe dream and something more suited to a doctorate project.

[Spirrwell]

 Hendricks266, on 14 September 2011 - 02:10 PM, said:

The main improvement I can think of is to rewrite the engine so that it has fully-3D sectors with all vertices independently movable along with a text-based map format and dynamically increasing sprite/sector/wall/etc limits (read: infinite). But that's a pipe dream and something more suited to a doctorate project.

Well, that's why I said in the coming years, TROR is like the first step, I'm sure things will improve. Someday I hope to start helping, which that itself is a couple years down the line. Right now I'm doing an installer for ReaperMan to help him with his voxels to make it more accessible to users. It was something insanely easy to do inside of Visual Studio 2010, but I want to help with the community here. I'll get there.

[rasmus thorup]

Okay guys. It seems that my bad english has caused some confusion. I love the build/mapster. And all the work that has been put into it is amazing. It's fantastic how such old things can still be upgraded.
@ Helixhorned, yes your mkterrain works as good as it possibly can. And the fact that the state works so good with the topographical sector-design doesn't surprise me. Because i made some con coding that works basicly the same way. The only thing it needs in my eyes is to change the walls.

Here is the result of the mkterrain state. The sloping is as close to perfect as it can be. But that is not good enough. Though there is a solution, and that make the walls look just like the floors.
Your mkterrain state:


My CON coded actor:


The idea: Make the mkterrain state copy the texture and shade from the floor, and paste it onto the walls. It's just a time saver. But it saves a lot.

Don't mind the floating grass >.>

[Stabs]

how do i use this "mkterrain" of which you speak?

[Spirrwell]

 rasmus thorup, on 14 September 2011 - 03:34 PM, said:

Okay guys. It seems that my bad english has caused some confusion. I love the build/mapster. And all the work that has been put into it is amazing. It's fantastic how such old things can still be upgraded.

No no no, I got that. You just seemed disappointed about some features that are missing that you'd like, I was saying that in the next few years, thanks to these new innovations, this might make it all easier, making new things happen in due time.

[Plagman]

 DanM, on 14 September 2011 - 04:32 PM, said:

how do i use this "mkterrain" of which you speak?

http://forums.duke4....h__1#entry77536

[Helixhorned]

I realized that the question posed earlier by HellFire isn't as straight-forward as I made it sound, therefore I made an illustrated tutorial, linked here as APNG and the individual frames as ZIP.

rasmus thorup: ah, I see, you tweak the wall textures in order to make the seam less noticable. I don't think I'll be making a.m32 changes in the near future, but if you can port that part of your CON code to m32script, I'll be happy to merge it.

Edit 20150218: updated URLs.

[Micky C]

Is something going to be done about textured 2D mode with TROR? It's pretty useless unless it actually shows the textures of the floor that's currently selected. More often then not, it actually shows the texture of the TROR portals themselves (which are invisible in-game) so everything appears to have the same texture.

[Micky C]

Place the mouse cursor inside the sector you want to select, then hold (alt) (') and (ctrl) at the same time. Then release alt. You can also deselect sectors the same way with the ; button instead of the ' button.

But just a heads up, somebody has already added transparent water to all the episode 1 levels, including the submarine area in e1l3. It's a available as a map pack somewhere in this thread I think. Try doing a search.

[TerminX]

Okay, uh, maybe I'm missing something obvious here but what's up with the post made by "Chun"? The post text is certainly relevant enough but the post had spam links at the end. I don't get it.

[HellFire]

I easily noticed my shitty english on that post made by "Chun". Check page 4, Chun's post is just a copy of a post of mine but cut in half. Maybe its a more sophisticated bot that searches the current topic and reposts some stuff?

[TerminX]

Ah, I should have figured. Removed.

[Stabs]

how exactly do i remove a specfic sector or group of sectors from a tror bunch with ctrl+u without screwing up the whole bunch?

[Helixhorned]

You can't. Recall that a bunch is a collection of N ceilings and M floors (N, M >= 1) so that the ceilings cover the same planar area as the floors. Unlinking only a subset of the ceilings or floors from a bunch would invalidate this requirement except for special cases.

[Fox]

Heck, I still think you should be able to view everything as layers. For example I assign the bottom of the ROR as Layer 1 and top of a ROR and the roof of surrounding buildings as Layer 2.

Otherwise it's nearby impossible to work, since my brain lacks processing power to work with multiple RORs in ortogonal view.

[Stabs]

I seem to recall you mentioning a slicer tool that allows you to dissect multiple sectors with a single line, how do i use that?

and the squish code, that mite have to be modified to not squish when going between some TROR portals or is that just something that cant be helped?

[Danukem]

I need a way to be able to detect, using CON script, whether a given sector's floor or ceiling has a TROR extension. It would be nice if it was something simple like a bit in the floor/ceiling stat (it doesn't matter that the bit won't actually control it).

[Plagman]

Bit 10 of the floor/ceiling statnum should tell you if it's part of a TROR bunch.

[DavoX]

Is it hard to implement ROR the way Blood does it?