Ladder problem, Beanstalk solution

As I may or may not have documented in the complextoy blog space I use to maintain before my prolonged sabbatical from university.(typed on phone notepad cuz no service) I've achieved a buggy 2.5d for my top down Zelda-type engine. Using parallax and sprite-stacking we've achieved a top down 3d look. My issue is when the effect is scaled; for a single character to interact with a crate sized(jumpable-platform) and an obstacle that can be platform (wall) the code works fine. But the farther the distance from the "true" floor the worse the origin of the player character's center of gravity becomes. To spin the camera around the character on the "floor" of the level works fine. But to jump to platforms that are 2 or 3 times while maintaining the camera on the player, to have the camera spin around it might redraw the feet of the player behind the platform the player is on. This is disappointing. This prevents more than limits the kind of play because the climbing and interaction cannot build off these base physics. I'm calling this my "ladder" problem. Because it is as if to rotate the camera the player is attempting to crawl to the other side of the ladder and they fall off, it's not because the code is performing in a 1-1 comparable way, it's just the easiest language I know to explain what it feels like is going wrong without explaining the code I have second(or third) hand understanding of. Enter the concept my "Beanstalk solution", this is what I am hypothesizing will be the solution to my coding misdirection. This might not fix the issue, but it is a design inclusion that might make the issue something I can design around. 

Instead of having vertical transport only be (jump) or (acting as doorway/room-transition/animated climb) I could have roofs be inaccessible from stacked-crates, but instead create a code for (ladder/climbing rope) that I apply to trees. Similar to how you might imagine a Minecraft mod that makes all wood from trees act like ladders so you can climb in whatever odd direction the tree code grows the branches. Having trees give vertical and horizontal platforms to navigate allows for the stealth and acrobatic role players lots of room to explore levels in different playstyles. I'll have to include both and play with the (beanstalk) and the typical (platformer/paralex/2.5d) code sections before I can say for sure they work together. But with the (beanstalk) code I'll be breaking into the (harvestmoon) side of the build. Which may bring me much closer to the MVP (MinimumViableProduct) of the build. This is where I can start building the community/interest in the project/fund the larger (stretch goal) portions.

Wooden dummy 3

The milkhouse at the barn is my cramped workspace. I'm unsure how the weight is going to suspend from the center support. If this support is insufficient I'll either make a box support the dummy fits similar to this base or make cross supports similar to more traditional models. 

The body and arms are their own tweaking challenge, the arms I'm repressing and modifying from my first dummy, the length of the arm base(as it fits in the body) has to stick out the other side of the wooden body by about 1/4 the length that fits in the body for the set pins to hold the arms in. When I was just practicing blocks on the arms the action was fine, if a bit loose from my inexperience, but lapsau or other trapping/ deflection/misdirection moves would shift the arms from their place. 

The action on the top arm moves in about a 1in or so extra inward because on the opposite inside corner I took about 1/4 inch more then I wanted it; but including the pins in the back should sure up some of the action.

Embossing/book/HDPE press

With a little imagination you can imagine this as a large press. 

The 2ton press will be switched out for a proper bottle jack. Similar to the Maker Brothers modification I've added extra length so I can fit various projects or future modifications.

wing chun dummy 2

To continue my Kung fu training I'm building a second training dummy for the school, one much lighter than the first. In the back of this photo you can see the body of the dummy. The frame you can see lying on it's back, the bottom support will have triangular braces to the suspension post. 

The body of the dummy will have small tire act as a housing on the base and chain to suspend from the post that will mount to the base. Tentative design is to make a three or four part collapsible construct. 

The body will have 2 tire halfs on the opposite side of the dummy to both provide spring to the body when using the first wooden arm side; and when inverted provide a rubber spring striking surface. Other projects take priority as I'm on a time crunch to get more tooling made up to prep the barn and forge for winter. Keeping small projects updated here for posterity and to keep my phone memory.

Speaking of:

The first post I made on the construction of my first dummy was deleted, idk when, those photos are gone I'll rewrite some of that when I can if it becomes relevant. Otherwise I'll just take some more photos later

knifemaking tooling

The knifesmithing project has reached the point of needing new tools. Earlier I've recorded the progress with upgrading the forge, I have weldable heat now and am one step closer to that holy grail of making Damascus.

The next important upgrade is power, hammering and forming power that is; I'm one person with limited calories to burn per hour, as much as I can hammer a shape into the other shape I want, the more the steel the harder that is and the more fuel it burns. So my design goals are to build a hammer and press with a non-existant budget. So far I have most of what I need for this upcycled design.

There are some tricky design issues I'm excited to tackle. For resource and reference I'm using; '507 Mechanical Movements Mechanisms and Devices' by Henry T. Brown.

In no specific order these are some of the Mechanisms I hope to include in a drop hammer. The main goal of this project is to make a wooden frame vertical reciprocating drop, to have a treadle powered flywheel powering the lift and drop. 

Fig 154 is a drop hammer off a drum

Here is another iteration on the simple drop hammer, closer to our design

Fig 353 is a variation on the Da Vinci cam hammer

Figure 420 is a hammer swing stop, 

Fig 416 is a continual motion treadle assistant, the spring helps the right angle turning assisting the momentum of the treadle moving the drum.

Figure 261 is a play on a weight drop pully system where the upstroke is slower than the downstroke

Jumping and platforms

As mentioned in previous post; instead of inserting a z axis and platforms into a randomizing machine, I'm re-evaluating the approach and making each of the puzzel pieces I want the machine to fit together first. I don't need the randomizer throwing together indipendent pieces if I don't know if or where or how they work together.

Maps and Stacks

Sooo. Long time before I've gotten around to updating. This pandemic has had me attempting to focus more on removing obsticles then completing projects. I'm much farther in understanding how to make a Z access and a global camera that might give me the LOCK ON toggle feature, or panning the camera around the corners, or include an active dynamic camera for mounted combat.

The main issue I've had is structuring the underlying framework of the level to produce all the elements I want to include in the game within the level randomizer. And the proper links between each element so I might be able to add and remove things from a data map into the level and have those dynamics tied to player progress. With that I can have my doors between random levels and the random or otherwise sequence between each level spawned to create the labyrinth between game location. I'll have a very basic map but that will structure the rest of these features I want to plug in.

I have two builds I am refining to try to get this rotation and stacking feature working just right. One is starting from a working randomized build with improper rotation. The second has beautiful rotation and needs the randomizer.

My initial goal was to figure a NorthSouthEastWest door spawn feature to test a basic loop between Spawn Room to the opposite side of a newly spawned room and South Door to the Home Room, with this I'll have the basic fuctions of the map. Then if I can make it add a second room between the Home Room and South Door after entering the North Door, and do the same with the East and West, I'll have something close to the map I want before I start playing with AI. But then I got this sprite stacking working and the movement and envorment I want to fit inside the randomized duengons that make up the game map needs multiple Z axis levels and would require a z axis . I'm just lucky the code that I needed to have a dynamic camera like I wanted around the player also helped adding the platforming effect and depth I was scratching my head about jamming into what working code I have. It reminded me how easy it is to put the cart before the horse when thinking ahead while working. So as much as the doors and randomizer make up a big aspect of the framework that will make this game a "game" with progression, and that is a fundimentially more important key in a finished product, the first step I ought focus on is all those blocks functioning within the camera physics and game collision physics before I stitch them into a randomizer. 

tldr;

I have a puzzel maker that I wanna put interactive stickers on but soon as I got my eyes working and the puzzel spinning and I realized that also lets my game piece jump it'd be better if I make a puzzel piece variety pack with stickers that works with my eyes and my game piece, and the puzzel spinning; before I build the puzzel making machine. Beeefore I make the puzzel quilt. Fingers crossed.