Yeah, your pages look good; everyone should contribute whatever they can. I've started to write a couple of the pages, including links to various useful websites.

Ok cool... with the other examples, it would do something when the var, joystick or whatever reaches the stated position, but would treat it like a key down; so it wouldn't repeat until the input has changed and gone back.

This is what I see... like I said, it still works, but here you can see the ghost joint;

Wierd.

@unknownuser said:

@wacov said:

I figured out how to make a no-rotate gyro! You use two... only downside is that you have to start rotated to 45 degrees pointing down; this immediately chages though.

no, you don't have to. this helicopter uses 2 gyros to keep part of the flying mechanism in it's orientation:

Error 404 (Not Found)!!1

(sketchup.google.com)

Ah ok thanks; yours works only when they are that way round. When I tried to counter the spin on mine, it disappeared whenever it touched something...

Awesome. I've copied across my (brief) descriptions of the versions, and added the download links for RC1. Also fixed a bit of english

I figured out how to make a no-rotate gyro! You use two... only downside is that you have to start rotated to 45 degrees pointing down; this immediately chages though.

Updated

Nice; it works very differently to mine. I really want a gyro that won't rotate, to do the turning from... the thrusters just don't allow precise aim.

Pretty glitchy... I experimented with more wheels for rotation control but thrusters work better. This is just a test level, If anyone finds a way to make the movement more stable please post it. Anyway, controls are:

left stick/wasd = forwards/backwards, strafe
right stick/arrowkeys = turn, look up/down
right trigger (RB)/space = fire

FPS rig.skp

Wait, have you made the Wiki, or are you about to? The link doesn't work, and I can't find it by searching.

That's always happened to me! I never mentioned it before... but the joints still got connected. Just to check, you are clicking the hinge, then ctrl/clicking the spehere, aren't you? I see you're using the beta; try RC1.

The Wiki could be started off with extracts from the FAQ as it stands now; alot of that is written tutorial-style.

I'm alright with script, and I've got a pretty good understanding of making vehicles, optimizing models for SP and that kind of thing. I can remember quite a few of the common glitches and how to get around them... the more technical stuff is probably what I can help most with.

Well, if you lead, I'll follow. I don't know how to set up a wiki, but I can write about SP fine...

A scene might help, you never know. But could you post a picture(s) of what's happening?

That's what I mean. A default setting, but with user-controlled exceptions would be perfect; there should be some pre-made templates, say, wood, metal, rubber, glass, stone, fabric, plastic, polysterene, and cardboard... just off the top of my head. This would mean that, as long as people used them, the materials that use exceptions would be cross-compatible between models.

It's a good idea, but Chris is very occupied with the actual making of SP; that's why there isn't one already. This'd basically be up to us.

Oh yeah! I remember that working in the beta, it must be something with RC1...

Thanks everyone! What really annoys me is that the slowdowns as I increase the size and complexity are totally due to SketchUp's inefficient renderer. I've had to increase the simulation's framerate to compensate, and this destabilises the physics. The friction engine just gives up, so the buggy starts sliding at random intervals; I don't want to see the textures go though! Is it even remotely possible to use an open source game renderer, or a custom one, during the simulation??

Maybe you could build the script into a function? Like, (onButton("a",1)toggleVar("foo")). Or something like that, just a way to detect presses and other changes as an event. You could even have stuff like 'onVar("foo",1)' , 'onJoy("lefty",0.8)' , and 'onKey("space",1)'.

I see what you're saying but we're basically stuck with however the physics engine does materials. No way around it, no way to edit the engine, and really no option of changing engines at this point. Sliders in a new window for material config, like you say from 0 to 100%, would be good, but if possible I'd like to be able to set rubber to have high friction against glass, and low against, say, a carpet. The carpet would have quite good friction and the rubber would have very high friction, so if we only used a general system then it wouldn't work realistically. We can't simulate the interaction between the rubber and every fibre in the carpet, so this would be the best solution

How do thrusters, magnets and emitters work?

Thrusters, magnets and emitters are all settings you can apply to any physics body in your model, using the UI; the thruster option will propel the object with a constant force along its Y (Blue) axis (However, this can be changed using the formula box). The power is user defined, and is dynamic, able to accept formulas and Ruby Script; a setting of 0 is off, so you can use something like joybutton("a")*1000 for runtime control.

Magnets affect any 'magnetic' objects nearby, with a force that can be defined much like that of the thruster. In this case, a negative value will push magnetic objects away, and, again, 0 is off. The setting for 'magnetic' can also be found in the UI; note that it's possible to turn both settings on for a single object.

Emitters create copies of themselves, which can be created with momentum along their Y axis. The lifetime setting dictates how many frames the emitted objects will remain; in this case, a setting of 0 will cause them to remain for the duration of the simulation. Strength is the momentum of the object when it is created, and rate is the number of frames between emissions; a setting of 0 for either of these will turn it off. These are dynamic, so you can turn emitters on and off, change their power and the rate of fire all during the simulation, using a formula or script. Note that complex 'objects' like a vehicle made up of many jointed groups cannot be emitted. Emitted items also lose a variety of settings applied to the parent object, such as whether it's hidden, any state changes, and any Thruster, Magnet or Emitter settings.