-
Posts
3,736 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Nuke
-
yea but it was driven by an array of lego motors, that was impressive in of itself.
-
c is a good first language: 1 it teaches some very useful fundamentals. functional programming, working with memory, pointers, etc. 2 it is still a useful language to know, looks good on a resume. 3 its not hard to jump into c++ after learning it. i learned c++ as my second language, and using c was a great stepping stone.
-
lego is extremely strong under compressive loads. i hear there is a 118 foot high lego tower in israel, won a giunness world record in 2015. the other day i saw a video where they built a car mostly out of lego, and drove it (using a lot of lego motors). its only a matter of time. everything else you said totally agree. i think anything with a virtual machine should be avoided at all cost. we had the problem of too many architectures, so we started using virtual machines to bridge the gap. now we have too many virtual machines. its only a matter of time before we get virtual machines in our virtual machines. gotta draw the line somewhere before things get out of hand. there are a lot of useful scripting languages, but its better when they stick to that job and not try to fix the too many architectures problem.
-
i was skimming the service manual and i only see 2 drive bays, one optical one drive. i didnt see an m.2 slot or anything like that in there. you can however get an adapter to turn the optical bay into an extra drive bay. they are pretty cheap (granted you still need a drive), but you would be giving up your optical drive, so its a tradeoff. from the service manual it looked like the drive can be removed with just one screw, so it should be easy to swap if you want to go back. me personally i havent installed an optical drive for any other purpose than to fill a hole in my case in the last decade or so (one computer its not even hooked up, its just acting as drive bay cover).
-
there isnt a spare drive bay by chance is there? do laptops still have those? anyway while investigating a new pc build and wanting to turn the old pc into a media center i looked at using a small ssd as a boot drive. drives in the < 128gb range are pretty cheap. should be enough for your os and database.
-
i dont know about that, lego is pretty structurally robust if you build right.
-
i learned c in 9th grade. its totally in the realm of possibility for a highschooler to learn a real programming language. i see scratch as being for a more elementary level.
-
yesterday i stared at my raspi tablet terminal all night (i sshed in so i wouldnt have to use the chicklet keyboard and do a lot of squinting). so after updating the distro, i find out that there is a newer one out. after backing up the card i attempted to do the upgrade to the new distro in situ and it resulted in nothing working. i had doom, descent, an snes emulator, quake 3, etc all working perfectly fine, figured the upgrade process ruined it. so i re-flashed the card with a clean install of the new system. went through all the documentation (using linux is like reading 'war and peace' all the way through every weekend), recompiled all the things. and nothing worked. aparently they borked a lot of the gpu drivers in the new distro. so this morning i re-installed the backup on the old distro. now everything works again. i also recompiled my i2c joystick driver, and that seemed to work right the first time. now i need to build a better one. its going to have a thumbstick, throttle slider, trackball, hall effect encoder knob, and 4 gateron (cherry knockoffs) brown keyswitches for the shoulder buttons and anything else i can cram in there, all powered by an atmega328p. now im starting to question whether or not i2c is fast enough to move all that data. one way to find out is to build something. its less frustrating than working with linux.
-
i read but i really dont like to collect books (except for ebooks which just take a tiny bit of drive space and arent too much trouble to keep around). when i buy a real book, i usually read it once and then drop in a donation bin or on one of those book exchange racks you see at airports and the like, or give them to somone who wants to read it. if i wannt to read it again i either buy another copy (or find one in a book exchange/thrift store), read it, and then find it a new home. some readers like to show off all the books theyve read by having really large book shelves but thats not even remotely practical.
-
What would be your plans if you had a trillion dollars?
Nuke replied to Piatzin's topic in The Lounge
definately evil lair on cruithne. -
i dont really see any point when i have the gcc toolchain installed and the knowhow to use it. ive never seen a graphical programming environment that didnt start to crash as soon as you tried to do any serious work with it.
-
i usually use nano. on winders its strictly notepad++.
-
this one flies like a dream. at least compared to the other helis i built. i also found out that so long as you put a 2 axis joint on each end you can use a strut to connect the linkages.
-
i got my helicopter to lift off. i think the problem were my glider wings which havent been updated in a really long time. i used a segmented rotor blade and got a lot more lift out of it. control is still rather difficult. you cant control the cyclic fast enough to compensate for any rotation near the ground (joystick mapped servos would really help here). there is no fly by wire here except in the yaw axis since thats just a tweakscaled rcs thruster (a proper variable pitch tail rotor is a possibility). helicopters get easier to fly once you get out of hover though. i also think i need custom mast, swashplate and linkage parts to simplify the mechanism. i can just model those after the parts on my rc heli. i also found another issue after a rather successful and controllable flight at 0.5g, any manuver which changes the pitch of the blades (pretty much anything but yaw) will make the blades loose energy. i think real helicopters govern their throttle to maintain a constant rpm for consistent operation. being spun up by monoprop thrusters doesnt lend it to easy control, and its very hard to gauge the rpm of the blades to try and keep them constant. so far all ive been able to do is max out the engines and hope for the best. of course that also poses a problem as weird things start happening if the rotor spins too fast. like the lift force gets inverted which turns out causes a lot of dead kerbals. latest linkage configuration
-
i made a helicopter which works like a real one. you got a swashplate and collective control. monoprop engines to spin up the blades. a big rcs thruster where the tail rotor would normally go. doxking washers support both the main rotor and swashplate (to transfer cyclic control to the blades), the linkages use an additional 2 washers each (x6) and required the use of docking ports to connect them. i kind of wish you could use struts as linkages but that only taunts the kraken. unfortunately its not working very well and some optimization needs to be done, but i was hoping to inspire others. i kind of wish i could map a joystick to the servo set points so that its somewhat easier to control.
-
just glue the emergency procedures manual over the hole.
-
my 3d printing rig is multiboot. i installed a grub partition and pretty much use it to boot everything, because it can. grub is powerful if you know how to use it.
-
automatic updates are the main reason why i dont use windows 10. when i want to use my computer the last thing i want to do is update for a half an hour and forced reboots at the worst possible times. i will have transitioned to linux by the time support ends on 7 and 8.1.
-
ive cleaned deer in the past and you normally chuck the entire spine once you removed the meat from it. not sure how it is with other animals.
-
if you want to get really low level get you an arduino and one of those ili9341 lcd screens. you have all kinds of bandwidth constraints do to the spi interface so you have to do a lot of sprite swapping with the background to keep things fluid. not to mention a lot less memory, a lot less storage, and a rather sluggish cpu.
-
the only gui library ive ever been able to use is iup. its mostly for lua but i do believe you can use it in c/++.
-
sdl just gives you a put pixel function iirc. but it gives you everything else you need to make a game (sound, input, etc). id go with opengl and sdl (you kind of have to since sdl provides you a gl canvas that opengl can render to). i used both libs in my c++ game engine that never really got past the line draw phase and a lua version that has textures. map your sprites to polys and you can render them in any orientation and use the z axis to handle sprite render order, you also have access to fast alpha blending for weapon effects (its actually how i handle my 2d elements). of course my knowledge of opengl doesn't really go past old legacy versions where you dont even have shaders (like my lua engine only uses opengl 1.3 and i get my rendering context from iup rather than sdl). you might also want a bitmap library, but i like to use tga bitmaps since the format is just an 18 byte header and the rest is pixels. you just load the file, read the first 18 bytes to get the bbp and image size and load the pixels into a dynamic array (malloc). if you use opengl compressed textures become an option but i think for a 2d game id want uncompressed images.
-
theres no reason c++ cant be as fast as c. its just easy to bog yourself down in oop overhead. its not a lot of overhead (especially with so much code running on vms as opposed to being compiled). of course the thing i like about c++ is that it doesn't force you to use classes for everything. you can run your oop code and use functional code when you really need to push it. i actually went and looked at my interpreter code. the entire vm is pretty much wrapped up into a single c++ class, its actually very lightweight since i wrote it to run on an 8-bit mcu. its just full of a lot of low level stuff that wouldn't look out of place in c. c is still a good choice for those tasks though. even if not for performance reasons (performance in this case has more to do with the programmer than the language they are using). for one its good to approach a low level problem with a low level language, and c is about as low as you can go before you have to start using asm.