David on 29/10/2004 at 14:11
Not so much bugs, but quirks and things you need to remember.
#1 When T3ed crashes (not a Viktoria error, but when it just disapears) you need to manually quit T3.exe from the task manager or it'll give you the same message as starting T3ed.exe "You must start the editor from T3.exe with the "editor" commandline" or similar.
#2 Cannot add any of the "Rope" objects as the "skeletal mesh" is missing - to be expected if the rope arrows have been totally eradicated.
Gingerbread Man on 29/10/2004 at 20:12
* bIsOnFire didn't seem to work when added to a Puppet.
(bad luck, but I wasn't really expecting it to work -- just wanted to SEE)
:D
* unselected meshwork disappears in preview window when camera position is moved. Selected meshwork doesn't. Is this usual? (edit: Okay, this doesn't happen when in FleshRenderer...)
Harwin on 29/10/2004 at 21:16
Quote:
unselected meshwork disappears in preview window when camera position is moved. Selected meshwork doesn't. Is this usual? (edit: Okay, this doesn't happen when in FleshRenderer...)
IIRC, Performance optimization. I'm trying to recall if there's an option to turn that off in the Unreal view. I don't have easy access to a copy of the editor right now (poor planning on my part), but I'll see if I can get one so that I can check some of these things.
--Alex
ETA: Quote tag...
Harwin on 2/11/2004 at 03:53
Just thought I'd add a word of warning about properties... from a technical perspective
For performance and memory reasons, we have an internal unbreakable hard-cap of 65535 property values (that's values on a particular archetype or instance, as the result of an "add"). A level that exceeds this cap will NOT OPEN, even in the editor. So we cut it down to about 61440 (0xF000), to allow us to build a local version with the slightly higher cap and open the level and fix it.
You don't have that luxury, since we're not going back and forth between versions. I'll see about bumping it up a bit back to 65535, but you're still going to have that danger.
So here's a preventative suggestion:
In the game, the used property count is higher than in the editor (some properties get instantiated onto instances when the game starts up). Therefore there are some levels that will work in the editor but fail in the game. This gives you time to fix them in the editor.
And here's the way to recover a level that no longer even works in the editor:
This is probably only going to happen if you get a new gamesys (you shouldn't be able to get the level in a state where it has too many properties within an editor session without it crashing (and therefore not saving it in the state). So either revert to the older one, or *carefully* remove some extraneous objects from a gamesys you're using, and open your level and fix it using the new gamesys, then go back.
(Also, if you really want to make a level that exceeds the count with the official Thief: Deadly Shadows gamesys, you're going to have to ship a stripped gamesys with it)
--Alex
Gingerbread Man on 2/11/2004 at 04:02
So, that's 65535 (or 61440) ADDED Property values? What's the way to keep track of that?
Harwin on 2/11/2004 at 04:13
Quote Posted by Gingerbread Man
So, that's 65535 (or 61440) ADDED Property values? What's the way to keep track of that?
ADDED, yes, remembering that you're already paying for some of them. To track them, try...
DUMPINTERNALPROPINFO
Total is your current max. "Total + Used But Freed" is the highest count you've ever gotten to (deleted properties take up space until the next frame). The sum of the two can't go above the cap.
Although... that command may only print to an attached debug window... not sure if it prints to the log. You could find out :)
--Alex
Edit:
Sigh, finally got what I needed to get my copy of the patch up and running. It doesn't appear to output to the log file. So... right now you'd need to attach to it with a debugger like Microsoft Visual Studio or something. I'll think about fixing this one, at least for the editor, since I'm going to have to recompile that anyway for the other fixes.
Gingerbread Man on 4/11/2004 at 02:19
Two small notes:
1) Returning to T3Ed from game mode requires at least a basic geometry rebuild before the 3d viewport realtime panning etc works properly.
2) Sometimes the delete key won't remove things, so it's necessary to right-click the mesh (for instance) to pull up a delete option from there.
Plus one extremely minor thing: Although the viewport content preferences are saved on exit (I like to have UEd running 3d / t / f / s clockwise from upper left... I've never been able to handle a bottom-left 3d view in any engine), the grid size and viewport positions reset themselves. No big deal, as changing the grid is hardly a chore, but floating / resizing / fixing the viewports is a bit tedious. But, like I say, it's extremely minor and probably only bothering me and my idiosyncrasies.
David on 23/2/2005 at 23:51
bump!
Beleg Cúthalion on 2/1/2009 at 19:54
I'm just moving this out of the newbie thread:
Quote Posted by Flux
Beleg, before jumping any conclusion, I want to understand what is the problem exactly. I'll be happy to poke around your unr file tonight if you wish, just pm me.
That thread you linked is about arhcetypes, nothing about shadow/lighting bsp etc. "size" limits.
There are still, I believe, lots of myths going around the what the engine is capable of "size"...
How many ai you have, how many dynamic lights you have? The number of zones? Number of new custom classes?
Heh, I'd really love to overcome this, but I've already planned to get rid of a couple of unimportant streets in the worst case. My vertex pools are OK, my zones also (app. 190 and thus far away from 1023), my gamesys is yours from valley times (i.e. with two inventory books, the level entry actors plus mine and maybe something by you which I haven't found yet), everything else works. OK, left aside the saving issue with the GL-ready mission.
I could play it until I designed the little storage room in the inn you can see in the last picture I posted (glad you like it, by the way :)). After that, it refused to load (crash shortly after entering game mode, just one frame or so, as if the pools were exceeded) and neither increasing the pools nor re-booting did help. Once I got a Viktoria error after loading it in T3Ed telling me about the property storage count. I've saved a testing version of the current map and randomly deleted lots of static meshes - as well as some crucial path points that might have been the cause - and somewhen it worked again. Now I'm trying to find out if deleting the shadowcasting property at certain static meshes will suffice to reduce this property storage count, otherwise I'll just replace them with fresh ones. However, I haven't found anything in the editor files indicating that this thing is easily changed and Harwin's posts don't hint that. I'm trying to get the FM running in debug mode again so I can try the DUMPINTERNALPROPINFO command.
Edit: I believe I wasted a lot of properties by copying NavMesh subtraction volumes and changing the properties all the time. Re-working everything shouldn't be a problem if my wrap builder brush command wasn't so unuseable. :(
Edit2: I finally found the dump(ed) property list in T3Main.log. Here we go:
Code:
Total Number of Properties Stored: 53817 [ 450057] (.\PropSysInternals.cpp : 257)
Used But Freed: 7338 [ 450057] (.\PropSysInternals.cpp : 261)
Property Tag : 10344 [ 450057] (.\PropSysInternals.cpp : 271)
Property Touching : 9117 [ 450102] (.\PropSysInternals.cpp : 271)
Property StaticMesh : 8474 [ 450125] (.\PropSysInternals.cpp : 271)
Property ObjectMesh : 7395 [ 450164] (.\PropSysInternals.cpp : 271)
Property bHidden : 2808 [ 450332] (.\PropSysInternals.cpp : 271)
Property CollisionFlags : 766 [ 450407] (.\PropSysInternals.cpp : 271)
Property CastShadows : 728 [ 450409] (.\PropSysInternals.cpp : 271)
Property CanSubdivideNavMesh : 537 [ 450416] (.\PropSysInternals.cpp : 271)
Property DrawScale : 466 [ 450419] (.\PropSysInternals.cpp : 271)
Property Culprit : 457 [ 450419] (.\PropSysInternals.cpp : 271)
Property HealthState : 372 [ 450422] (.\PropSysInternals.cpp : 271)
Property TriggerScripts : 295 [ 450425] (.\PropSysInternals.cpp : 271)
Property RenderType : 210 [ 450428] (.\PropSysInternals.cpp : 271)
Property LightShape : 175 [ 450430] (.\PropSysInternals.cpp : 271)
Property LightColor : 153 [ 450431] (.\PropSysInternals.cpp : 271)
Property ContactResponse : 144 [ 450431] (.\PropSysInternals.cpp : 271)
Property bHideDontDestroy : 128 [ 450432] (.\PropSysInternals.cpp : 271)
Property PrePivot : 118 [ 450432] (.\PropSysInternals.cpp : 271)
Property MassPounds : 118 [ 450432] (.\PropSysInternals.cpp : 271)
Property OrderInSequence : 111 [ 450432] (.\PropSysInternals.cpp : 271)
Property Disposition_vs_Player : 104 [ 450433] (.\PropSysInternals.cpp : 271)
Property Disposition_vs_Faction0 : 103 [ 450433] (.\PropSysInternals.cpp : 271)
Property AddSurfacesToNavMesh : 99 [ 450433] (.\PropSysInternals.cpp : 271)
Property FactionGUID : 97 [ 450433] (.\PropSysInternals.cpp : 271)
As you can see CastShadows is the most often used property I am (partly?) responsible for. I'm just trying to delete some properties and see if the values change (light color for instance, I messed around with that before finding light radius).
Edit 3: After deleting one ShadowExtrusionDistance entry at a street lamp the first two lines changed to:
Code:
Total Number of Properties Stored: 53661 [ 361840] (.\PropSysInternals.cpp : 257)
Used But Freed: 7493 [ 361840] (.\PropSysInternals.cpp : 261)
Now someone please explain me that. :erg: After all, it helps to keep track of it.
Edit 4: Apparently I also wasted a lot of properties when I tried to undo the evil consequences of navmesh-subdividing properties among my already placed SMeshes. I'm trying to replace the SMs in question as I move along with final decoration. This and deleting properties works to reduce the propcount as I just found out. Or believe I did. The advice for everyone here would be to take care that no objects with messed-up properties remain in the map.
Beleg Cúthalion on 15/1/2009 at 22:00
One bump for my edits and for this here:
I'm running out of ideas. I'm trying to continue with the mission design but from time to time I have to stop (when the game starts crashing due to the property count) and delete/change app. four times as many objects as I had put into the map before. I've just played around with a test map to see how the property count behaves after certain steps which I have already tried out to decrease it. The object in question is a bookcase with shadow casting at the beginning.
Total properties: 8170
Used but Freed: 749After deleting the shadow casting property it reads like this:
Total: 8161
UbF: 757It somehow makes sense; the total number is decreased but the number of already used "slots" (?) in of course higher.
After adding shadowcasting a second time we have this:
Total: 8172
UbF: 747Now it's getting weirder. It looks like the new property (although being only one property) used both second-hand slots and increased the total property count.
Deleting the bookcase now results in this:
Total: 8175 (higher!)
UbF: 738 (lower although there should be new second-hand slots AFAIK).
Putting in a new one and adding shadow casting makes this:
Total: 8143 (decreased, as if.. well, I don't know)
UbF: 775 (increased for no reason I can think of)
Replacing it with a vanilla bookcase from the browser (and thus without shadow casting) results in this:
Total: 8161
UbF: 756 :weird:
Does anyone have an idea of how this thing stores and replaces/deletes these property slots? Does anyone know what Harwin meant with "frame"?
Quote:
(deleted properties take up space until the next frame
I'm far away from being a computer expert so I have no idea how these things usually work.
