ShadowSneaker on 31/3/2009 at 14:06
Why not just make new actors with shadow casting as default?
Ziemanskye on 31/3/2009 at 17:20
I think I can answer the question about why so many properties in an otherwise "empty" map. It's because of Garrett and the Inventory and all that stuff, they're all built as actors and things as well, so they get added into the map too.
Beleg Cúthalion on 31/3/2009 at 18:40
But not the patrol point or AI disposition properties. :weird:
This shadow casting things would be a lot of work and probably doesn't help much anyway. Plus, it would make my actor browser/gamesys completely unusable. :eww: I'll see if I can juggle the PSC until the mission's ready. I'm already glad that the ambient music properties carried no weight.
str8g8 on 3/4/2009 at 12:54
If I understand it correctly, adding and then removing an actor can result in empty, unused slots in the same way as a hard disk gets fragmented. Frame might refer to a fragment of memory. Unfortunately, there is no defrag tool for T4Ed :(
What about Harwin's suggestions of stripping down the gamesys? You would have to be very careful about this, but there must be a lot of junk, plus stuff that you know you won't use that could be safely removed?
Beleg Cúthalion on 4/4/2009 at 07:30
There's not even a defrag tool for T3Ed. :p Seriously, I have thought about the very same thing... except of course that I don't even know for sure that it's exactly this kind of fragmentation.
Does anyone know which actors in the GameSys can be deleted without problems? If it's not completely a matter of individual taste I'd suggest we write a sort of guide/wiki entry about it. I've added a Lord Julian to my map this week (I'll see if he talks too much), just because it appeared to be the only bearded noble without the civillian faction model... anyway, long story short: I fear we/I cannot simply delete even those very TDS-specific elements. On the other hand I have no idea what remaining parts of the GameSys could be deleted. :erg:
ShadowSneaker on 4/4/2009 at 11:22
Quote Posted by Ziemanskye
It's because of Garrett and the Inventory and all that stuff, they're all built as actors and things as well, so they get added into the map too.
I thought the properties only counted if you added them to an existing actor like giving a static mesh the frob, highlight distance and IsJunk properties so you can pick it up, for example. Or changing light colour and radius on a torch. There is a post where the guy that mentions the PSC stresses that it is only added properties that contribute to it.
Quote:
Plus, it would make my actor browser/gamesys completely unusable.
In what way? I've made loads of changes to mine.
What is the benefit of deleting actors from the gamesys? If they are not in your map then what effect could they possibly be having on it?
Ziemanskye on 4/4/2009 at 13:17
/shrugs
I could easily be wrong about this - I've never ran into the property limits, but I would guess that Garrett and the map-specific stuff might get added everytime because they're something that the game sort of adds into the level to make it work.
Um, I mean that in the sense that if the level itself gets baked down and contains all the stuff that was edited in, you still have to add a PlayerGarrett at the Startpoint, because we put the latter into the map file, not the former. And some of the level properties might be similarly added in later as needed, like which way is north, what day it is (I think that gets tracked with a GlobalInt, but still, I guess it goes on with some script as the level starts to run) And so on.
It was just a guess, really, but it seemed like a reasonable one to me.
Judith on 4/4/2009 at 13:29
Ironically, the best method for making maps in T3ed is the wrong one, level design-wise, i.e. making location after location, adding details in each spot on the fly, while having some plans laid out, but on a paper only.
When you have the default values in User.ini and you hit your first vertex/shadow vertex / some other limit, you know you have to think about making a transition to the next part of the map, while still having some room for details, without pushing the engine to its limits, and that's it.
Beleg Cúthalion on 24/5/2009 at 11:09
Since apparently even a mission within the property limits might still not work (that is: save) properly, I thought about writing PMs to all the guys who have created any patch programs (ibt patcher etc.) or other stuff for T3Ed or anything else related to TDS to ask if they think it would be possible to alter an unr file to re-sort/defrag the properties of each object. In a hex editor the file looks like this:
(
http://s11b.directupload.net/file/d/1803/6re6lhj5_png.htm)
Inline Image:
http://s11b.directupload.net/images/090523/temp/6re6lhj5.png (screen shot made by Stoker)
I have no clue about programming but the existance of an ibt shrinker which changes texture links or deletes them (or whatever) makes me hope this could be possible at least theoretically. I have about 11,000 "used but freed" properties right now and I'd like to have them completely free again to allow saving or maybe even add all necessary detail to my map. :erg:
ShadowSneaker on 24/5/2009 at 14:23
Have you tried copy & pasting the whole mission into another map to see if the "used but free" properties are carried over like Flux suggested?
