nomad of the pacific on 23/8/2006 at 16:55
Quote:
ERROR: Exceeded maximum property storage count of 61440. Must raise the limit and recompile. [ 153223] (.\Viktoria\Viki_Errors.cpp : 662)
This limit killed Evicted.
str8g8 on 23/8/2006 at 17:22
Is that a maximum number of objects?
Ziemanskye on 23/8/2006 at 18:26
/shrugs.
I'd guess it's a maximum number of properties: like he set some new props in concretes and cloned it all over the level rather than creating new archetypes - so the extras get saved for each instance. Just guessing of course, but he's the only one confirmed to have hit it.
And if you notice NH's arguements have always included a "properly optimised" clause, which can include such ideas as taking things out because the detail level is too high.
Yes we can do TMA sized levels - really that shouldn't even be in contention. The problem is that people don't want TMA level of detail in their missions (at least not here, though even in the T1/2 Editor's Guild they rail against it). A cuboid bookcase, a single table and an 8-side cylinder of gold coins on the table is nowhere near enough any more.
New Horizon on 23/8/2006 at 19:18
Quote Posted by Ziemanskye
/shrugs.
And if you notice NH's arguements have always included a "properly optimised" clause, which can include such ideas as taking things out because the detail level is too high.
I only include the 'properly optimised' clause to dispell any crazy ideas that doom 3 can magically render something massive without properly designing it first. People will be in for a much smoother ride with the doom 3 engine, no bones about it...but it's best to learn good mapping practices right off the bat. A well designed and optimised map will run well on a wide variety of system specs...especially when you consider Doom 3 has 4 levels of detail that goes from butt ugly to drool worthy. There are plenty of ways to optimise your maps in Doom 3 and we've added to that ourselves. :) FM makers have more control over how the engine executes their maps...and this will lead to some great levels in the future. I won't go into a great
level of detail just yet, but once things are more finely tuned, we will likely talk about it. :)
ascottk on 23/8/2006 at 19:41
Same thing applies to audio. If you mix and master on a crappy pair of monitors it's only going to sound good on those monitors. The inverse could be true as well, have a high-end sound system and mix for that, it's going to sound crappy on a low-end system. Why do you think commercial recordings have a mastering process? The best mastering people get paid the big bucks because they have great monitoring systems & the best ears in the business. Ray Charles had those kind of ears (even better), he heard an unbalanced monitor before the mastering person did.
The trick is having a calibrated system. The same goes for crts & lcds. Macs generally are calibrated to gamma 1.8 & wintels are calibrated to 2.2 or somewhere. That's why so many people complain about whether or not a picture is too dark or bright because their monitors are not calibrated.
Where was I going with this? Proper mapping skills. How does that relate to calibration? Beta testing is a good way to find the balance between eye candy and performance. What works well on a high-end machine may not work well on a Dell/Gateway :laff: Then the mapper adjusts the level based on the beta tester feedback.
nomad of the pacific on 24/8/2006 at 04:38
Quote:
Originally posted by Harwin: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
I'm not sure how I killed Evicted. I didn't add any new archtypes that I can remember. (Maybe a couple.) Not many properties to the objects I used, either. Mostly stock stuff. Anyhow, the point is, there is a cap on what we can do with T3Ed, and it is deadly! Backup your level and gamesys regularly.
Ziemanskye on 24/8/2006 at 11:37
There's also a cap on BSP vertices we can't expand.
It killed my first FM way back.
Rantako on 24/8/2006 at 18:35
Quote:
I'm not sure how I killed Evicted. I didn't add any new archtypes that I can remember. (Maybe a couple.) Not many properties to the objects I used, either. Mostly stock stuff. Anyhow, the point is, there is a cap on what we can do with T3Ed, and it is deadly! Backup your level and gamesys regularly.
I'm guessing it was all the AIs - they come with a heap of properties on the concretes even if you don't add anything, and there were
a lot of AIs in Evicted
sparhawk on 29/8/2006 at 09:59
Quote Posted by Ziemanskye
But while I agree it's too early to nail them - are you considering setting such limits?
Why should we? The engine runs whatever it is capable of. Would limit TDS even further just to be able to have the occasional poeple still running a 266MHz PII loading your FM?
Quote Posted by str8g8
What are all these hard-coded limits everyone is talking about :confused:
It's limitations that are set by the developers and were also confirmed by them.
Quote:
Someone said you can't do T2 sized levels with the T3 Editor. It's my opinion that you can, and I would hate for some potential mapper to read that and be put off trying, because then it would become self-fulfilling.
I doubt that mappers wont try it just because they read it doesn't work. Simple fact is that it is not done because it doesn't work. Not because somebody read it doesn't work.
str8g8 on 29/8/2006 at 13:01
Quote:
Simple fact is that it is not done because it doesn't work.
We'll see. ;)
I think Ziemanskye hit the nail on the head when he said that the problem is people expect a T2 sized mission, BUT with a T3 level of detail.