Search results

I can't believe that this hasn't been suggested before, but can we please get an LUA based interface? Secondarily, LUA based in-game scripting in the 'personal computer' blocks is a crying desire for me. This game totally reminds me of the game notch talked about when he was talking about...

Source that - because if that's true, I'll be writing LUA ai that does all sorts of crazy stuff.

Right, and the developer time isn't intended to solve the problem you had when you found another solution - it's to solve the problem future gamers will have so that the game is more accessible and more fun for them. Requiring external VOIP is fine for hardcore gamers who will pay for it. It's...

I don't think they should go for the core at all - I think they should go after the nearest heat signature once armed. 'hot' items in order of preference - EDIT: top priority should be - Ejected chaff =) Engines in use weapons in use other missiles in flight charging warp drive cores...

This is a great idea, and really necessary. It's simple and straightforward and easily manipulable.

Oh I love that light sticks could be the antenna blocks for this. That's grand. Now that I think of it, the 'channels' thing is actually somewhat complex and would require a mumble api or somesuch, because those are essentially 'channels'. That's a lot of audio stream combining.

here's a refinement to the idea - allow the effect beams to be used as primary systems when unlinked with a flat power. That way you don't have to multiply the blocks just to get the effect.

Good to know

here's an idea how to do it - add a new activation block that requires the user to activate it with a key that matches the 64 character string.

The idea is that your own radio is tuned to a 'code' - and you can't hear any broadcasts that are not on your tuned channel (nor can anyone else hear yours). A radio tuned to the default "null string" channel would receive null string chat. Honestly, I far prefer radial sounds/comms...

Which is fine - right? Your ship is balanced because it's designed to suit the role. You could not do that and also be armored, shielded and have massive weapons. The point is that with 4 charged one block jumpdrives, someone can. I'm suggesting removing that so that they have to change...

Follow up to this idea : Crew could be used for the complex script part of behaviours. Crew could be given conditional orders that they execute with a set of values

Witness games like H1Z1 that have integral voice chat. If you put it in, the game affords players tending to use your own systems. Make it natural to the game, and players will naturally use it. Players use these external systems now because they have to.

Oh no no, I mean that the block in question behave that way if XOR logic is sent to it - meaning if a mix of signals is present as inputs. Yes god I know. I spent 2 hours last night coming up with a simple logical circuit to handle some door / dock functions. It's a chore.

The mechanics are identical. When a ship core docks with a dock, any named storage on the entity connected to that dock should be visible to the ship.

I suggest having integrated voice chat that is basically radio. method - If player is in a ship, ship must have a radio module. If player is not in a ship, they must have a radio module on their hotbar. If player is in a station, they must have a radio module or must be using a radio module...

I should be able to set a dock as a target for a cargo container to pull from, so that ships can dock and have cargo automatically transferred based on the pull rules. EDIT: This should be specific to cargo containers on the docked ship that are slaved to the ship core. This is actually from...

It should be possible to access the host ship's named cargo when docked This way a ship can dock and then transfer cargo to the host ship without the player having to get down, dump, get up again.

Bench, how is that different from what it is now? I use a single named 'drop off' module and then have (arbitrary number) of other modules that pull all from it. I think I've already created a system that does what you state as an objection, so - does the idea have merits otherwise? I think...

Well ... not exactly but mostly yes. Basically scout ships would have to be designed around rapidly regenerating jump. People will adapt. One jump drive per ship is a fine solution for me - if not, you won't be able to prevent someone charging 3-4 spare 1-block jump drives.