Could pay attention to the use of ut99 cpu, I have the feeling that ut2k4 is a newer game with a heavier graphics, but it seems that the game runs smoother and less memory and cpu usage... (talking about server)
or it would just be empression?
What compiler version will be used for Linux builds? If a modern version is used, will it include a symbol level translation to support the existing native binaries built on ancient versions?
The engine is by nature wasting a lot of CPU cycles and memory. Maybe it's time to start working on a JIT compiler to take care of that sloppy code.
- Posts: 5193
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
If you're referring to the problem of mismatching packages in general, while there are potential strategies and workarounds I have personally thought for a very long time (outside of the patch), the person who may shed some light on that would be @anth himself, not me.
As far as the patch goes, I'm a mere tester for now like others, and I have not been a very good one lately (due to lack of time).
That's mainly because UT2004 got a lot of fixes and optimizations, especially in the field of graphics.
UT99 does all its graphics heavy-lifting on the CPU side, and then tells the GPU to draw one thing at a time, being the main reason for the poly-count limits and such, whereas UT2004 moved most of this heavy-lifting to the GPU, hence being able to render more polys and greatly reduce the load on the CPU side.
It's an effect of the hardware advancements that happened in those years: at the time of UT99, 3D hardware graphics were still a novelty to an extent, but by the time of UT2003/2004 they were already the norm for most 3D games.
No, as far as I know, which actually makes the version code in the package (69) to closely match the version label of the new patch (469), which is nice, but I can confirm for sure in the weekend (unless @anth confirms this before).
This first patch is mostly a bug-fix patch, with a lot of extra love given to UnrealEd to bring it up to speed with U227 UnrealEd (2.2) in terms of fixes all around (BSP, lighting, crashes), as well some extra tools and options that the OldUnreal version may not necessarily have (yet), but everything built there is still compatible with 436 (it has to be).
The idea is to keep both editors up to speed with one another, meaning that fixes in one may be ported to the other, and vice-versa, and there are currently fixes and addons in the new UnrealEd for UT which didn't (originally) exist in OldUnreal's UnrealEd, so both games will benefit a lot from this editor parity.
ABSOLUTELY Nothing will go screwed up if you fix those:
- JumpSpot and
- TranslocStart deals and also some love at
- WarpZoneMarker won't hurt anything and I can promise that no computer will explode in area, trust me. Not sure if hurts a check for "markedWarpZone"
Code: Select all
if (markedWarpZone != None) ...
These have a dedication for Bots without to check if another Pawn is roaming around, discarding any Human Paths Tester for no single reason.
Definitely JumpSpot should be FREE way for a Pawn with PHYS_Flying and all that Translocator specific craps definitely won't stop a Fly to navigate. Why not dealing with ALL possible Paths Seekers ?
But... maybe these are not a must-have after all... I can conform other stock adjusted for all requirements if these won't be fixed after releasing a public 469...
- Posts: 392
- Joined: Sun Mar 16, 2008 9:06 pm
- Personal rank: Brush Commander
- Location: inside ze bocks
- ShowPaths - we do have this
- ShowPrunedPaths - We Don't have this.
PathNode67 has a reachspec number 563 heading to PathNode54 - We don't have knowledge about it as a visual feature:
Code: Select all
Specs: PathNode67 - PrunedPaths=563 ->PathNode67 --->PathNode54 RFlags=Jump Walk =9 Dist=616 ShortcutConnected: PathNode67 to PathNode54.
- Posts: 1884
- Joined: Sat Sep 17, 2011 4:32 pm
- Personal rank: Dame. Vandora
- Location: TN, USA
What is there to fix on the vertical scroll bar?
Map loading issue has been handled fine in 469 if you wanna enroll in the betatesting program. Skins/mutators are not affected but those mutators are depending on their code of load.
Good idea - alternatives to that are to move the .int files to a folder off the UT paths or to simply comment out (;) those parts of the .int that are not required (this is particularly useful where an .int contains references to a number of mutators/gametypes/etc and some but not all are required to be kept).
With reference to UT 469 it would be useful if it incorporated the UT.log truncation feature of Higor's MiniLauncher as this can significantly reduce the size of the UT log.
- New hardcoded screenshot feature where the screenshot is compressed to png format and handled better than previous attempts, perhaps option to transfer it to custom website/location.
Make it hardcoded into the engine, and make ACE scan if it's hooked from outside - viola, clean games follow
And ofcause a prompt of what/if any personal information that gets logged on server OR shipped to 3rd party like ACE link to UnrealAdmin? Why does ACE resolve Unreal Admin and what data is send/recieved in that traffic? Admins and players needs to know EVERYTHING that goes on, a server admin is FULLY responsible for any data the server is gathering or shipping to 3rd party.