EditorTools

Tutorials and discussions about Mapping - Introduce your own ones!
User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Sat Sep 12, 2020 9:43 pm

Previous code, like you said, returns a round to the nearest grid integer - lower or upper, for me it's pretty useful. Some BSPCuts from a map have been mitigated due to a new alignment, of course they had a few bad polys... there probably doesn't worth wasting time, it's missing game-flow... that's another story.

But right now I think I can do nice aligned things thanks to these goodies.

Buggie
Adept
Posts: 411
Joined: Sat Mar 21, 2020 5:32 am

Re: EditorTools

Post by Buggie » Sat Sep 12, 2020 10:14 pm

You check latest version?

Code: Select all

loc.x = int(int((loc.x/GridSize.x) + 0.5)*GridSize.x + 0.5)

User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Sun Sep 13, 2020 3:36 am

Yep... it's flawless.
Edit:
I've added a couple of information if selected actors are aligned already or they have been aligned during current alignment request and all those selection checkers. Right now I'm looking again at scripts. Here is involved a check: old location data - new location data proposed, because if data is matching, actor won't be moved. I think that SetLocation is generating junk bytes like OldLocation which doesn't make any sense to fill map with these left-over "history" things, this is not run-time, it's an editing session.

Red_Fist
Godlike
Posts: 1873
Joined: Sun Oct 05, 2008 3:31 am

Re: EditorTools

Post by Red_Fist » Sun Sep 13, 2020 6:54 am

All I know is now the damn 2d editor makes a tessellated brush from a simple extrusion. From installing all this editor crap. (pissed)

However I am in need of a new install anyway.
Binary Space Partitioning

Buggie
Adept
Posts: 411
Joined: Sat Mar 21, 2020 5:32 am

Re: EditorTools

Post by Buggie » Sun Sep 13, 2020 7:06 am

Not connected with this tools.
Also you can select brush - poligons - merge. Rebuild geometry and all coplanar poligons must act as one.
If surtfaces not merged - try unalign/align to floor/wall all surfaces of brush. And repeat merge again.

User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Sun Sep 13, 2020 9:29 am

Mmm... I went back to simple INT rounding.
I tried to align 91 triggers... They weren't really aligned for some reason and returned bad coordinates...
Previous method worked.

User avatar
Barbie
Godlike
Posts: 2064
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: EditorTools

Post by Barbie » Sun Sep 13, 2020 1:21 pm

Is there any reason to have Actors (not brushes) aligned to the grid?
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

Red_Fist
Godlike
Posts: 1873
Joined: Sun Oct 05, 2008 3:31 am

Re: EditorTools

Post by Red_Fist » Sun Sep 13, 2020 5:41 pm

Buggie wrote:
Sun Sep 13, 2020 7:06 am
Not connected with this tools.
Also you can select brush - poligons - merge. Rebuild geometry and all coplanar poligons must act as one.
If surtfaces not merged - try unalign/align to floor/wall all surfaces of brush. And repeat merge again.

No, I need to start over anyway, got so much stuff just insane.
Plus I moved my ut2004 install , moved it back, after I reinstalled win 7 it says my key is bad, but the editor opens is all I really need.
Binary Space Partitioning

User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Sun Sep 13, 2020 6:01 pm

Barbie wrote:
Sun Sep 13, 2020 1:21 pm
Is there any reason to have Actors (not brushes) aligned to the grid?
Yes, where I have small tunnels having 36-38 UU width (or a bit more) and I need PathNodes perfectly aligned - Like the rest of things.
And since this operation takes around 5 seconds why would not do it ? It will align decorations, lights (where they have to be exactly in the middle of a lamp...) everything, it doesn't hurt after all. A trigger for a 256 hall can be mapped to 260 UU, I will attempt to drop it in the middle and in next seconds aligning it perfectly. Why wasting time "pixeling" location ? Why preserving a stupid useless size since it can be properly placed using grid. If Editor has something without bugs, that's probably the grid and then I will be extremely abusive with this grid.
Else, next is the question: Is there any reason for not having everything aligned at grid ?
Look at these paths. I was wasting time painting these, now is easier...
StillTooBigTunnels.PNG
At a moment I've quit aligning each of them one by one...
By using this toy, even if I'm drunk or a half asleep I can have a perfect alignment - because builder is not drinking and neither sleeping :lol2: .
You do not have the required permissions to view the files attached to this post.

User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Thu Mar 18, 2021 8:20 am

Bump - Either Way -
Barbie wrote:
Sun Sep 13, 2020 1:21 pm
Is there any reason to have Actors (not brushes) aligned to the grid?
:agree1: More than a reason to align stuff at grid... It's called "Level Design"
This is DynamicWater (in this case Dynamic Lava)
GettingThemAligned.PNG
GettingThemAligned_1.PNG
Full credits at Daewon for his dynamic stuff... Respect, Sir !

Of course, we are talking about networking...

Code: Select all

class SMedium expands SmallWaves;

simulated function PostBeginPlay()
{
	if ( Level.NetMode != NM_DedicatedServer )
		LoopAnim('SmallWave',1.0);
}
I believe that a tool capable to align actors at grid is MANDATORY not optional... :sleep:
Let me see - NetUpdateFrequency can be set at 20, I don't think these do need more... and I believe that once replicated first time and then sitting latent, engine will recover those 128 channels for other purposes as long as these won't change over time but "making noise" only in clients...
You do not have the required permissions to view the files attached to this post.

User avatar
Feralidragon
Godlike
Posts: 5300
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: EditorTools

Post by Feralidragon » Thu Mar 18, 2021 12:13 pm

You can already align actors to the grid from the start though, by setting the bEdShouldSnap property to True.
If you check my latest maps, you will see that every single actor there has this property set, so they are all perfectly aligned with the grid.

Having that said, enabling this only activates "snapping", meaning that it will use the current actor position as the base position for snapping.
Meaning that if the actor is already outside of the grid, it will remain outside of the grid, but it will move in such a way that it will snap in intervals equivalent to the current grid setting (16uu grid -> 16uu intervals).
So you have to start with the actor already aligned, which it does start by default if you add it through one of the 3D viewports, but you can always set the Location manually in the properties to do the same.

It also has some bugs when you go down to a grid as small as 4uu wide, and starts to unalign for some reason, and starts to behave erratically sometimes (it's really annoying when it does).

But, having some sort of tool to do that without needing to enable this property for every single actor would indeed come in handy.
I might open an issue at github with this feature request.

User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Thu Mar 18, 2021 6:09 pm

Not in all maps all actors are snapped properly but...
Feralidragon wrote:
Thu Mar 18, 2021 12:13 pm
Meaning that if the actor is already outside of the grid, it will remain outside of the grid,
all selected actors and set bCollideWhenPlacing=False + bCollideWorld=False are going snapped at grid doesn't matter anything else. All task takes a few seconds and 100% accuracy. Definitely I won't check and compute 128 Actors if Builder does this during an eye blink and ZERO errors - even if sometimes command needs applied twice (like a vaccine).
You can see this task in MapGarbage where grid is acquired from INI (credits go at Buggie preventing my brain to get burned...) or... user defined... By removing said collisions NOTHING is escaping from being aligned, MapGarbage doesn't have mercy at this point... Why the feature ? Because in certain maps aligning is mandatory for a good design (coronas, decorations, even pathnodes for maximum size of reachSpecs calculations in a center of a tunnel or such) and these miss-aligned things doesn't need more than selecting them, putting option to True, and BUILD button does aligning without discussions. Of course if an actor is selected and has borked data it needs a "refresh" of properties for getting new location data else it looks untouched. Believe me or not ALL of them can be aligned, it doesn't even need bEdShouldSnap. If we are in 16 UU grid and we want them snapped at an 8 UU grid, this is also doable without toggling grid values. UScript does not include shakes of hands or some mouse with issues - bang, and we are on GRID.

Hint for mappers saying: I cannot add PathNodes in that spot. False - PathNodes can be added everywhere exactly as other similar actors, if they are helping in that spot. All we need is "preparing them" first for being added WITHOUT saving stock files but adjusting things a bit during editing session. Nothing goes screwed if you know what you do. "!bCollideWorld" and "!bCollideWhenPlacing" are the key for snapping EVERYTHING (even collision cylinder can be "prepared") at grid and PLACING these everywhere not only bEdSnap and bEdShouldSnap.

Note: Sektor's Editor settings is defaulted at 8 UU grid not 16 UU. I see that more stock maps are having geometry fitting well at 8 UU. I think this is what they used.

In this particular case, it looks like networking is not so helpful and then... These actors configured as bNoDelete are keeping animation timing (they should look as linked waves in a whole water surface) and this seems to have a better deal (like a single MESH) as bNoDelete ones... or just creating them separately in client...
Last edited by sektor2111 on Thu Mar 18, 2021 6:50 pm, edited 2 times in total.

Red_Fist
Godlike
Posts: 1873
Joined: Sun Oct 05, 2008 3:31 am

Re: EditorTools

Post by Red_Fist » Thu Mar 18, 2021 6:48 pm

I always use grid 1, and have always never used snapping. It's the same idea of "digital" if I have a digital FM AM tuner it won't let you deviate to infinity like to tune between stations, like analog can. It's like taking away my power or decisions to do what I want. Same for CD DVD and all that "sampling" whereas a record records every flaw and note. Granted DVD audio lessens the problem, but yet I know it's digital.

Having said that, this type of 3D graphics has to have a grid.

I wish they made the grid go to 1/2 or .5 grid resolution, I just hate that snapping, but I can see if you stay at 16 grid from a map made from scratch, but I hardly get the convenience from some screwed up geometry from an existing map, so I always used grid 1 since day 1.

If I need perfection I edit the location of the actors in properties. x y or z.
Binary Space Partitioning

User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Thu Mar 18, 2021 6:55 pm

Nah, I won't edit X hundreds of actors, MapGarbage can use a 1 UU grid if mapper wants such things. Floating numbers are exactly what Editor dislikes as I could see over time... in X maps with a bug at geometry I aligned brushes or... Editing them in Notepad - another thing is nasty... such maps are not having only a brush bugged, these are having usually thousands requiring a lot of checks, and MapGarbage cannot solve a bad vertex... EPIC has forgot granting access to UScript here (geometry assets - brushes, revealing some coordinates not only creating them) else it would be a piece of cake to fix X GB of messed up maps. It's why I was waiting/expecting some extra 469 features for editing as long as game it's not affected because game is not editing map, but builder does this, and a brush builder it's not part of run-time classes. A well executed map runs in 436 without problems concerning a brush builder. It's exactly the same as for pathing, a reachSpec it's a reachSpec custom or automated, Engine has no problems running what mapper has done if all has logic.

To not forget that fore-mentioned function it's written even for negative values of x y z and it does such an alignment too for "decollided" actors moving them at grid without discrimination.

User avatar
sektor2111
Godlike
Posts: 5193
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: EditorTools

Post by sektor2111 » Fri Mar 19, 2021 7:36 pm

Future version of MapGarbage will have this feature for alignment a bit modified. Exactly those actors delegated to auto-snap at grid might have "pivoting" issues and lousy things will happen, and then these can be adjusted to no longer mess with Editor's alignment but letting builder to do its job as long as there is no failure in snapping them at desired "GridSize" - aligning is currently possible after doing a few moves, but... these can be automated preventing mapper/editor from wasting time. This won't affect actors with a PrePivot adjusted - this is another story, the design should not be affected - certain actors need a bit of tuning at this chapter.