Max range of robots?
#1
In Descent 1 level 25, large areas and long corridors exist. It seems the robots don't see you or don't act if you're at a long range.. was this intended?
Reply
#2
Does it work that way in Descent 1 v1.5 as released by Parallax? If yes, then yes, it is intended (even if it is not useful). If no, then it is a regression.
Reply
#3
I don't know about the original binary.. haven't run it in a long time.

Another weird issue is the collision behavior of fusion shots. In the screenshot, the bot can't hit me which just doesn't seem right.

BTW, there's a bug on the forum itself as well: Less than 1 minute ago">scrn0003.jpg for this screenshot.


Attached Files
.jpg   scrn0003.jpg (Size: 363.34 KB / Downloads: 9)
Reply
#4
Yep, these two behaviors are the same in the original MS-DOS game. Robots were always sluggish to react to far-away players. Even though that's probably unrealistic, if we made them more aggressive, many levels would unintentionally become very difficult. Wink As for the Fusion Cannon, it fires big projectiles with big hitboxes. This makes it easy to hit several robots with one shot, but the balancing factor is that the projectiles often clip the corners of walls and explode - which often happens to that Miniboss's projectiles.
Reply
#5
A fusion blast isn't really a projectile though is it?

One other strange thing I noticed: sometimes the reactor ignores you while you're clearly visible, while sometimes it just continues to fire at you though you're behind a wall..

There's also weird behavior related to save / load cycles, as if some vars aren't included in the save.
Reply
#6
All weapon fire are projectiles. Some of them just have graphics that make them look like vague blobs.

For the reactor, can you provide specific steps to reproduce? Identify an affected level, how to enter that state, etc.

Many variables are not included in the save. In my opinion, this is because save-sensitive data was added haphazardly without adequate consideration for what needed to be saved and what could be recomputed on load. Unfortunately, the save file format is very difficult to extend without breaking backward compatibility. It is not impossible to extend, but it is ugly, particularly for any polyinstantiated data (per-object, per-segment, per-wall, etc.). I have planned for a long time to completely replace this, but I have some other big projects in the queue ahead of it.
Reply


Forum Jump:


Users browsing this thread: 5 Guest(s)