For direct access use https://forums.oldunreal.com
It's been quite a while since oldunreal had an overhaul, but we are moving to another server which require some updates and changes. The biggest change is the migration of our old reliable YaBB forum to phpBB. This system expects you to login with your username and old password known from YaBB.
If you experience any problems there is also the usual "password forgotten" function. Don't forget to clear your browser cache!
If you have any further concerns feel free to contact me: Smirftsch@oldunreal.com
It's been quite a while since oldunreal had an overhaul, but we are moving to another server which require some updates and changes. The biggest change is the migration of our old reliable YaBB forum to phpBB. This system expects you to login with your username and old password known from YaBB.
If you experience any problems there is also the usual "password forgotten" function. Don't forget to clear your browser cache!
If you have any further concerns feel free to contact me: Smirftsch@oldunreal.com
Mover bug
- Reorn
- OldUnreal Member
- Posts: 7
- Joined: Sun Jan 06, 2019 7:51 pm
- Reorn
- OldUnreal Member
- Posts: 7
- Joined: Sun Jan 06, 2019 7:51 pm
Re: Mover bug
I found these bugs many years ago, in old versions of Unreal on old computers, and I was surprised to learn that in 227i these bugs not fixed...
I'm interested in reason for this bug... and way to fix it.
Right way, not random rebuilds with random results.
I'm interested in reason for this bug... and way to fix it.
Right way, not random rebuilds with random results.
Last edited by Reorn on Tue Apr 23, 2019 8:28 am, edited 1 time in total.
- Hellkeeper
- Global Moderator
- Posts: 3260
- Joined: Wed May 21, 2008 8:24 pm
- Location: France
- Contact:
Re: Mover bug
These problems come from the geometry of the map themselves. The huge door of the cargo bay of the ISV-Kran in the map Trench.unr is the most flagrant instance of this issue.
In other word, they are not display bugs (fixable by changing renderer or the renderer's parameters) as much as map design bugs (which are embedded in the map's polygons themselves). Since they come from the way the map was built, they cannot be fixed except by changing the geometry itself. This means changing the map ever so slightly and creating compatibility problems down the line. Considering this, in order to provide full compatibility, patch 227 does not fix them and they cannot be fixed except by doing exactly what you want to avoid: random rebuilds.
The reason behind them is that movers are very unstable in UE1 and the bigger, the more complex they are, the more they are prone to have polygons go invisible, either in all cases or in certain positions or from certain viewpoints.
In other word, they are not display bugs (fixable by changing renderer or the renderer's parameters) as much as map design bugs (which are embedded in the map's polygons themselves). Since they come from the way the map was built, they cannot be fixed except by changing the geometry itself. This means changing the map ever so slightly and creating compatibility problems down the line. Considering this, in order to provide full compatibility, patch 227 does not fix them and they cannot be fixed except by doing exactly what you want to avoid: random rebuilds.
The reason behind them is that movers are very unstable in UE1 and the bigger, the more complex they are, the more they are prone to have polygons go invisible, either in all cases or in certain positions or from certain viewpoints.
You must construct additional pylons.
- Masterkent
- OldUnreal Member
- Posts: 1469
- Joined: Fri Apr 05, 2013 12:41 pm
Re: Mover bug
I presume, we could blame the rendering implementation for such glitches too. It seems, it uses a very unreliable optimization which reduces the set of surfaces that are considered as potentially visible (for the given viewer at the given moment). Exclusion of surfaces that cannot be seen under the given circumstances helps to improve performance, but if the implementation erroneously treats observable surfaces as currently invisible to the viewer, it might be better to choose a slower but correct and reliable method instead. E.g., a particular troublesome mover could be marked as always fully exposed to the viewer.In other word, they are not display bugs (fixable by changing renderer or the renderer's parameters) as much as map design bugs (which are embedded in the map's polygons themselves).
If it can be done by tweaking the filtering of invisible surfaces, changing the mover's geometry data would not be needed.Since they come from the way the map was built, they cannot be fixed except by changing the geometry itself.
Technically, objects inside a map can be altered externally without any impact on compatibility. It's only a matter of time and programming skills of devs who have the native source code. If the C++ sources were available to public, glitches like that could have been fixed many years ago...This means changing the map ever so slightly and creating compatibility problems down the line. Considering this, in order to provide full compatibility, patch 227 does not fix them and they cannot be fixed except by doing exactly what you want to avoid: random rebuilds.
- Hellkeeper
- Global Moderator
- Posts: 3260
- Joined: Wed May 21, 2008 8:24 pm
- Location: France
- Contact:
Re: Mover bug
Thanks for the technical insight. I'm parroting the usual speech about BSP bugs in stock maps.
The renderer's failing is probably to blame, yet there are cases where modifying the mover fixes this kind of issues, which leads me to believe geometry is also at fault, if only in so far as it causes bad rendering.
The cargo door in trench is an ancient bug. If what you say is true, and I have no reason to doubt it is, then it should probably have been fixed ages ago. The fact it has not been surely attests it is not an easy task.
Still, notwithstanding mismatch problems, the easiest way would, I believe, be a slight modification of the map and a good rebuild?
The renderer's failing is probably to blame, yet there are cases where modifying the mover fixes this kind of issues, which leads me to believe geometry is also at fault, if only in so far as it causes bad rendering.
The cargo door in trench is an ancient bug. If what you say is true, and I have no reason to doubt it is, then it should probably have been fixed ages ago. The fact it has not been surely attests it is not an easy task.
Still, notwithstanding mismatch problems, the easiest way would, I believe, be a slight modification of the map and a good rebuild?
You must construct additional pylons.
- Reorn
- OldUnreal Member
- Posts: 7
- Joined: Sun Jan 06, 2019 7:51 pm
Re: Mover bug
Thank you very much.
Glitches on BSP and movers may disappear, but reappear on next rebuild...
No RELIABLE way for correct visual errors, if level too complicated.
Only "method of trial and error".
This is builder/renderer problem, and big problem for mappers, on complicated user maps.....
Small modification and rebuild has random result.I believe, be a slight modification of the map and a good rebuild?
Glitches on BSP and movers may disappear, but reappear on next rebuild...
No RELIABLE way for correct visual errors, if level too complicated.
Only "method of trial and error".
This is builder/renderer problem, and big problem for mappers, on complicated user maps.....
Last edited by Reorn on Wed Apr 24, 2019 2:24 am, edited 1 time in total.
- Masterkent
- OldUnreal Member
- Posts: 1469
- Joined: Fri Apr 05, 2013 12:41 pm
Re: Mover bug
A good implementation of hidden-surface removal should correctly handle _any_ geometry, unless the geometry data is initially corrupt. If the editing tools produce a corrupt data, then we should blame the editing tools. In general, it's possible to build a BSP tree and apply the resulting binary space partitioning so that non-hidden surfaces won't be ever erroneosly removed as hidden. The question is how Epic's devs implemented the construction of BSP trees and the hidden-surface removal based on such trees. I suspect that either part or both may have errors. They didn't properly implement even much more simple things like replication of mover's movement in online game. F.e., I hardly understand how someone could think thatThe renderer's failing is probably to blame, yet there are cases where modifying the mover fixes this kind of issues, which leads me to believe geometry is also at fault, if only in so far as it causes bad rendering.
Code: Select all
SimInterpolate.Y = 100 * FMax(0.01, PhysRate);
The problem is that there are no people who would be able to fix such bugs properly. Probably, many talented programmers could try to find a good solution for the given issue, but they simply have no access to the relevant source code.If what you say is true, and I have no reason to doubt it is, then it should probably have been fixed ages ago.
Considering the current possibilities, I think that leaving everything as is would be the best option (although the issue most likely can be fixed in theory, in practice we don't have devs with access to the relevant source code, a sufficient level of programming skills, and a sufficient amount of free time in order to implement appropriate modifications without introducing 10 new bugs instead).Still, notwithstanding mismatch problems, the easiest way would, I believe, be a slight modification of the map and a good rebuild?
Last edited by Masterkent on Wed Apr 24, 2019 11:15 am, edited 1 time in total.
- Reorn
- OldUnreal Member
- Posts: 7
- Joined: Sun Jan 06, 2019 7:51 pm
Re: Mover bug
I replace these movers to static meshes (attached to invisible movers) and have no visual glitch.
Problem is solved.
But this had raised the question:
may I draw mover as static mesh (in trial, this method not works),
or only attach static mesh to mover (this method works )?
Problem is solved.
But this had raised the question:
may I draw mover as static mesh (in trial, this method not works),
or only attach static mesh to mover (this method works )?
Last edited by Reorn on Wed Apr 24, 2019 9:52 pm, edited 1 time in total.
- Krull0r
- Global Moderator
- Posts: 543
- Joined: Sun Jul 01, 2007 4:07 pm
Re: Mover bug
Hello
No need to attach static meshes on movers. You can simply select any mesh in your meshbrowser and right click on the "add mover" button in your toolbar,
There you can select different types of movers and each type has a mesh veriations.
No need to attach static meshes on movers. You can simply select any mesh in your meshbrowser and right click on the "add mover" button in your toolbar,
There you can select different types of movers and each type has a mesh veriations.
- Reorn
- OldUnreal Member
- Posts: 7
- Joined: Sun Jan 06, 2019 7:51 pm
Re: Mover bug
Thank you very much.Hello
No need to attach static meshes on movers. You can simply select any mesh in your meshbrowser and right click on the "add mover" button in your toolbar,
There you can select different types of movers and each type has a mesh veriations.
It was working well.
- Masterkent
- OldUnreal Member
- Posts: 1469
- Joined: Fri Apr 05, 2013 12:41 pm
Re: Mover bug
Meshes (especially big ones) aren't properly lit by dynamic lighting (when a light is emitted by explosions, flashlight, etc). Besides, hacking the standard maps this way probably won't let you play on existing Coop game servers without troubles.
- Reorn
- OldUnreal Member
- Posts: 7
- Joined: Sun Jan 06, 2019 7:51 pm
Re: Mover bug
Thenk You.
but I was wondering ways to fix visual glitches, not a certain maps.
UnrealEd have many build/optimisation/visualisation glitches, and no tuturial for bug fixes. I discovered, that version 227 more stable, than previous, but remain a some errors.
That's bad.Meshes (especially big ones) aren't properly lit by dynamic lighting (when a light is emitted by explosions, flashlight, etc).
Nothing prevents have copies of standard maps (or Unreal) for internet game.Besides, hacking the standard maps this way probably won't let you play on existing Coop game servers without troubles.
but I was wondering ways to fix visual glitches, not a certain maps.
UnrealEd have many build/optimisation/visualisation glitches, and no tuturial for bug fixes. I discovered, that version 227 more stable, than previous, but remain a some errors.
Last edited by Reorn on Thu Apr 25, 2019 10:41 am, edited 1 time in total.
- )Leela(-[otS]-
- OldUnreal Member
- Posts: 205
- Joined: Tue May 31, 2011 7:30 pm
Re: Mover bug
Hi
These problems exist in many maps and sometimes costed me some headaches. In some cases making a new mover solved the issue. In other cases a simple small movement of the mover fixed it and there were also some which I couldn't fix at all.
But there is one common thing which I noticed over the years. The problem always occurs as a result of the interaction between two movers. For example Mover A starts to move and everything looks fine. Then Mover B starts to move and suddenly parts of Mover A or even the whole Mover becomes invisible or flicker at least.
I've never seen, that this also would happen to a single mover.
These problems exist in many maps and sometimes costed me some headaches. In some cases making a new mover solved the issue. In other cases a simple small movement of the mover fixed it and there were also some which I couldn't fix at all.
But there is one common thing which I noticed over the years. The problem always occurs as a result of the interaction between two movers. For example Mover A starts to move and everything looks fine. Then Mover B starts to move and suddenly parts of Mover A or even the whole Mover becomes invisible or flicker at least.
I've never seen, that this also would happen to a single mover.
- TONI-M
- OldUnreal Member
- Posts: 136
- Joined: Thu Mar 14, 2019 12:19 pm
Re: Mover bug
I have also seen other problems:
after the flicker the mover remains partially devoid of texture, black or disappears at all
It occurs if you apply so many changes to the environment, such as to improve it.
I can't explain it better, because the translator doesn't translate well. I am Italian
Hi everyone
after the flicker the mover remains partially devoid of texture, black or disappears at all
It occurs if you apply so many changes to the environment, such as to improve it.
I can't explain it better, because the translator doesn't translate well. I am Italian
Hi everyone
- TONI-M
- OldUnreal Member
- Posts: 136
- Joined: Thu Mar 14, 2019 12:19 pm
Re: Mover bug
I advise you to be careful if you duplicate the same mover so many times, it can remain black. I created a prison, and found myself with all the black movers, and what was behind the mover looked black. transparent mover. prison door.
- Buster
- Global Moderator
- Posts: 1610
- Joined: Wed Jun 08, 2005 3:02 am
Re: Mover bug
Create a studio (a large subtracted cube) off to the side in the map you're working on. Put a light source all around the cube, so the center is lit from all six directions. Make the mover here. And yes, try to avoid duplication. Make each mover, and do so in a well lit studio. It seems to help avoid problems. Sometimes, when a mover is touching a solid at its starting position, the surface touching it won't be lit. I have no clue how to prevent that from happening when it does. Try making a new mover from scratch, and don't get too frustrated when it happens again.
Gatherstone - Unreal by Design
https://gatherstone.oldunreal.com
OK - he falls
Keep it Unreal !!
:-)_~
https://gatherstone.oldunreal.com
OK - he falls
Keep it Unreal !!
:-)_~
- TONI-M
- OldUnreal Member
- Posts: 136
- Joined: Thu Mar 14, 2019 12:19 pm
Re: Mover bug
Dear Buster, it's weird ... because he can do it after loading a rescue and not before. Sometimes it stains everything with white, some remains black. From the wolf guide, I learned how to make bows
The level is called the temple on the peak ... With a monumental aquarium and a small artistic garden. a wonderful scale that I copied from the cemetery; considering that where I live there is a monumental cemetery, which to say the least the church of the level the city of heaven is only the beginning ... very beautiful but not like the one I saw. Ciao TONI-M
The level is called the temple on the peak ... With a monumental aquarium and a small artistic garden. a wonderful scale that I copied from the cemetery; considering that where I live there is a monumental cemetery, which to say the least the church of the level the city of heaven is only the beginning ... very beautiful but not like the one I saw. Ciao TONI-M
- TONI-M
- OldUnreal Member
- Posts: 136
- Joined: Thu Mar 14, 2019 12:19 pm
Re: Mover bug
Can I ask you a question? Does the error arise even if you create the mover by going through all the procedures?
I mean and not recovering it with >from polygons to brush?
I mean and not recovering it with >from polygons to brush?
- )Leela(-[otS]-
- OldUnreal Member
- Posts: 205
- Joined: Tue May 31, 2011 7:30 pm
Re: Mover bug
Hello
There is a possible fix for TheTrench without touching the geometry. This can be done in the map if it's not needed for online play, but could also be done with a mutator which can create and modify actors in a map.
As a compromise you need to alter the sequence of the gate a bit to make it work.
I list the steps here one by one.
1) Set the Event of Trigger8 to None (or disable it)
2) Set the Event of SkaarjWarrior3 to None
3) Modify Trigger0: Event=hatchcrtl, InitialState=OtherTriggerToggles
4) Modify Mover0: Tag=hatch2, MoveTime=8.005000
5) Modify Mover3: Tag=hatch2, MoveTime=8.005000
6) Modify Mover5: Tag=hatch2
7) Modify Mover7: Tag=hatch1, StayOpenTime=20.500000
Add a Dispatcher:
Tag=hatchcrtl
OutDelays[2]=14.500000
OutDelays[3]=34.500000
OutEvents[0]=ISVTrigger
OutEvents[1]=hatch1
OutEvents[2]=hatch2
OutEvents[3]=ISVTrigger
This makes sure, that the gate will run without errors. It's important, that Mover7 never runs together with Mover0 and Mover3.
There is a possible fix for TheTrench without touching the geometry. This can be done in the map if it's not needed for online play, but could also be done with a mutator which can create and modify actors in a map.
As a compromise you need to alter the sequence of the gate a bit to make it work.
I list the steps here one by one.
1) Set the Event of Trigger8 to None (or disable it)
2) Set the Event of SkaarjWarrior3 to None
3) Modify Trigger0: Event=hatchcrtl, InitialState=OtherTriggerToggles
4) Modify Mover0: Tag=hatch2, MoveTime=8.005000
5) Modify Mover3: Tag=hatch2, MoveTime=8.005000
6) Modify Mover5: Tag=hatch2
7) Modify Mover7: Tag=hatch1, StayOpenTime=20.500000
Add a Dispatcher:
Tag=hatchcrtl
OutDelays[2]=14.500000
OutDelays[3]=34.500000
OutEvents[0]=ISVTrigger
OutEvents[1]=hatch1
OutEvents[2]=hatch2
OutEvents[3]=ISVTrigger
This makes sure, that the gate will run without errors. It's important, that Mover7 never runs together with Mover0 and Mover3.