EditorTools

[sektor2111]

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]

You check latest version?

Code: Select all

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

[sektor2111]

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]

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.

[Buggie]

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.

[sektor2111]

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.

[Barbie]

Is there any reason to have Actors (not brushes) aligned to the grid?

[Red_Fist]

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.

[sektor2111]

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 .

[sektor2111]

Bump - Either Way -

Is there any reason to have Actors (not brushes) aligned to the grid?

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...
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...

[Feralidragon]

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.

[sektor2111]

Not in all maps all actors are snapped properly but...

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...

[Red_Fist]

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.

[sektor2111]

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.

[sektor2111]

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.