Jump to content
Stray Fawn Community

Lurkily

Moderator
  • Posts

    1,540
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Lurkily

  1. I like the shake test. Just shift the brain back and forth along an axis the player can alter. Give the player to change the frequency of the vector change, speed of motion, and whether it's back-and-forth on a player-defined axis, or twisting left and right.
  2. Honestly, I haven't paid attention. They can't be too bad if I haven't noticed them at all.. I don't mean to pan them; I just don't pay a lot of mind to lore in most cases, so they just blend in.
  3. AND gate; if 1 + 2, output 3. 3 should be the firing key. If I'm understanding you, you'd prefer to do away with logic blocks, and handle the logic in some other interface? I do kind of like the idea that damage to your drone can break its logic, though.
  4. Functional, but not adjustable, and definitely too short at max range, and dependent on terrain. I'm looking for 'distance from the center of gravity.' My plan is to have a very high-speed orbiter that adjusts its forward speed to maintain an orbit, instead of upward thrust. Increase desired altitude if you detect land below, and decrease it very slowly over time. It's not currently possible since the feedback just doesn't exist.
  5. Interconnections sound nice, but unless you're flying a brick, I feel link it would still wiggle like a bowl of jello. Long narrow ships (Like a giant upright walker I'm trying to build) will still bend, with all connections on a linear plane. We already have a few self-reinforcing physics issues (many structs connected to a hinge, for example) and I worry that multiple interconnections risk exacerbating that. I also just don't like circular interactions being in place. I'd like to see lots of new features and awesome stuff, and while circular physics isn't totally avoidable or necessarily a time sink, there's the potential that it might become a sticky issue, diverting time from other things. I'd like to see other things considered first, though I realize I have zero sway in the dev's planning process. As for a tread, rotation of free hinges seems to 'propagate' from hinge to hinge. One turns, and the whole chain bends. I haven't had success using them as a chain. Regardless, the connections between them will not collide. Spikes of terrain will pass through it. I've had some success with 'wheels' (There's a gif on the forum of a wheeled, wall-climbing rover) but they have their issues, too.)
  6. Orbits are sketchy. If you have orbits, players are going to want to alter orbits sometimes, drop rocks on enemy structures. It introduces gameplay elements that may be worth it - but you'll want to make a plan for everything that might be done with it before you start, just so you know whether or not it's worth beginning. Honestly, you'd have to increase scale a lot before I can see orbiting bodies being terribly interesting.
  7. What about an altimeter? I'd like a sensor that reads your altitude and activates a keypress if your altitude is below a certain value. Like dynamic thrusters, you should be able to lower or raise that value with a keypress.
  8. The solution for rigidity that I Iike (Yeah, I'll keep pushing it) is 'chassis' blocks that don't have physics interaction, and exist in a separate layer. Keep the chassis extremely rigid, but expensive in terms of mass and maneuverability. Have some big and awkward pieces that are more mass-efficient to provide some build challenges related to the size or awkward shape of the chassis. Only allow entire chassis pieces to be placed or removed as a unit, but when connecting parts to them or when being destroyed, treat them as a group of 1x1 blocks - allow attachments to any part of it, not just the center, and allow any part of it to be destroyed. This introduces the possibility of breaking a ship's spine. Being high-mass, a broken spine may do additional damage during maneuvers. Additionally, you might have damage done to the chassis also propagate to connected blocks, including connected chassis blocks. (Not divide itself among them, but propagate to them, so more total damage is done.) This would make exposed chassis a severe weakness.
  9. Good catch. I suspect the game is triggering the weapon cooldown when it TRIES to fire, instead of when it successfully fires, for some reason.
  10. I like it. Try turning off that gravity sensor, and see if those . . . outriggers? Will tip it over and climb the wall. See if using hinges instead of thrusters for their attitude control works. As long as they return to downward-facing when not under thrust, and the hinge doesn't stress the hinge so much that the whole thing explodes the moment you use it, it might just work out. How much logic do you need? It looks like you could manage with less than twenty keys and less than ten blocks, but I'm only basing that on what I see. I've used up to two keys and two blocks each for WASD before. That's 8/8. Weapons. Shields need a key and maybe a block for the toggle. Magnets might need two keys, the toggle for repel, and if not repel, then attract, twelve keys, eleven blocks. I assume the detectors keep it aloft if it's near terrain? These can directly link to upward thrusters though, so they shouldn't need extra keys or blocks. Each sensor on the pod needs keys, but they can be a direct link, and you can use disconnect blocks on each of those to duplicate the key selections without them triggering each other. Assuming you didn't, that's three sensors directly triggering thrusters - six more keys for a total of 18 keys, 11 blocks. I find keeping a notepad of my logic helps a lot. My thrust looks like: Thrust forward, left side: Numpad 4 Thrust forward, right side: Numpad 5 Thrust back, left side: Numpad 1 Thrust back, right side: Numpad 2 W: n4/n5 A: n1/n5 S: n1/n2 D: n4/n2
  11. I noticed the flamethrower/sparker issue. Not the laser issues. I had to go and test them, but you're right. They do fine if they fire from inside the laser, but yeah, that needs a fix.
  12. Lasers are great, for the right thing. A short-beam laser is great for clearing terrain. (wider beam misses fewer specks.) A long-beam laser with a push upgrade and maybe a range upgrade can keep exploders at bay, and their range is so long I can't see the end of them. Exploders can damage you through shields and are hard to handle autonomously, so they're my drone's nemesis. Towers aren't great on terrain because they all waste effort focusing on the terrain under your cursor. Fixed banks of lasers will serve that better. I have a number of surface-roamers whose task it is to destroy all planetary mass. The best solution I've found for it is a bank of downward-facing lasers. Long beam, range upgrade, digging. (If I had a dual beam/digging/long range epic, if only.) As always-on weapons, they're not as damaging to enemies as some other things, and I find myself okay with that.
  13. Keep connections short. Interlace components so they don't split into 'strings'. Try not to have parts suspended a long distance from their connection points. In the current build, try using magnets set to attract to minimize flex.
  14. Springs are like any other block - but the strut connecting them to their source is a spring instead of a normal strut, and seem to be able to take a terrain impact much better than most other parts. The 'floppiness' of the connection can be configured, so it can behave like a rope, if you prefer, or like a very stiff connection. As for magnets, you just need to configure them properly. Turn them off with the fire key (if not Mouse 0, then output the repel button) or put them behind the guns. I don't find them to be too useful as a defense, not quite.
  15. I especially liked seeing the enemy bullets hit and destroy each other. I didn't notice that this could happen until I made that .gif.
  16. I wonder how computationally expensive it would be to apply physics to all terrain? The entire planet. Calculate the center-of-mass of all terrain, just as you do with drones. Any modification to terrain updates that measurement. (This wouldn't have to be updated frame by frame, once every few seconds would do.) Apply physics to cut-free pieces of terrain. If at all possible, calculate where stress on the terrain would be greatest. Overhangs and thin protrusions should ovbviously be weak, and it would be interesting to see the planet collapse as you dig, introduce a new danger to digging straight to the core. Different types of soil could have different thresholds at which they break free and fall. Once a cut-loose piece of terrain comes to rest, you can fuse it back to adjacent terrain, to limit the amount of physics calculations. This opens the gate to various things, such as explosions throwing chunks of debris, instead of just excising a sphere of mass. Impacts could crumble rock formations, cause landslides. As you damage a planet, debris and landslides would tend to fill in the holes you dig,, and tunnels might face the danger of collapse; you'd run the risk of your drone being buried.
  17. I loaded it up, and with some modifications made later it's having issues climbing. I'll have to rebuild. I was planning to rebuild bigger with magnets for stability, so this'll be a good excuse.
  18. The URL is: https://i.imgur.com/XilQUQ8.mp4 Let me know if you can't get to it, I may have to throttle imgur until it cooperates. The link in the img tags is a proper gif, but same host.
  19. The magnets to maintain cohesion? Glad to see it working well - magnet-based battleships are also on my to-do list.
  20. Remember I mentioned I was going to play with vectored thrust? This is small and unstable (probably in part because of low mass,) but it works, it freaking works. Thruster rotation looks herky-jerky because I use the impulse logic to slow down rotation so I don't get constant sway with the gravity sensors. 0.2s delay, 0.1s rotation. Less responsive leveling out, but it works better. Now I just have to figure out how to make it work without gravity sensors, so that it can navigate walls and ceilings. The drone is attached. Hit tab to engage automatic roaming. Be aware if it comes up against a cliff, if can and will go into an uncontrollable spin. Guns face backwards because it's fast, and I want it outrunning the explosive units when they detonate. https://i.imgur.com/Qu40xrQ.gif Example.nimbatusdrone
  21. I like it - but I couldn't use it. I love making smart, autonomous drones, and both being a tower, and being cursor-controlled would make it useless for that. Heat-seeking is my preferred trait, and it's rare, and non-tower isn't too common. My ideal epic would be a third-tier gun (shotguns are too recoil-ey) with heat-seeking, cluster, and bounce. I find that cluster can often stand in for a digging upgrade, it's great at chewing up terrain.
  22. Magnets are to repel projectiles? I've worked on a lot of roamers, and I keep trying to get the right balance that can navigate any terrain and stick to it. My two tests of a roamer's ability is to first have it circumnavigate the text chamber unassisted, and to second build a sub-bot that drills a very wide hole straight to the core, and have the roamer circle the world, dive into the hole in the core, then circumnavigate the interior and climb out the other side of the hole. I find that gravity sensors almost never help the second test. Most of my ships have to be fully sensor-based in order to be really autonomous without risking getting stuck in weird terrain or circumstances. And . . . now I'm having thoughts about motorized hinges and vectored thrust. Hmm. Thank you.
  23. I do have a lot of wishes, but the game has a lot that it lacks. I don't mean to knock the devs. We're not even into alpha yet, so there will be things missing, and that's okay. A few of these (wide-angle directional sensors) the devs have mentioned as being things they plan. Others (hinge limits, better impulse blocks or some kind of 'macro' block) have been requested by others. This list, though, is specifically the limitations that prevent me from creating crazy, off-the-wall bonkers shit like functional digitigrade legs that adjust their feet's facing to climb walls.
  24. On many keyboards, the numpad acts as a directional pad unless num lock is on. Hit num lock, and see if that switches them to numerical values. You can assign numberpad numbers separately from the alphanumeric numbers (the 1-through-zero row) so it really helps expand your capability with complex drones.
×
×
  • Create New...