Work arounds, hints, etc.

[Nelsona]

I think if we have a general mapping thread will be useful for whoever wants to make small steps in advanced mapping (not rocket science mapping...) but basics...
While I got busy with tutorials at UT99.org while some topic has been updated I really could see that some of those links and descriptions are "funny". One of problems was describing the best way in making whatever cylinder to be done using 2D Shape Editor because this way is causing a better alignment compared with cylinder builder. The dude writing that probably doesn't know console options as others think are mappers but they cannot deintersect and align brushes correctly.
I'll prepare a tiny and summary description about these aligning problems which aren't that grave as they do looks like.

[SC]-[WARTZ_{HoF}]

I'm looking forward to this.

[Nelsona]

Cylinder alignment
Description: it's way faster using a builder than painting each vertex.
Let's select and input data for a small cylinder and then pressing build Button:

stage_0.PNG (36.83 KiB) Viewed 10301 times

Apparently (shown in circles) vertexes don't seems indeed aligned at grid having floating values.
By Using Command Actor Align which for me is way simple because I have a button (and even more buttons) bound for that, I think we can have cylinder aligned somehow depending on grid used (my case it's 8 UU by default).

stage_1.PNG (104.29 KiB) Viewed 10301 times

It looks aligned but I want to see in numerical format what is about

stage_2.PNG (39.5 KiB) Viewed 10301 times

using Menu - Edit - Copy command and then Menu Edit Paste in some text editor - brush will have a numerical format and I will look where is being written "Vertex"

...
Begin Brush Name=Brush
Begin PolyList
Begin Polygon Item=Wall
Origin +00025.460785,+00128.000000,-00128.000000
Normal +00000.316228,+00000.948683,+00000.000000
TextureU +00000.948683,-00000.316228,+00000.000000
TextureV +00000.000000,+00000.000000,-00001.000000
Vertex +00024.000000,+00128.000000,-00128.000000
Vertex +00024.000000,+00128.000000,+00128.000000
Vertex +00072.000000,+00112.000000,+00128.000000
Vertex +00072.000000,+00112.000000,-00128.000000
End Polygon
Begin Polygon Item=Wall
Origin +00072.506180,+00108.513161,-00128.000000
Normal +00000.707107,+00000.707107,+00000.000000
TextureU +00000.707107,-00000.707107,+00000.000000
TextureV +00000.000000,+00000.000000,-00001.000000
Vertex +00072.000000,+00112.000000,-00128.000000
Vertex +00072.000000,+00112.000000,+00128.000000
Vertex +00112.000000,+00072.000000,+00128.000000
Vertex +00112.000000,+00072.000000,-00128.000000
End Polygon
Begin Polygon Item=Wall
Origin +00108.513168,+00072.506172,-00128.000000
Normal +00000.948683,+00000.316228,+00000.000000
TextureU +00000.316228,-00000.948683,+00000.000000
TextureV +00000.000000,+00000.000000,-00001.000000
Vertex +00112.000000,+00072.000000,-00128.000000
Vertex +00112.000000,+00072.000000,+00128.000000
Vertex +00128.000000,+00024.000000,+00128.000000
Vertex +00128.000000,+00024.000000,-00128.000000
End Polygon
Begin Polygon Item=Wall
Origin +00128.000015,+00025.460773,-00128.000000
Normal +00001.000000,+00000.000000,+00000.000000
TextureU +00000.000000,-00001.000000,+00000.000000
TextureV +00000.000000,+00000.000000,-00001.000000
Vertex +00128.000000,+00024.000000,-00128.000000
Vertex +00128.000000,+00024.000000,+00128.000000
Vertex +00128.000000,-00024.000000,+00128.000000
Vertex +00128.000000,-00024.000000,-00128.000000
End Polygon
...

Origins and textures are not fitting exactly due to surfaces created but Vertexes are perfectly aligned.
So to speak we have a cylinder which will not be causing too many problems if it will be linked at grid with other brush having the same good build.
THAT simple... builder and button + data input do take under a minute for building a cylinder or whatever brush fitting to the grid.

[SC]-[WARTZ_{HoF}]

I need to really install those builder buttons you have there when i get back to my super mario mapping. By the way great tutorial.

[Nelsona]

Next stage is speaking about a map sampled in some tutorial fixed and over-fixed, and in final stage not fixed. At least what I could do inside it it's way better than mappers did all these years. It's somehow pathetic to see "awesome" descriptions when the Level do sucks starting with second battle area.

[Nelsona]

Time to see some real "facts".
In map mentioned in an earlier post we have this zone

T2_00.PNG (396.29 KiB) Viewed 10285 times

where player dies falling into void - around wall marked with red circle, so to speak we have an issue with that wall.
By looking at brush I think we have some values not that ".000000" as expected but something even rammed for real.

Code: Select all

         Begin Polygon Item=Outer Texture=Wrcka3 Link=5
...
             Vertex   +00148.077301,-01216.000000,-00512.000000
             Vertex   +00148.077271,-01216.000000,+00512.000000
...
          Begin Polygon Item=Outer Texture=Wrcka3 Link=6
             Vertex   +00148.077271,-01216.000000,+00512.000000
             Vertex   +00148.077301,-01216.000000,-00512.000000
          End Polygon

If you did not figure the problem, then let's bring some light around. As samples (not checked the rest) Link5 and Link6 do seem to have 2 values at a point which should be in the same point of space. Actually this brush is broken having a "leak".
As a primary fix I went to align it and even doing advanced Vertex editing in order to gain similar values.
This is one of errors but that brush has even other one around value 212.xxxxxxx.
148.077271 is not 148.000000 and not even 148.077301, from float value ...271 to ...301 we have some tiny space proving that bsp tree was going down-hill linking play space with void. This is - read well - version "_fix5" which looks dated 2015, not that old.

Another stage except that burial of player. Titan has came outta box like the box is not even there just as a non-solid thing. By setting up Mover for figuring textures and almost how it do looks in game - RightClick - Mover - ShowPolys

T2_01.PNG (219.44 KiB) Viewed 10285 times

I was surprised about the "picture" showing up next second.

T2_02.PNG (725.04 KiB) Viewed 10285 times

To summarize this mover is perfectly rammed - I suspect that it was build in high speed and touching other brush - usually when we are adding a mover builder should NEVER touch any other brush. Here we cannot talk about alignment at grid because it's probably a myth.
Fixing solution - doesn't looks like we have more options.
By copying red builder brush to Mover and making another mover will result two movers rammed. At this moment I don't know other solution than redoing it - and this is what I did.
Game play being not a very mapping problem I won't chat about it toward this area of map, but we can step to next point.

[Nelsona]

It's time to debate a bit Brutes zone. That "buried alive" thingy...

T2_03.png (1.12 MiB) Viewed 10272 times

Eh, "nice" map... Something in my head is whispering that we have some another entertaining brush: Brush188. Let's take a tour... figuring only essential things.

Code: Select all

....
             Vertex   -00768.000000,-00152.764694,-00256.000000
             Vertex   -00768.000000,-00152.764694,+00256.000000
             Vertex   -00768.000000,+00152.764603,+00256.000000
             Vertex   -00768.000000,+00152.764603,-00256.000000
....

I think we speak about brushes with non-coplanar polygons. In 2D space when we are doing 3D things then we are going into wrong direction...
Solution applied aligning this thing and if by chance it has developed later an ugly BSP cut, I turned both those big brushes at whatever 32768 rotation, I mean Left to Right or up side down. Improvements have been noticed after rebuilding all geometry related things.
That's all about "stock fixing" which I did not see why mappers were only blabbering around spreading more than 5 versions of the same messed up thing.
Next chapter is Bot speech for interested persons. That stuff is not that doable here with stock repository. Human is required for "manual override" during game.

[Nelsona]

Due to some object troubles (bad conformed stuff anyway) reported by Barbie at UT99.org and sampling map doing funky things MH-Horus, we can discuss a bit porting map "strategy" (None btw).
By Accident (not as a game event) I found some string saying in a never seen MonsterEvent
"Map made by Zeppy_{HoF}" because this is not the way of doing a message-trigger and actually we have some stuff in LevelInfo Author = Arjan Vroegop a.k.a. Evil Atje, which makes me a bit confused. Given the skill for setting up messages, I think map is not made by Zeppy in hoping to not wrong here... Whoever was setting up Events here, doesn't seems to have a clue what was doing...

By checking game-type class, in this MH map we have game-type "BotPack.CTFGame". The result might be shown, probably depending on environment (XCGE my case).

HorusAddiction.PNG (20.36 KiB) Viewed 10219 times

when I hit a double click directly on map inside Maps folder. Actually CTFGame is trying to enter as MH which technically is a retarded thing.

Guys, if you want to port a map to MH you should ask some help because this is not the "how to". By doing the right setup, map starts normally when a direct double click on it is being applied - I'm not doing research right now which Chaos version was used for doing this map. The final question is: Why was necessary to ruin Bot Support ? Map has paths and it would be very nice to have the end reachable and MH has nothing in common with AlternatePath actors - sweet dreams here.

Probably this production was done in 2012 when we were supposed to die according to retarded news announced everywhere in that time so no one would care what's going on anyway. But we did not die and the awesome ported "map" stays alive as well haunting servers and it will be like that for years.

[Nelsona]

Bump here - Until to get some inspiration for a map which I had in mind.

By The Way, speaking about mapping from years 2012 and around, I was intended to fix a bit map Imperialbase. Last time TB dude has asked me about my PROBLEM with his maps. Actually I'm going to show WHO has problems and REAL problems after time spent in Editor and/or whatever editing crapped thing.

This Level shorter IB has a nasty BSP problem around LordSith battle zone. Map has brushes stripped out - probably was "perfect" so it won't need any fix and those Troopers have a "funny" death animations. I could solve their animations but operating map VIA BSP building/rebuilding was showing a major issue MAX_POINTS hard-coded value from engine went over boundaries. WE have options:
- Solving all game ground geometry and crashing player when Han's ship is entering the stage - over 128000 points;
- Messing up polygons for ship, like is damaged by battle and keeping player alive - also with the risk to develop HOMs around those ugly BSP cuts;
- Leaving BSP problem in original and annoying players when some Lord Sith will go behind an invisible wall being invincible there...

Other stuff is not that fixable because all brushes have been deleted making fixing a very hard task...

Not the last problem is this one (not the only one):

IB_crapped.PNG (1.08 MiB) Viewed 10099 times

Which actually could be changed into this

IB_changed.PNG (1.09 MiB) Viewed 10099 times

Way different right ? Right !
I'm not gonna speak about texture properties which seems like are a null thing without reacting at Masking command/property - I do not have a clue what was used here, but for sure NOT UT's Editor and is not the single map done this way.

I was wondering when these people will want to start a team-work around, with testers in team able to figure and to report everything for bug-fixing before to release such things in public.

I've done pathing and tweaking modules for NavAdder but it doesn't worth patching because of its current stage.

[SC]-[WARTZ_{HoF}]

Clearly masking textures properly is not rocket science and ThunderBolt has difficulty with any criticism if someone points out some flaws with his maps. I wouldn't want to waste my time fixing his perfect( ) works LOL.