d1x crashes with too many special cubes
I'm not sure, whether this counts as a bug. For the work on an observatory-version of a level, I need a lot of reactor cubes to prevent the spawning of missiles purely for the entertainment of the observers. Now of course, it would be better if there were a way to tag cubes not to spawn. But, well.

The number of special cubes is limited to 50 (reactor cubes count against the limit and this has already been discussed here http://www.dxx-rebirth.com/frm/index.php...l#msg14890):

main/fuelcen.h:82 (retro and rebirth)
[tt]#define MAX_NUM_FUELCENS        50[/tt]

If you go over the limit with the design of a level, d1x-rebirth crashes with a segmentation fault

ddd shows this to happen in

main/fuelcen.c:168 (retro and rebirth)
[tt]Assert( Num_fuelcenters < MAX_NUM_FUELCENS );[/tt]

(At least I hope this is where the crash originates, I have only a very basic knowledge of programming.)

After changing the maximum to 500 it seems (rebirth and retro both compile), that everything is working fine. Apart from maybe allocating too much memory (?):

[tt]extern FuelCenter Station[MAX_NUM_FUELCENS];[/tt]
[tt]FuelCenter Station[MAX_NUM_FUELCENS];[/tt]

But I really do not have any idea as to any other consequences this minor change might result in.

Maybe someone competent might take a look at this?
For observatory levels there is more stable way to go around it rather than using reactor cubes. I mean its ok as long as you dont go too close to that limit. Rising the limit wont help since you would have to distribute custom , recompiled executables in order to play your level + there is no warranty it will be stable.
Keep all items (and start positions) in main fight area and have observation area separated by the walls at any point (leave entry as illusion wall or whatever) - that itself should prevent stuff from spawning in separated observation area. D2 behaves much better with this trick than D1 for some reason - at least thats what I've heard.
At least stuff really doesn't spawn up there in D2.
I would say that what you described isnt a bug but rather limitation. The method which I described above is kind of ... undocumented feature which can save level designers from frustration and depression... up to some degree. Wink
Descent level parsing is very fragile.  Exceeding built-in limits usually crashes it.  This will be somewhat improved in the next release, which is more aggressive about throwing exceptions when fed invalid input.  A later release may add appropriate catches to gracefully abandon the level load.
kp said everything true here. He's made quite a few changes and I think after that I can see and take a look which limts can safely be raised.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!

Forum Jump:

Users browsing this thread: 1 Guest(s)