Koruzarius

No, they changed it... Now the *top* needs to be clear, like retro-rocket brakes. So anyone who futureproofed their designs are completely out of luck.

Yeah, I *immediately* cratered my ship that I thought was in good flying form...

Can we get the getPlayerPosition and direction vectors available *on a screen*? I've been trying to implement some AR features for many months now, and the quaternions stymied me, but now with the screens all rendering for each player individually it feels like all the pieces are in place to do some basic AR work, but the screen doesn't actually have the player location, and basing it off of a programming board means that it will only apply properly for one person, when there's no reason each person couldn't have their own proper view. I'm going to try to implement it anyway, but it will be clunky by comparison...

Looks great! I'm glad it won't be removing old constructs that are too complicated, though a bit worried about people who may want to update an old ship and are no longer able to =S Hopefully they can update it during the period where we have the numbers but they aren't enforced.

While I would enjoy some AvA combat, I don't see that coming for some time, and it will probably require a lot of mechanical rework, so I'm not thinking too heavily on that right now. I'm wondering how maneuver tool mechanics will work... One of the major weaknesses of docking as I've seen it is that if you are in someone else's tile, they can rip your docked constructs off of your ship, and that can cause some brutal headaches. With this new system, can the maneuver tool affect the whole group of constructs, not individual ones? Force separation of docked constructs to happen through one of those UI options, maybe?

Simpler, quite probably! This was quite a lot of work =D But faster? I honestly really doubt it. This is some very very basic level stuff, there's very few operations involved in each of these steps, and the amount of data being transferred over the server is also minimal, just the 50 kb (45kb of which is the teapot itself) one time, then the client's computer handles all of the processing. That said, it's also pretty limited in its ability, I kept the code pretty tight and efficient, but the trade-off is it isn't super versatile. It can handle any OBJ file that has faces that only have 3 vertices each. I'll expand it out later (probably) but the more versatile you get the slower and more bulky it becomes. The loading step at the beginning could probably go 10-100x faster, I seriously lowballed how much processing to do at each step, I may optimize that later, I just wanted to be absolutely certain it wouldn't overload!

Hey all! So I've been playing around with the new screen tech on the PTS, and decided to try to create a basic 3D renderer. It was a bit of a pain because there's a 50,000 character limit, and no vector libraries in place (yet?) but it was a fun challenge, and it runs fairly well! Anyone else playing around with the new screens yet?