My car scenes have working spring engines so maybe I could be of help!
Fair warning though, mine are quite simplified and run almost entirely on scripting rather than using pistons/mechanics because my scenes are designed for 60hz and 60hz Algodoo doesn't take kindly to high-power piston engines...
If you like, I can share a scene response detailing how my engines work!
It's also fine if not though! My engines are much simpler than most (again, they don't use real pistons) and might not be what you are looking for.
As for connecting the crank's axles to eachother, the way I do it is to attach the two crank parts with a center axle and set the axle to an extremely high braking force.
As for the engine in this scene, a separate timing system for the ignition could help. You could do this by using something akin to a camshaft. Since lasers operate on framerate and not simulation frequency, it could be wise to substitute the laser entirely for something scripted.
Finally, note that this is technically a spawn engine since it generates power through spawning objects, so it's not technically a spring engine!
I found the cause of the issue and I am now working to update the scene.
The theory you posted was correct -- the way UNTIL and WHILE works in Chives v10 computers (not just this one either!) is fundamentally flawed. I have no idea what I was thinking when I made that...
Just shifting a little bit of code around seems to have cleared up the issue though!
Feel free to let me know if any further complications arrive -- so I can be ready to fix them!
My theory as to why this issue arose in these hybrid computers and not the original AHOX Hydrogen is because these use the same break function for both Chives and Ab -- and having not worked on either for a loong time, I kind of forgot the difference.
Either way, the break function remains unchanged and is still the version from Ab -- just a few lines being shuffled in the Chives interpreter seemed to clear things up!
Once I remember how bundles work, I think it would be wise if I could return a list of filenames within Chives too, because right now listing the files on the Ab partition from within Chives is impossible...
I'm working on my next Algodoo Computer (the AHOX Boron -- I'm continuing the next-element naming scheme, Magnesium was just a detour
This also implies that, until further notice, the next computer after that would be named the AHOX Carbon, AHOX Nitro, then the AHOX Oxy, and so on) and I just realized I completely forgot to add the functionality for Chives network booting.
I have released a hotfix to the scene that uses the same code the AHOX Boron uses for it. I hope this helps things!
I really should have tested this more...
I promise to be more responsible with the AHOX Boron!
EDIT: Unfortunately, as of right now, the AHOX Boron is as good as cancelled.
I'm running into tons of bugs in Ab that are caused by the stack limit that can't be fixed without throwing xfors around everywhere, and thus greatly slowing everything down.
What's even worse is that older versions of Ab have a lot of these same bugs, albeit less severe.
Ab is a complete disaster and I regret making it if I'm honest...
EDIT 2: I've done a lot of thinking (or well, as much as I can on my currently tight schedule) and I've decided that I am going to rewrite Ab from the round up and maybe play around with tokenization!
Long story short, what I want to do is effectively compile the Ab program into a much more simplified form before the computer runs it.
This would come at a tradeoff though; when I first load the program I would have to take some time tokenizing it and I'm not quite sure how I should handle that yet.
But, this could open up a world of possibilities, potentially even making Ab's speeds comparable to that of Chives V11 -- and as well, finally allowing for nested functions!
For an example of what I'm talking about, it could turn something like this:
print "Hello, World!"
into:
[1, [0, "Hello, World!"]]
with 1 being the opcode (print), and the [0, "Hello, World!"] being a function; in this case function 0, or the immediate function.
I haven't quite worked out how the tokenizer will work but I plan to start small and work my way up.
It's also probably important to note that I am on my last 11 days of school (ever) so I'm a bit stressed out at the moment and don't have that much room in my head for Algodoo stuff.
One last thing -- I probably won't release the AHOX Boron right away. I plan to do some form of beta scene showcasing the tokenization and demonstrating whether or not it's something I should pursue further.
I personally have decent hopes for it -- but who knows what the future holds! It could turn out terribly, or it could be one of the best Algodoo Computer-related decisions I make!
To be fair though, most of that time was spent completely forgetting about Swap, and most of the time that was spent on Swap even then was trying to make it so that the entire thing could be one scene and not the game itself.
I'm taking things easy for the next few days -- but once I'm done, I'm going to start working on a bunch more scenes!
For personal reasons (long story short, I'm pretty seriously disabled) I can't get a regular job -- but one upside of that is that I won't have to be pulled from my hobbies (such as Algodoo)!
I'm quite looking forward to seeing what the future of my scenes looks like now that I don't have to worry about school anymore!
I believe I have tracked down the cause of this nasty little bug causing the stack overflows -- and if so, it's not as bad of a fix as I expected! I hope to release a hotfix for that bug along with the bug you mentioned shortly!
As much as I would love to do the tokenizer, it is a really complex project beyond what I've done before so it probably won't be complete any time soon if I even get to it.
EDIT: I fixed the bug you mentioned as well as the stack overflow bug. Cheers to Ab being somewhat usable again!
I think one thing that could help with the tipping is if I change the drivetrain from AWD to 4x4.
If I engage front-wheel drive, perhaps it wouldn't want to flip!
At the same time though, traction would be way worse...
EDIT: I tried this and it didn't go very well. Even if I max out the friction on the wheel, it just glitches out at full throttle and doesn't pull the car very well.
When I do end up going to college though, it's probably going to be for something psychology related.
I don't have huge confidence in my engineering skills
This scene showcases why to an extent, I would say -- if you try to build a car with a geared transmission with these engines, the engine usually backfires upon shifting up because of the rapid RPM change, and the backfire results in a huge jolt and usually slows the car down pretty hard.
It's sort of just an artifact of how my engines idle.
From what I understand, real engines usually just have a minimum throttle rate -- and that throttle rate usually happens to be around enough to reach 800 or so RPM.
However, these engines only have completely on or off throttle -- so the idle speed is achieved through a hard rev limiter which shuts off ignition above a certain RPM.
Since each detonation can easily increase the RPM by over 100, it will typically overshoot a fair amount and slowly glide back down due to air resistance, causing the cycle you mentioned.
I may experiment with soft rev limiters in the future -- who knows?