/diy/ - Do It Yourself

>>425498
You can pretty easily fine tune the difficulty for laypeople by making more macroscopic circuit components. For example, if you wanted to make automating machine guns easier, you could introduce an "if-then-else" component that just checks some condition at each timestep and branches the circuit accordingly, instead of doing a conditional component, a branch in the wire, and a NOT gate. You could also decouple the GUI from the circuit, so your circuits don't get so cluttered. Finally, you could make the individual components as error tolerant as you want, e.g. you could just rig the R key directly to reload, and have the gun just do nothing if it doesn't need to or can't reload.

As a case study, you can look at Blender's logic system, which is kinda similar to circuitry and actually favored by laypeople who don't know how to code. (pic related)

>>424369
> punching someone with your relatively fragile weapons doesn't seem like a good idea.
Bayonets, man, bayonets.

> quick-reload mechanics in, was it Gears of War?
I think it was. And yeah, I liked that minigame too.

> minigames
Another possibility is some sort of simple rewiring minigame. You have N power sources of varying strength and M power sinks (maybe 2 slots per sink). You have to reroute the wires along a grid so no grid cell has more than 2 wires on top of each other, and still get your power where you need it. If you want to divert more power to a sink, you can either plug into the auxiliary socket or replace one of the current weak power sources with a stronger one from somewhere else. Since some of the sources would be batteries, you'd have to rewire whenever a battery goes dead, but it might recharge over time from the reactor.

>>422737
You're stealing OP's design, but you're omitting the giant buttons and switches? Come on.

Also, what is that controller on the left arm rest?

>>419758
A real mech wouldn't have windows, it would just have an external video camera, so I think it's reasonable to display the game on a monitor inside (and certainly cheaper).

>>416581
>I am thinking about putting sound proofing on the outside to keep it from gettin ugly in there. Would that work? Line the /outside/ with dynamat or something similar?
see:
>>416637
>There is a difference between soundproofing, and setting up a room for proper acoustics be it for listening/recording purposes.

I'm no expert but I believe the point of putting soundproof foam on the interior walls is to prevent echoing off the walls, which makes the audio sound worse. If you put the foam on the outside, it will prevent noise from leaving the box, but not from echoing.

In my opinion, soundproof foam looks cool anyway. Some back of the napkin calculations indicate that it will probably cost $30-60 to soundproof the interior, depending on how thoroughly you want to do it.

>>415249
>Thats not a ball bearing you idiot, its a ball joint.
Heh, derp. My bad.

>>414302
Hah, awesome! I love diy MacGyvering.

>>413819
Here's the bearing he uses for the support column.

>>413777
> I was worried about having the system on a pivot in the middle but then having motors across from each other; if something went wrong and they both tried to push up or down at the same time, shit would've started breaking.
In the wiper guy's build, I'm pretty sure that can't happen. The whole point is that the motors are in front of the ball bearing, so if they both "extend", it will just tip the seat backward, and if they both "contract", it will tilt the seat forward.

(in the picture, the center of mass is in front of the bearing/support column, but you get the idea)

>>413511
>I'm sure three of them can gymble you and your whole box around.
Actually, the windshield wiper sim guy's design is really elegant and it requires only 2 motors, which would save a fair chunk of change. He's got the whole thing balanced on a ball bearing and the motors placed a fair way in front of the center of mass. That way, when both motors are up, the thing tilts back, when both are down, it tilts forward, and when one motor's up it tilts to the side. The downside is that you can't tilt forward and sideways at the same time (you basically can tilt like a dinner plate that's always touching the surface of a table). The upside is a 33% reduction in cost and complexity and your motors don't have to actually support your weight, because it all rests on the ball bearing. Hell, if you added counterweights below the ball bearing, you could probably move the thing with a finger.

Some control scheme inspiration. This is the controls for the Canadian Space Agency's robotic arm, Canadarm (nice name, right?). I thought it looked pretty cool, particularly the giant STOP button and the little metal loops around the switches and knobs to prevent accidental toggling.

>>411570
>The first thread wasn't archived
http://archive.installgentoo.net/diy/thread/380959
http://4chandata.org/diy/Battlemech-Cockpit-Simulator-senior-project-a345210

I believe all of /diy/ is archived automatically.

>>411239
Seems like the sort of thing you could emulate with software. Why bother putting in the work to disassemble the LCD?

Completely off topic, but whatever happened with your armphone? Do you ever use it? Did it get any cool upgrades since the thread 404'd way back when?

>>408341
I'm always wary of feature creep, although it does seem like you're implementing things faster than the features are creeping, which is good.

>>408317
>The fact that it was such a low probability was actually what made it a poor mechanic; you'd be unloading on some guy and suddenly he'd just slump over, and my beta testers would get really confused. (They thought it was a glitch.)
Perhaps make this happen only with a rail driver weapon, like in Red Faction 1. The gun shoots an energy beam through walls that only affects people. (In RF1, the gun also has a scope that shows people's heat signatures.)

Sorry to contribute to the idea spamming, but I hate to see a cool mechanic like the dead pilot go to waste.

>>407662
>For coding, use comments EVERYWHERE; I comment almost every line of code I write.
http://www.codinghorror.com/blog/2008/07/coding-without-comments.html

>>407674
>My general philosophy with scripts is to make each script completely independent.
I'm guessing you mean apart from polymorphism. If you're not using inheritance on this project, you're making things needlessly hard on yourself.

>>407677
>sniping the cockpit
That's really cool, it would be neat to see it in the final game. If it's a matter of gameplay balance, then just make a really small hitbox/low probability for this happening, or make the hitbox on the back of the mech (pilot's O2 supply or something).

Also, you seem to have lost your "BattlemechDood" name.

Just found the new thread. Looks great, OP!

>>406243
You'd be surprised how fast things can deteriorate.
http://www.youtube.com/watch?v=m8CsBMCfu0s
I read the full book a while ago and it talks about how many cities, like NYC, are constantly battling with nature. If NYC were abandoned for a few months, it would flood--not just the subways, but the streets themselves. There's giant water pumps running 24/7 to evacuate the water. So, plausibly, 100 years from now, cities could be very overgrown.

>>400859
Nice find. I particularly like this one: >>>/m/8778522

>>397216
Lookin' real good, man. I have three additions I think would be cool:

1. Homing projectiles that can be used to shoot around corners/shields. Basically, you want to give the projectile an initial velocity, but home in on the target, so you can aim to one side and it will arc around obstacles.

2. Melee attacks to either knock the opponent backwards, do massive damage, or both. I think this will help make the game more balanced and interesting.

3. Land mines.

Some inspiration:
http://www.youtube.com/watch?v=U7wOX2WqbXE

http://www.youtube.com/watch?feature=player_detailpage&v=D6GvIu02cew#t=32s

>>394905
Dude, that's already been posted twice.

>>393255
>fun as hell
Yep. I love it.

>Still not exactly what I want
If you want more help, explain better and I'll do my best. I've seen your threads before and you're a cool guy, so I'll stick around till the 404.

>>393015
Another way of doing this would be to have the crosshairs accelerate towards the player's perceived position each frame, but have the player's perceived position be a random position centered around their actual position (e.g. normally distributed).

>>392919
Sorry, I've been a bit busy with classwork. For wandering behavior, you want to have an angular velocity for the bot's crosshairs, then every frame, add a random vector to that angular velocity. (Then add the angular velocity * dt to the bot's current crosshair position) If you want the bot to randomly jiggle its aim, but trend towards you, you just have to bias the random vector you're adding towards the player (e.g. make the velocity accelerate towards the player by amount x every frame, then add the random vector on top of that).