nicked on 1/3/2020 at 17:48
I've run out of obj IDs. It's set to the max (8184) and now I'm getting
Object count dangerously high(8192 of 8192). Be very very careful.
ASSERT: [objsys.cpp@401] Ran out of concrete obj ID's
Re-run with a larger obj_max.
ASSERT: [prophash.h@228] obj != OBJ_NULL
Anything I can do here, or am I just going to have to start deleting things? Also, am I safe to fix the mission if I'm already seeing this error, or should I revert to a backup from before I ran out?
FireMage on 1/3/2020 at 18:44
Errr... That stinks...
When you are close to the limit, you will first start to have issues like objects which don't delete themselves, AIs becoming invulnerable, arrows that don't shoot, rope arrows which never go back to your inventory but delete their ropes and obviously, a crash after a few minutes of playing.
So when the console says you have to be careful, it means you should make sure the map won't have many objects spawned or shot... so make sure your obj limit is set correctly within the compatible NewDark's limits and spare as many objects as you could. This limit can be set with Dark.cfg (of FM.cfg if you don't want to modify player's games too much).
obj_min -6144
obj_max 8000
max_refs 32768
Is a good deal.
You should be careful with your achetypes and then schemas as well. Since the obj limit counts both archetypes and in-game objects
nicked on 1/3/2020 at 18:57
Archetypes I've no issue with (as far as I can tell there's no limit on obj_min, only obj_max).
I don't have much that is spawned on the fly ingame, mostly just teleporting stuff from blue rooms. I do have a lot of random trees, bushes etc. I think they will have to go. Hopefully I can get it low enough to not cause problems.
I was wondering why it was complaining when my object count is only just over 8000, but if it's counting everything spawned in ingame, that would explain it.
nicked on 1/3/2020 at 19:46
I think I may need to revert to a backed up version. Even after deleting hundreds of miscellaneous objects, the monolog is still spewing:
ASSERT: [OBJLIGHT.C@367] gMaxObjID < HACK_MAX_OBJ
Is there any way of "defragging" object IDs to make sure all slots are filled in order?
DirkBogan on 1/3/2020 at 20:07
The command 'compress_br_ids' should be happening when you optimize (assuming you're using more recent builds of DromEd with modern .cmds), but you can try doing it manually.
I'd also like to suggest higher safe values for dark.cfg than FireMage's proposal:
obj_min -18192
obj_max 8184
max_refs 65000
A few recent FMs that really push the limits have used these successfully. However, any larger positive or negative values for obj_min/max are almost sure not to work. obj_max 8192 is known to be unstable.
john9818a on 2/3/2020 at 05:15
One thing you can do is use existing objects for your conversation markers, relay traps, etc as long as those objects don't already respond to On or Off signals.
I'll usually use a chair or a pipe as a conversation marker.
nicked on 2/3/2020 at 07:35
Yeah, there's a few things I can do to reduce the number of objects. I'm still going to have to reduce the scope of the mission from the original plan.
I'm still getting errors, so I think the best bet is to bite the bullet, throw out the current version, roll back to a version before I started placing guards and patrol routes, clean up the object count to begin with, and then try to use less TrolPts for AIs.
Christine on 2/3/2020 at 09:48
you could also group some objects in Anim-8or/Blender to one object. Fibanocci did this with some bushes, I used it in RavenCreek: 4 bushes together in one object.
nicked on 3/3/2020 at 17:51
Yeah that's definitely a viable option. There are a few places I could swap a bunch of objects for 1 mega object
Nameless Voice on 6/3/2020 at 23:01
There was an experimental script in NVScript, written for CoSaS Mission X, called NVFreePatrol.
It used a set of NVFreePatrolPoint# params to describe a patrol route, without needing patrol markers.
Each param is a location in the format "0.00, 0.00, 0.00". Something like NVFreePatrolPoint0="35.00, 200.00, 80.00"; NVFreePatrolPoint1="135.00, 200.00, 80.00".
I believe it goes on the AI.
I don't remember if it actually worked or if it was even used in MX.
It seems to check if it's near any of the up-to-100 patrol points once a second, which strikes me as highly inefficient code.
