Hi! I don't think so. You'd probably have to implement IK constraints and manually move control points around. I suppose you could use this to simulate some of the joints inbetween but at that point it would make more sense to implement a dedicated system for walk cycles.
JamJamTeam
Creator of
Recent community posts
Hi! You can attach a point of one group to a point of another group using the VIConnector like this:
var rope1 = new VIRopeColored(0, 0, 8, 10, c_red, 1, 1, -1); system.AddObject(rope1); var rope2 = new VIRopeColored(0, 0, 8, 10, c_green, 1, 1, -1); system.AddObject(rope2); var connector = new VIConnector(0, 0); connector.SetParent(VI_PC_TYPE.POINT, rope1.GetPointByKeyword(VI_POINT_INDEX.LAST)); connector.AddChild(VI_PC_TYPE.POINT, rope2.GetPointByKeyword(VI_POINT_INDEX.FIRST), false); system.AddObject(connector);
This connects the first point of the green rope to the last point of the red rope. Note that you can't set up circular hierarchies though with multiple groups where the last one is connecting to the first.
If you need some new object which is not represented by a rope/cloth/softbody, you need to create a new function which derives from VIPhysical. You can look at how the VIRope functions are set up for that :)
Hi!
You can run the simulation multiple times by calling system.Simulate(delta); and manually override / temporarily store the friction variable system.frict before that.
The reason the rope with more points appears longer is because every point is affected by gravity, which is dragging the rope down and streching it. You can increase the "stiffness" in the rope's constructor to counteract that. :)
Unfortunately I don't have any time atm to create tutorials beyond the function documentation and the implementation provided :c Sounds like a complicated setup. What you could do is create a rope and attach both ends to connectors. One connector is then also attached to your player instance and the other one to your hook instance (which you'd control with your own physics probably). Retracting a rope is not a build in functionality. A couple of months ago, someone else asked a similar question about a fishing line, where I explained how you'd implement something like that in theory. That does require some understanding of programming though :/ Hope that helps you a bit!
If it works, it works :D There is still some functionality one could add like the delete function you've added, or interaction between different ropes/softbodies. However, I won't be able to work on this project for a longer time again now so feel free to add what you need :)
That being said, I plan to upload the project to github the next couple of days, so if you want you could also contribute there.
(Seems like I can't upload screenshots for some reason.. :c)
Problem 1:
The verlet system works by having a list of vertices and a list of sticks. Every update, we iterate through the list of vertices from the start, forcing the sticks to their original length. Since we're starting at the first vertex, its position will always be correct, but the rope will drag away from the last point as a result. One way to solve that might be to rewrite how we iterate through the list every update. So update the first vertex, then the last, then the second, second from last, etc. until we reach the center. I'm not sure if this will result in other unwanted behaviour though.
I'd manipulate this for loop and see what happens:
verletFunctions line 299:
for (var i = 0; i < stickAmount; i++) {
currentStick = stickList[| i];
A simple and dirty "fix" would be to rewrite the draw function and draw another line from the last vertex to the point where it is supposed to be attached. It won't be perfect but it will look like it's attached.
verletFunctions line 497: draw_vertex(currentStick.v2.x + lengthdir_x(wHalf, stickDir - 90), currentStick.v2.y + lengthdir_y(wHalf, stickDir - 90)); draw_vertex(currentStick.v2.x + lengthdir_x(wHalf, stickDir + 90), currentStick.v2.y + lengthdir_y(wHalf, stickDir + 90)); // Draw another line here draw_primitive_end();
Problem 2:
When the verlet system updates, the "stiffness" is simply the amount of times we do the update. The more updates per frame, the more correct the simulation will be, but the more performace we draw.
verletFunctions line 294:
repeat (stiffness) {
#region Update sticks
#region Update vertices
}
A stiffness value below 1 would therefore result in errors.
Problem 3:
That will be a difficult one.. I didn't think of a use case like this.
The sticks already have an individual length value. To retract the rope, you probably want to create some function that retracts the rope by one pixel. It would decrease the length of the first stick by 1 as long as the stick's length is greater than 1. A length of 0 would probably create errors. Otherwise delete the first stick and the first vertex, then continue with the next stick until the rope is gone.
New function for the rope group:
function retractRopeByOnePixel() {
if (<amount of vertices> > 2 AND <amount of sticks> > 1) {
var currentStick = <first stick>
if (currentStick.length > 1) {
currentStick.length --;
} else {
<delete first stick>
<delete first vertex>
}
} else {
return false;
}
return true;
}
Something like that maybe. You'll need to figure out where to get the amount of ropes/sticks and where to delete them. Call the function until it returns false, then delete the rope.
Hope I could help :)
Thank you! I think I added an option to change the 'stiffness' of the verlet system so it doesn't stretch so much. You should be able to manipulate it either in the rope function or the function which sets up the verlet system. But do note that increasing the stiffness draws a lot of performance, as this basically multiplies how many times per frame the whole physics simulation gets updated.
Thank you :) The verlet system is drawn using the VerletSystem() struct's Draw() function. The depth would be equal to the object which calls the Draw() function. By changing either that object's layer, or where you call the Draw() function (depending on your case), you can control the depth at which it is drawn. There is however no functionality to sort different verlet groups within the same verlet system after they are created. Groups within a system will be drawn in the order in which you added them with the VerletGroupCreateRope() or other functions. If you need to change them dynamically, you could either create multiple verlet systems, or write a new function inside the VerletSystem() constructor, which rearanges the "verletGroups" ds_list. Hope this helps!
Thank you for the kind words! It's really rewarding to hear that some people like the game so much :) I think with all the positive feedback I got I will make an actual game out of this. Motivation for my old projects was getting pretty low so it would be cool to work on something new. Especially an arcady game like this wich is playable from a very early stage and doesn't require multiple years of development while still not being playable^^ So thanks again for your feedback, it really means a lot to me (:














