Display posts from previous
Sort by

Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)

#382 by xhul
As promised...
I may have more to come later on, if i manage to unlock enough time.
Love =]

BUG|EXPLOIT REPORTS

> opening|closing doors just by moving
No idea if that was intented or not, so that's really just in case.
Open a door, walk past it, go left a bit until you get the button on your back and its icon visible, press walk-left, and the door will close.
If walk-left is already pressed before the icon appears, it doesn't work.
Only works when you have the button on your back, it seems.
EDIT :
As i suspected, this one is definitely related to the key mapping of the launcher, because the bug is gone if i use the default keys.
Basically, i use a french keyboard, so i had to remap horizontal- & vertical+ when i performed the tests (playing with ZQSD instead of WASD).
With this setup, horizontal- becomes partially interpreted as fire1 when interacting with a door button on your back, no idea why.

> look direction not resetted
Pretty sure you already know about that one, so that's another "just in case".
The variable used to store the coordinates of the direction in which you look isn't resetted when a new game starts.
For example, if you're facing the floor when you die or exit, you'll be facing the floor at the very start of a new game.

> 012 - chamber lighting
It seems that the red lighting inside 012's chamber goes past the ceiling, as you can see it from above (right before the chamber entrance).
No big deal, i could definitely live with that.

> 173 - kill through door
Aight, let's say 173 is right behind a door when i close it.
Once the door closed, i see a bit of his arm clipping through the door, but not enough to be afraid.
If i stay far away from the door and blink, 173 gets properly blocked by the door, and his position gets adjusted behind it, preventing further clipping.
Now, exact same scenario, but this time i blink right in front of the door : death.
The problem here is all about 173's proximity in the case he gets partially "doored".
You could fix that by reducing his kill range, or adding a piece of code that updates its position right when the door closes.

> elevator - 173 immunity
Basically, as long as you're inside an elevator, 173 is unable to move.
EDIT :
I think what is happening here is that 173 is simply behaving as if the door is closed, even if it's actually open.

> elevator - out of order
Don't panic, your elevators work well, but still, there's a way to break them permanently.
Enter the elevator, click the proper direction button to go to the other floor, the door closes, wait for the travel duration.
During the door opening (not before or after), simply press the direction button to go back.
At this point, the elevator will stay here forever, door open, and the 4 available buttons won't do anything.
video

> elevator - noclip exploit
The idea here is to enter the elevator, click the proper direction button, and exit it right before the door closes.
After that, the algorithm does what it's supposed to do : wait for the duration, and teleport you to the other floor.
But since you're actually out of the elevator, and the teleport coordinates are relative to the elevator, you can reach nasty spots by comparing the 2 floors.
video

> tesla - immunity exploit
Using 1499, you can permanently lock a gate in a state where it becomes harmless for the player.
In that state, its animation is always active, and its sound effect disabled.
video

PERFORMANCE FEEDBACK

I must say the game runs pretty well on my machine.
The only thing worth noting is that my FPS drop dramatically when a door opens or closes.
I'd say it probably has something to do with heavy conditional checks processed by the engine (pure intuition).
Let me know if you want more details about that.

SUGGESTIONS

Your port, your call =]

> faster stamina recovery when stationary
Something that was missing in the original aswell, and could add a bit of realism to the whole thing.

> walk/run shake effect
Currently, the sound effect feels a bit weird along with that linear view.

> elevator shake effect
Another touch to make the player believe the elevator is actually moving.
Last edited by xhul on Sun Mar 12, 2017 2:24 pm, edited 3 times in total.

Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)

#383 by zornor90
xhul wrote:As promised...
I may have more to come later on, if i manage to unlock enough time.
Love =]

BUG|EXPLOIT REPORTS

> opening|closing doors just by moving
No idea if that was intented or not, so that's really just in case.
Open a door, walk past it, go left a bit until you get the button on your back and its icon visible, press walk-left, and the door will close.
If walk-left is already pressed before the icon appears, it doesn't work.
Only works when you have the button on your back, it seems.

> look direction not resetted
Pretty sure you already know about that one, so that's another "just in case".
The variable used to store the coordinates of the direction in which you look isn't resetted when a new game starts.
For example, if you're facing the floor when you die or exit, you'll be facing the floor at the very start of a new game.

> 012 - chamber lighting
It seems that the red lighting inside 012's chamber goes past the ceiling, as you can see it from above (right before the chamber entrance).
No big deal, i could definitely live with that.

> 173 - kill through door
Aight, let's say 173 is right behind a door when i close it.
Once the door closed, i see a bit of his arm clipping through the door, but not enough to be afraid.
If i stay far away from the door and blink, 173 gets properly blocked by the door, and his position gets adjusted behind it, preventing further clipping.
Now, exact same scenario, but this time i blink right in front of the door : death.
The problem here is all about 173's proximity in the case he gets partially "doored".
You could fix that by reducing his kill range, or adding a piece of code that updates its position right when the door closes.

> elevator - 173 immunity
Basically, as long as you're inside an elevator, 173 is unable to move.

> elevator - out of order
Don't panic, your elevators work well, but still, there's a way to break them permanently.
Enter the elevator, click the proper direction button to go to the other floor, the door closes, wait for the travel duration.
During the door opening (not before or after), simply press the direction button to go back.
At this point, the elevator will stay here forever, door open, and the 4 available buttons won't do anything.
video

> elevator - noclip exploit
The idea here is to enter the elevator, click the proper direction button, and exit it right before the door closes.
After that, the algorithm does what it's supposed to do : wait for the duration, and teleport you to the other floor.
But since you're actually out of the elevator, and the teleport coordinates are relative to the elevator, you can reach nasty spots by comparing the 2 floors.
video

> tesla - immunity exploit
Using 1499, you can permanently lock a gate in a state where it becomes harmless for the player.
In that state, its animation is always active, and its sound effect disabled.
video

PERFORMANCE FEEDBACK

I must say the game runs pretty well on my machine.
The only thing worth noting is that my FPS drop dramatically when a door opens or closes.
I'd say it probably has something to do with heavy conditional checks processed by the engine (pure intuition).
Let me know if you want more details about that.

SUGGESTIONS

Your port, your call =]

> faster stamina recovery when stationary
Something that was missing in the original aswell, and could add a bit of realism to the whole thing.

> walk/run shake effect
Currently, the sound effect feels a bit weird along with that linear view.

> elevator shake effect
Another touch to make the player believe the elevator is actually moving.
Thanks so much, this is excellent feedback - I especially appreciate the videos. I will respond in further detail tomorrow once I'm able to look through and see what caused these

Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)

#386 by zornor90
Zackonark wrote:Hey everyone!

been a while, but hey! Progress!

[youtube]L6tBAGtqkYc[/youtube]
Hey man! Thanks for doing that playthrough! It is so helpful to see people actually playing the game

Some good feedback / questions:
1) Out of curiosity, which graphics setting were you playing on (Fastest, Fast, Good, etc) and which resolution? As there were no shadows. I need to tweak the quality settings so that there is one fast setting with shadows, and one fast setting without.
2) I'll have to increase the time in the airlock so people don't feel as rushed
3) I'll overload the function for give_item so that it gives one by default if no amount is specified, it was good to see you try to figure that out because I wasn't sure if it would be intuitive
4) Also the tesla gate killing you way after the burst is fixed now
5) The current version of the pathfinding engine just has 173 stand still when he can't reach the player, but I plan on adding some random behaviors so that he's moving around, trying to press buttons, etc. I'll also be fixing it so that you can't see 173 turn when doors are opening. Dynamic obstacles like doors add a whole 'nother level of programming difficulty

You'll also be excited to know that I'm (finally) going to have your room in in the next build, which will focus on NPCs, events, and rooms

Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)

#387 by zornor90
xhul wrote: > opening|closing doors just by moving
No idea if that was intented or not, so that's really just in case.
Open a door, walk past it, go left a bit until you get the button on your back and its icon visible, press walk-left, and the door will close.
If walk-left is already pressed before the icon appears, it doesn't work.
Only works when you have the button on your back, it seems.
EDIT :
As i suspected, this one is definitely related to the key mapping of the launcher, because the bug is gone if i use the default keys.
Basically, i use a french keyboard, so i had to remap horizontal- & vertical+ when i performed the tests (playing with ZQSD instead of WASD).
With this setup, horizontal- becomes partially interpreted as fire1 when interacting with a door button on your back, no idea why.
EDIT: Gosh, that's frustrating. I really hate Unity's default input system. Fortunately, thanks to my lovely patrons, I was able to purchase the Rewired unity asset. I'm hoping that that asset will work better for everyone's input devices across the board, we'll have to test and see!
> look direction not resetted
Pretty sure you already know about that one, so that's another "just in case".
The variable used to store the coordinates of the direction in which you look isn't resetted when a new game starts.
For example, if you're facing the floor when you die or exit, you'll be facing the floor at the very start of a new game.
Fixed
Thanks for bringing this up! I wasn't resetting the MouseLook script, fixed that. Also now the player will always start facing the containment chamber, as a bonus!
> 012 - chamber lighting
It seems that the red lighting inside 012's chamber goes past the ceiling, as you can see it from above (right before the chamber entrance).
No big deal, i could definitely live with that.
Which graphics setting were you playing on (fastest, fast, good, etc)? It could be due to how light bleeds when shadows aren't enabled
> 173 - kill through door
Aight, let's say 173 is right behind a door when i close it.
Once the door closed, i see a bit of his arm clipping through the door, but not enough to be afraid.
If i stay far away from the door and blink, 173 gets properly blocked by the door, and his position gets adjusted behind it, preventing further clipping.
Now, exact same scenario, but this time i blink right in front of the door : death.
The problem here is all about 173's proximity in the case he gets partially "doored".
You could fix that by reducing his kill range, or adding a piece of code that updates its position right when the door closes.
Yeah this is annoying, I haven't decided whether to let the doors 'push' 173 out of the way or just for him to move as they close to be on one side or the other.
> elevator - 173 immunity
Basically, as long as you're inside an elevator, 173 is unable to move.
Yeah currently 173 just stands still when there's no way to reach the player. I'll be adding some random behaviors (move, open doors, etc) in the upcoming build.
> elevator - out of order
Don't panic, your elevators work well, but still, there's a way to break them permanently.
Enter the elevator, click the proper direction button to go to the other floor, the door closes, wait for the travel duration.
During the door opening (not before or after), simply press the direction button to go back.
At this point, the elevator will stay here forever, door open, and the 4 available buttons won't do anything.
video
Fixed
Whoops! I needed to use 'yield return null' to wait until the door closed, not 'yield break', which breaks the coroutine. Then, because the coroutine set the 'elevatorIsMoving' boolean to true, it is never allowed to 'move' again. I also set the elevator to wait until the door is open at the end, to allow it to reset. Therefore, this bug is fixed in the next patch.

As a side note, I realized that just like the tesla gate, I'll have to handle the player teleporting out of the elevator. I'll have to do some thinking on this.
> elevator - noclip exploit
The idea here is to enter the elevator, click the proper direction button, and exit it right before the door closes.
After that, the algorithm does what it's supposed to do : wait for the duration, and teleport you to the other floor.
But since you're actually out of the elevator, and the teleport coordinates are relative to the elevator, you can reach nasty spots by comparing the 2 floors.
video
Fixed
I forgot to clear the array of teleported items and entities before gathering them again, so once you teleported in one elevator, you (and anything else) could always be teleported again if your reference wasn't overwritten. Fixed!
> tesla - immunity exploit
Using 1499, you can permanently lock a gate in a state where it becomes harmless for the player.
In that state, its animation is always active, and its sound effect disabled.
video
Fixed
My fault. The tesla gate needs to reset OnDisable(), when swapping Dimensions and the Facility is disabled. The next patch includes a fix for this!
PERFORMANCE FEEDBACK

I must say the game runs pretty well on my machine.
The only thing worth noting is that my FPS drop dramatically when a door opens or closes.
I'd say it probably has something to do with heavy conditional checks processed by the engine (pure intuition).
Let me know if you want more details about that.
Yeah I am calling a pathfinder Update() which generates a LOT of garbage I can probably increase the time between updates to try and help with this, or reduce the per frame ms allocated to pathfinding.
In fact this was a great point to bring up because I noticed that unlike most of my code, Doors have a constant Update() loop for each Door, which is anywhere between 50 and 100 doors so far, and will scale as modders and I add more rooms! Update() calls are very expensiveand unecessary here, as Doors aren't doing anything. I'll be refactoring their code extensively. Also noticed highlighting system constantly being called for each button, which is huge. I'll have to refactor that as well. Thanks for bringing this point up!
> faster stamina recovery when stationary
Something that was missing in the original aswell, and could add a bit of realism to the whole thing.

> walk/run shake effect
Currently, the sound effect feels a bit weird along with that linear view.

> elevator shake effect
Another touch to make the player believe the elevator is actually moving.
These are all great ideas - I especially like the stamina recovery when stationary idea!
Last edited by zornor90 on Sun Mar 12, 2017 9:13 pm, edited 2 times in total.

Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)

#388 by zornor90
General Build v0.4a is out!

This is a patch build based on user input for 0.4, freely available to the public. It fixes some issues with the tesla gate, elevators, and mouse look as well as increases the lockroom duration from 5 to 10 seconds, to allow the player to walk through it as in the original game.

Get it here!

Changelog:

Code: Select all

Changed quality settings names and options to make it more transparent to the player what they are. Only lowest (no shadows) lacks shadows
Moved TeslaGate.cs to correct folder
Tesla gate - kill field is now enabled / disabled independent of attack sound.
Much shorter time kill field is active
Tesla Gate now resets OnDisable(), for instance when swapping dimensions
Elevator now waits for the door to open before registering input from a button again. This fixes a bug that caused the elevator to become unusable if the button to go to a different floor was clicked while the door was opening
Doors are now not 'open' until the open function completes, and 'closed' until the close function completes
Elevator now clears list of entities to teleport before populating them again, to avoid dangling references and the player being teleported even if outside of the elevator
Fixed MouseLook not resetting on a new game, so player would be facing direction when quitting / dying
Player now starts facing the containment chamber
Doubled time in airlock from 5 to 10 seconds, so player feels less rushed
give_item console command now takes only an item_name parameter and returns a single item instance
Tried to create give_items command, realized that the DevConsole executes the give_item command as well since it has a similar string, will need to rewrite the console.
Increased spawn chance for t-shaped lockroom slightly (from 10% to 20%)
BodyText for TextViewer now correctly scales with aspect ratio (instead of being cut off). TextViewer should work better on different resolutions.

Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)

#389 by xhul
zornor90 wrote:Gosh, that's frustrating. I really hate Unity's default input system. Fortunately, thanks to my lovely patrons, I was able to purchase the Rewired unity asset. I'm hoping that that asset will work better for everyone's input devices across the board, we'll have to test and see!
Sounds great !
zornor90 wrote:Thanks for bringing this up! I wasn't resetting the MouseLook script, fixed that. Also now the player will always start facing the containment chamber, as a bonus!
You're the man !
zornor90 wrote:Which graphics setting were you playing on (fastest, fast, good, etc)? It could be due to how light bleeds when shadows aren't enabled
Performed my tests on "fastest", with all other graphic settings on their default values.
To give you an idea of how it looks, you can check Zackonark's vid at around 16:45, the red light can be seen on the left wall, when he passes near 012's room.
But again, that's just some red light, no big deal.
zornor90 wrote:Yeah this is annoying, I haven't decided whether to let the doors 'push' 173 out of the way or just for him to move as they close to be on one side or the other.
How about :
> Define a rectangular area for each door.
> When a door has to close, first check to see if any unit is overlapping that area.
> If yes, cancel door closing.
That would remove the clipping issues, aswell as the ambiguity of the "is he in or out ?".
You would of course need to add a few exceptions for special units like 106.
zornor90 wrote:Yeah currently 173 just stands still when there's no way to reach the player. I'll be adding some random behaviors (move, open doors, etc) in the upcoming build.
I guess i wasn't explicit enough, that happens even with the elevator door open, with 173 in direct line of sight.
Basically, the game always considers the elevator door closed, no matter what.
zornor90 wrote:Whoops! I needed to use 'yield return null' to wait until the door closed, not 'yield break', which breaks the coroutine. Then, because the coroutine set the 'elevatorIsMoving' boolean to true, it is never allowed to 'move' again. I also set the elevator to wait until the door is open at the end, to allow it to reset. Therefore, this bug is fixed in the next patch.
Good job =]
zornor90 wrote:As a side note, I realized that just like the tesla gate, I'll have to handle the player teleporting out of the elevator. I'll have to do some thinking on this.
That mask is nasty XD
zornor90 wrote:I forgot to clear the array of teleported items and entities before gathering them again, so once you teleported in one elevator, you (and anything else) could always be teleported again if your reference wasn't overwritten. Fixed!
Hmm, looks like i'll have to think of something new to walk through walls.
Good news is, i have Larry's personal phone number.
zornor90 wrote:My fault. The tesla gate needs to reset OnDisable(), when swapping Dimensions and the Facility is disabled. The next patch includes a fix for this!
Less skin cancers for class D's, good !
zornor90 wrote:Yeah I am calling a pathfinder Update() which generates a LOT of garbage I can probably increase the time between updates to try and help with this, or reduce the per frame ms allocated to pathfinding.
In fact this was a great point to bring up because I noticed that unlike most of my code, Doors have a constant Update() loop for each Door, which is anywhere between 50 and 100 doors so far, and will scale as modders and I add more rooms! Update() calls are very expensiveand unecessary here, as Doors aren't doing anything. I'll be refactoring their code extensively. Also noticed highlighting system constantly being called for each button, which is huge. I'll have to refactor that as well. Thanks for bringing this point up!
I was actually hoping for you to catch some useless/unoptimized stuff when i reported that one, nice =]

Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)

#390 by zornor90
xhul wrote:
zornor90 wrote:Yeah this is annoying, I haven't decided whether to let the doors 'push' 173 out of the way or just for him to move as they close to be on one side or the other.
How about :
> Define a rectangular area for each door.
> When a door has to close, first check to see if any unit is overlapping that area.
> If yes, cancel door closing.
That would remove the clipping issues, aswell as the ambiguity of the "is he in or out ?".
You would of course need to add a few exceptions for special units like 106.
This is a good idea, I may go with this!
zornor90 wrote:Yeah currently 173 just stands still when there's no way to reach the player. I'll be adding some random behaviors (move, open doors, etc) in the upcoming build.
I guess i wasn't explicit enough, that happens even with the elevator door open, with 173 in direct line of sight.
Basically, the game always considers the elevator door closed, no matter what.
Oh, I see what you mean. Yeah that's due to my elevator prefab blocking the pathfinding engine when it shouldn't, adding it to the list!
zornor90 wrote:Fixed
I forgot to clear the array of teleported items and entities before gathering them again, so once you teleported in one elevator, you (and anything else) could always be teleported again if your reference wasn't overwritten. Fixed!
Hmm, looks like i'll have to think of something new to walk through walls.
Good news is, i have Larry's personal phone number.
Hahaha
zornor90 wrote:Yeah I am calling a pathfinder Update() which generates a LOT of garbage I can probably increase the time between updates to try and help with this, or reduce the per frame ms allocated to pathfinding.
In fact this was a great point to bring up because I noticed that unlike most of my code, Doors have a constant Update() loop for each Door, which is anywhere between 50 and 100 doors so far, and will scale as modders and I add more rooms! Update() calls are very expensiveand unecessary here, as Doors aren't doing anything. I'll be refactoring their code extensively. Also noticed highlighting system constantly being called for each button, which is huge. I'll have to refactor that as well. Thanks for bringing this point up!
I was actually hoping for you to catch some useless/unoptimized stuff when i reported that one, nice =]
Actually found something else earlier today. The new highlighting system was calling update() in every single interactable object in the facility even when not updating, using almost 0.04ms a frame on my fast machine (which means that a standard machine was seeing anywhere from .10 to .20 a frame)! That's a quarter of what the pathfinding engine uses at peak load!
Image
I've changed it to add/ remove the highlighting system component when the user hovers over the object, which combined with my door fixes should make performance a lot better, especially as I add more items and rooms!
Post Reply

Return to “General discussion”