EditorTools
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
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.
But right now I think I can do nice aligned things thanks to these goodies.
-
- Godlike
- Posts: 3177
- Joined: Sat Mar 21, 2020 5:32 am
Re: EditorTools
You check latest version?
Code: Select all
loc.x = int(int((loc.x/GridSize.x) + 0.5)*GridSize.x + 0.5)
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
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.
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.
-
- Godlike
- Posts: 2201
- Joined: Sun Oct 05, 2008 3:31 am
Re: EditorTools
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.
However I am in need of a new install anyway.
Binary Space Partitioning
-
- Godlike
- Posts: 3177
- Joined: Sat Mar 21, 2020 5:32 am
Re: EditorTools
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.
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.
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
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.
I tried to align 91 triggers... They weren't really aligned for some reason and returned bad coordinates...
Previous method worked.
-
- Godlike
- Posts: 2929
- Joined: Fri Sep 25, 2015 9:01 pm
- Location: moved without proper hashing
Re: EditorTools
Is there any reason to have Actors (not brushes) aligned to the grid?
"If Origin not in center it be not in center." --Buggie
-
- Godlike
- Posts: 2201
- Joined: Sun Oct 05, 2008 3:31 am
Re: EditorTools
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
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
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...
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 .
You do not have the required permissions to view the files attached to this post.
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
Bump - Either Way -
This is DynamicWater (in this case Dynamic Lava)
Of course, we are talking about networking...
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...
More than a reason to align stuff at grid... It's called "Level Design"
This is DynamicWater (in this case Dynamic Lava)
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);
}
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.
-
- Godlike
- Posts: 5498
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: EditorTools
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.
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.
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
Not in all maps all actors are snapped properly but...
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...
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).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,
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.
-
- Godlike
- Posts: 2201
- Joined: Sun Oct 05, 2008 3:31 am
Re: EditorTools
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.
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
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
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.
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.
-
- Godlike
- Posts: 6438
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: EditorTools
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.