Re: Containment Breach Unity Edition (2016) - General build v0.4.0 is out (3/10/17)
#381EDIT: Downloads are re-enabled.
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 thesexhul 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.
Hey man! Thanks for doing that playthrough! It is so helpful to see people actually playing the gameZackonark wrote:Hey everyone!
been a while, but hey! Progress!
[youtube]L6tBAGtqkYc[/youtube]
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!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.
Fixed> 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.
Which graphics setting were you playing on (fastest, fast, good, etc)? It could be due to how light bleeds when shadows aren't enabled> 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.
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.> 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 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 - 173 immunity
Basically, as long as you're inside an elevator, 173 is unable to move.
Fixed> 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> 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> 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
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.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.
These are all great ideas - I especially like the stamina recovery when stationary idea!> 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.
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.
Sounds great !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!
You're the man !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!
Performed my tests on "fastest", with all other graphic settings on their default values.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
How about :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.
I guess i wasn't explicit enough, that happens even with the elevator door open, with 173 in direct line of sight.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.
Good job =]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.
That mask is nasty XDzornor90 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.
Hmm, looks like i'll have to think of something new to walk through walls.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!
Less skin cancers for class D's, good !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!
I was actually hoping for you to catch some useless/unoptimized stuff when i reported that one, nice =]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!
This is a good idea, I may go with this!xhul wrote:How about :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.
> 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.
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!I guess i wasn't explicit enough, that happens even with the elevator door open, with 173 in direct line of sight.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.
Basically, the game always considers the elevator door closed, no matter what.
HahahaHmm, looks like i'll have to think of something new to walk through walls.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!
Good news is, i have Larry's personal phone number.
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!I was actually hoping for you to catch some useless/unoptimized stuff when i reported that one, nice =]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!
Return to “General discussion”