- this fix was implemented by simply clamping the x and y of the localPoint
to -0.1-0.1 and -0.2-0.2 respectively.
- objects can no longer clip through stage
- player can no longer clip through stage
Fixes#13
- the player shouldnt be able to shoot a portal while grabbing an object (as in game)
- if the player does shoot while grabbing an object then the object is dropped (as in game)
- The portal gun now has its own .c/.h files
- the portal gun is a struct containing a CollisionObject and RigidBody
- portal gun CollisionObject is set as a permanent player point constraint
- portal gun also moves while shooting
- video attached of it working
- was tested on N64 hardware no game breaking issues.
- removed long list of completed tasks
- added some new features
- added a sound addition todolist
- added a prioritized bug todolist (all hardware verified)
previously if the player walked with a decore object to a new room
within a level, the object would dissapear (because it was no longer
set to the correct currentRoom). This can be seen in test chamber 0 with the
radio for example.
- this is a simple fix to change the currentRoom of a grabbed object
to the players room if the player walks through a doorway.
This fix was implemented by checking the distance from the player to
the nearest collision object (thats not the player and the object they're
holding) and if that is too close, adjusting the grab point back towards the player.
grab point is also bounded to -1.5 -> 0 so that the grab point doesnt go somewhere odd.
Also if a player is holding an object and they are much too close to a wall
(less than 0.3 distance) it will disable grabbing on the object and drop the
object.
Fixes#32Fixes#11
- Door open and close sound implemented
- Pedestal rotating sound implemented
- Elevator moving sound and timing implemented
- fixed implementation to make use of object flags rather than global variables (this was a good catch because it fixed a bug when there were two buttons loaded at once)
- intercom on sound triggers when its the first queued sound
- intercom off sound triggers when its the last queued sound in a string of sounds
- button press sound implemented
- cube dropper now has a sound when it drops cube
- pedestal now has a shooting sound
- save checkpoint is now at a few more places
- removed previous revision
- removed portalgun flag from being saved to a save file in player.c
this was due to the fact that that information is already saved in
checkpoints (I think?) and doesnt seem to serve a purpose
- the only downside (or maybe this is intended) is when a player
loads from a checkpoint it only seems to load from the start of the
blender file level (so if there are two levels in one blender file
and the player clipped out or died in the second level then it would load
back to the first level in that blender file)
- player now has footsteps (always sounds like concrete steps)
- player now has jump footstep
- player now has landing footstep
- player has select (grabbing) sound
- player now has select denied sound
- player has various new additions to flags to accomodate sounds
Fixes#20Fixes#69
- there is now a new asset "signage_off.blend"
- when the player first looks at a sign it exponentially is on more often
- video attached to PR of flickering in action
- majority of changes in signage.c
the following has been implemented:
- C UP cancels out any pitch the player might have (looks straight)
- C DOWN cancels out any pitch and rotates 180 (looks behind)
- this was implemented with only existing quaternion math operations
- functionality disabled if player is looking directly up or down.
these are some final tweaks to the HUD:
- when grabbing an object HUD turns white (as in the game)
- blue part of HUD indicates that a BLUE portal can be shot (not just any portal)
- orange part of HUD indicates that an ORANGE portal can be shot (not just any portal)
- screenshots are attached
at this point I think every logic based hud element has been implemented
not sure where the asset for the center reticle is (the white dots right in the middle of the HUD),
but once we add that as an asset it should be easy to plop that in the middle of the rest of the HUD elements
In the real game the HUD is constantly checking if you are looking at a
valid wall to shoot a portal at. If you are, it displays both parts of the
HUD as filled in. if you arent they are both unfilled.
the hud in the game also has a portal indicator on the side of the hud
corresponding to the portal you last shot (also in the corresponding color)
both of the above things have been implemented in this PR. also attached are
images of it working.
I had to add a flag "just_checking" to a few functions involved when the
player normally shoots a portal and the validity checks are run. This flag
tells the functions to not actually shoot a new portal but just check if
shooting a portal would be valid.