I’ve seen people say it is but I can’t find any credible sources. The thing I’m talking about is when you restart a forge map you saved and all the pieces are at like a 2 degree slant. If that isn’t gone I’m once again not going to forge nearly as much. People shouldn’t have to do little tricks to forge a smooth map. Please 343 if this isn’t fix make it your number one priority with Forge.
yep, its there alright.
just go on youtube and type in halo 4 forge and I’m sure you’ll see the lock feature they showm among other things.
> yep, its there alright.
>
> just go on youtube and type in halo 4 forge and I’m sure you’ll see the lock feature they showm among other things.
I don’t really understand. I’ve seen the video.
I’m asking if the bumping is still in then you tell me to watch a video that has like no relevance to what I’m talking about. They don’t save and restart at all.
Hopefully it’ll be fixed. I hate it when all my objects are slightly off, and I have to fix them.
> Hopefully it’ll be fixed. I hate it when all my objects are slightly off, and I have to fix them.
It makes me not want to forge ever. I couldn’t believe it was still in Reach. I remember people talking about it before the game was released and I was already upset. It’s a real big buzzkill for forge. Magnet is going to be useless if this still occurs.
The “bumping” is a rounding error caused by limitations in the Forge file format. They could’ve removed it entirely by changing the format (to use XYZ rotations instead of axis angle), or they could’ve lessened it by lowering the rounding (like they did when going from 3 to Reach).
Since they haven’t shown us the process of saving and loading a map, and since they haven’t (AFAIK) made any official statement on the matter, no one knows if the round-on-save problem happens in Halo 4.
I do know this, though: if they still round on save, but don’t compute a new lightmap immediately after doing the rounding, then shadows will break. So if they compute a new lightmap whenever you save, that’s a good – but not guaranteed – indicator that things are gonna get rounded.
> The “bumping” is a rounding error caused by limitations in the Forge file format. They could’ve removed it entirely by changing the format (to use XYZ rotations instead of axis angle), or they could’ve lessened it by lowering the rounding (like they did when going from 3 to Reach).
>
> Since they haven’t shown us the process of saving and loading a map, and since they haven’t (AFAIK) made any official statement on the matter, no one knows if the round-on-save problem happens in Halo 4.
>
> I do know this, though: if they still round on save, but don’t compute a new lightmap immediately after doing the rounding, then shadows will break. So if they compute a new lightmap whenever you save, that’s a good – but not guaranteed – indicator that things are gonna get rounded.
I usually understand technical talk. Please excuse me this time as I understood maybe 10% of what you said. The second paragraph made no sense to me at all. To me it sounds like we’re gonna be screwed with the tilting/bumping once again.
> The “bumping” is a rounding error caused by limitations in the Forge file format. They could’ve removed it entirely by changing the format (to use XYZ rotations instead of axis angle), or they could’ve lessened it by lowering the rounding (like they did when going from 3 to Reach).
>
> Since they haven’t shown us the process of saving and loading a map, and since they haven’t (AFAIK) made any official statement on the matter, no one knows if the round-on-save problem happens in Halo 4.
>
> I do know this, though: if they still round on save, but don’t compute a new lightmap immediately after doing the rounding, then shadows will break. So if they compute a new lightmap whenever you save, that’s a good – but not guaranteed – indicator that things are gonna get rounded.
Excuse me for a second, I think my brain shorted out. That was a REALLY technical explanation, can we please hear it in english? Just explain it to me like I’m a 4-year-old
> > The “bumping” is a rounding error caused by limitations in the Forge file format. They could’ve removed it entirely by changing the format (to use XYZ rotations instead of axis angle), or they could’ve lessened it by lowering the rounding (like they did when going from 3 to Reach).
> >
> > Since they haven’t shown us the process of saving and loading a map, and since they haven’t (AFAIK) made any official statement on the matter, no one knows if the round-on-save problem happens in Halo 4.
> >
> > I do know this, though: if they still round on save, but don’t compute a new lightmap immediately after doing the rounding, then shadows will break. So if they compute a new lightmap whenever you save, that’s a good – but not guaranteed – indicator that things are gonna get rounded.
>
> I usually understand technical talk. Please excuse me this time as I understood maybe 10% of what you said. The second paragraph made no sense to me at all. To me it sounds like we’re gonna be screwed with the tilting/bumping once again.
1: The problem lies in how the data is stored when saving. They don’t use big enough numbers.
2: They haven’t demonstrated the situation that would cause the issue. Namely, they haven’t placed an object, saved the map, exited Forge, and then edited the map again. They also haven’t said anything about the problem. So no one knows if it’s fixed.
3: Know how Forge objects cast shadows now? That’s done by calculating something called a “lightmap” – essentially a diagram of where all lights and shadows are – every time you turn back into a Spartan in Forge. If they round the objects (the problem you’re describing) without re-calculating the lightmap, then the shadows won’t align with the “bumped” objects.
The only way to avoid that issue would be for them to calculate the lightmap when the map is saved. So if you save the map, and a message about “calculating” or “rendering” or “saving” anything to do with light appears on-screen, then there’s a good chance that things will get “bumped”.
(That’s obviously not too useful now, since you don’t have Halo 4 to test all this with. I wish I could give you a better answer, but all I can do is speculate. :\ If nothing else, this might give you a few less minutes of getting your hopes up once you start Forging for the first time.)
> > > The “bumping” is a rounding error caused by limitations in the Forge file format. They could’ve removed it entirely by changing the format (to use XYZ rotations instead of axis angle), or they could’ve lessened it by lowering the rounding (like they did when going from 3 to Reach).
> > >
> > > Since they haven’t shown us the process of saving and loading a map, and since they haven’t (AFAIK) made any official statement on the matter, no one knows if the round-on-save problem happens in Halo 4.
> > >
> > > I do know this, though: if they still round on save, but don’t compute a new lightmap immediately after doing the rounding, then shadows will break. So if they compute a new lightmap whenever you save, that’s a good – but not guaranteed – indicator that things are gonna get rounded.
> >
> > I usually understand technical talk. Please excuse me this time as I understood maybe 10% of what you said. The second paragraph made no sense to me at all. To me it sounds like we’re gonna be screwed with the tilting/bumping once again.
>
> 1: The problem lies in how the data is stored when saving. They don’t use big enough numbers.
>
> 2: They haven’t demonstrated the situation that would cause the issue. Namely, they haven’t placed an object, saved the map, exited Forge, and then edited the map again. They also haven’t said anything about the problem. So no one knows if it’s fixed.
>
> 3: Know how Forge objects cast shadows now? That’s done by calculating something called a “lightmap” – essentially a diagram of where all lights and shadows are – every time you turn back into a Spartan in Forge. If they round the objects (the problem you’re describing) without re-calculating the lightmap, then the shadows won’t align with the “bumped” objects.
>
> The only way to avoid that issue would be for them to calculate the lightmap when the map is saved. So if you save the map, and a message about “calculating” or “rendering” or “saving” anything to do with light appears on-screen, then there’s a good chance that things will get “bumped”.
>
> (That’s obviously not too useful now, since you don’t have Halo 4 to test all this with. I wish I could give you a better answer, but all I can do is speculate. :\ If nothing else, this might give you a few less minutes of getting your hopes up once you start Forging for the first time.)
I understood the fist time what you were saying. I just don’t understand how it is so.
Mainly this…
“So if they compute a new lightmap whenever you save, that’s a good – but not guaranteed – indicator that things are gonna get rounded.”
I REAAAAAALLLLY hope 343 addresses this issue somehow. It’s the most annoying thing in Halo next to aim acceleration.
> yep, its there alright.
>
> just go on youtube and type in halo 4 forge and I’m sure you’ll see the lock feature they showm among other things.
I don’t think the lock feature is meant to counteract the rotation glitches. I think it’s mainly to simply prevent people from accidentally moving or deleting objects, not to prevent the game from doing that on its own. Anyway, I believe DavidJCobb pointed out in another thread that if they haven’t fixed the rounding error, locking the object wouldn’t stop the object’s rotation values from being rounded off during the save.
My personal guess is that they have fixed it, or at least reduced the amount of rounding. Also, another hopeful indication is what they said while talking about the magnet feature. I suppose it’s not confirmed exactly, but I did hear something in the 16 min, full length vid. When they were talking about the new magnet feature, they said that in the past things were hard to line up because you might “bump the controller, and then the axis were kind of screwed up” (this is about 4:40 to 4:51).
Were kind of screwed up, past-tense. Assuming this is literal, I’m quite hopeful we’ll get a rotation system this time 'round that won’t go all wonky on us when we rotate stuff off-axis. And if they’ve fixed that, there’s a good chance they’ve fixed the rounding error as well.
I’ve seen some really good maps that are designed to look like they’re out in the middle of nowhere, just to be ruined by Forge Bumping 
I really hope it is fixed.
Ugh I hope its fixed… no more scrambling around the map selecting and deselecting all the peices to make em straight
No idea, I’ve never met this glitch.
From your description, it’s possible that Magnets would at least help solve the issue, as the pieces will automatically re-snap together on being picked up.
> No idea, I’ve never met this glitch.
>
> From your description, it’s possible that Magnets would at least help solve the issue, as the pieces will automatically re-snap together on being picked up.
Never really encountered this glitch either. I used the coordinate system on my maps to get the objects placed exactly, I never really “eyeballed” it when placing my forge pieces.
I have to say though, I do love that magnet system. It’s gonna be a lot easier to build stuff now.
If they ever put in AI (Halo 5 maybe?) I would say this new Forge is close enough to perfect imo.
> Never really encountered this glitch either. I used the coordinate system on my maps to get the objects placed exactly, I never really “eyeballed” it when placing my forge pieces.
It’s not a placement glitch (as far as I know, the objects stay in the exact same place & never move), it’s a rotation glitch. And it doesn’t happen to all rotations. It tends to happen to objects when you rotate objects 90 degrees on the X. It’s more noticeable with larger objects, like coliseum walls. Try rotating one at 90 degrees X. Since you didn’t touch either the Y or the Z, they should be at 0. Now save the map, exit, and reload. Now check the rotation again. There’s a very good chance the Y and Z will both now be at 45, or both will be at -135. This is a subtle shift, but it does make a difference (a surprising one, in fact).
In fact, you don’t even have to save & reload to see it. Turn the Coliseum wall to 90 degrees X. Now, repeatedly go into & out of the coordinate menu. Unless you keep rotation snaps to 90 while doing this*, each time, it will shift between 90, 45, 45, and 90, -135, -135. It you watch the wall as you do this, you will see it noticeable “shift” (remember, it’s not actually moving, just shifting in its rotation).
*Unfortunately, keeping 90 degree snaps on won’t stop the rotation from being messed up when saving & exiting.
Hopefully, this has been fixed in H4.
As to why the rotation glitch happens, I think I know a little bit about this. From what I know, every time you save your map it converts your object’s XYZ coordinates (a total of six discreet values between placement & rotation), to a vector that represents both placement & rotation in one go. Pretty sure this is one of the reasons why the map filesizes are so small. Then when you’re editing, it converts that back to XYZ again.
Apparently, they didn’t allow for quite enough digits to store the entire vector, so it has to round up or down. This of course means a loss of accuracy. I believe what is going on is that in certain cases, the rounded off, vectorized number falls right in between two different XYZ values when it gets converted back to the XYZ system. The result is that the engine can’t make up its mind between the two.
To put this into a concrete example (highly simplified & using completely made up numbers; I have no idea what an actual vector value looks like), say a rotation of 0, 90, 0 ideally gets converted to a vector number of 29.05. However, in the conversion process it rounds it off to one decimal point (I know it wouldn’t take much more space to store two decimal points; I’m sure the actual vector numbers are much longer, thus making rounding more useful). So, it is now at 29.1. Lets say that a rotation of 0, 45, 0 would ideally get 29.02, but instead gets 29.0. The engine handles this fine, since the two are separated enough prior to the rounding. But lets say that a rotation of 90, 0 , 0 ideally gets 35.02, and 90, 45, 45 ideally gets 35.03. They would both end up witht he same rounded-off value: 35.0. This is what gives the engine headaches, as its unsure which to go with.
I don’t know all this for certain; I’m no engineer, mathematician, or programmer. This is just how I interpret what’s going on based on how I’ve heard the system works. I could be way off.
I’m also hopeful that the rotation is not only more stable, but more intuitive and user friendly. I hated in Reach how for example turning something on the X caused the Y and Z to rotate the object at weird, unexpected angles. You’d often end up needing to find a seemingly random combination of the three values to get what you really want.
One of the weirdest things I’ve noticed is that (at least with some objects) the closer X gets to 90, the more the Y and Z start to pretty much collapse together & become the same axis (ie, they start to fight each other, turning the object the same way).
For some reason, Reach just didn’t seem to like rotations on X.