Search results

Careful not to kill small shipyards :-)

True - although I do wonder if setting Hitpoints for a block at 0 means that missiles would go after blocks with actual hitpoints; therefore exposing a faction block's location right away. On the other hand, that doesn't address the issue of constructing invisible stations, to prevent others...

Ah so the underlying issue, is that players can create almost invulnerable stations by constructing it primarily of transparent blocks, and then "hiding" the faction module far away from the station marker? Hmm, that's creative. Although build mode does reveal the location of those transparent...

It's it already easy to destroy poorly defended stations?

So, a modified multi-sector version of Battle Mode?

Yea, the ideas of fuel and food are hotly-contested topics, of which I do not believe has the support of developers. It's probably not appropriate we turn this into Yet Another fuel thread either. Hence the decay angle; it leverages pre-existing game mechanics, as blocks are worn-down by either...

Was a single solution necessary, or even appropriate though? After all, that article is over 6 years old, yet its relevance is timeless. There were some mild suggestions too: the free -vs- paid downloadable content and dynamic maps. Although neither are truly that relevant in SM's context. What...

I can't agree with total negligence, as Schine staff are very approachable for support related needs; speaking first as a player and then later as a server owner. Further, recent changes to the game have improved the experience for all: Chunk32 proved to be a positive performance improvement...

I'm inclined to agree with Jasper1991... The illusion of participation: It feels there's a loose illusion of player participation towards development. Although as time goes on, player contributions in the development cycle seem much more coincidental. For the most abundant illustration of this...

There's also: /sector_chmod 2 2 2 + peace

Was the artist OK with your duplication? Did you sell or give away your duplicate, as your own original work? Did you distribute duplicates in a medium where the original artist is competing for compensation? Did your app also determine how any internal wiring was run? Did the printer apply such...

It would be nice, if the existing "CONTROLLING" /player_info attribute would list what a player is aligned and/or attached to (e.g. gravity), when the player is not inside a core. We do have the "CONTROLLING-POS:" attribute, which changes when an astronaut moves around...but without parsing...

Fair enough - although as the engine stabilizes, and more servers can host mixed creative/survival on the same instance, the need to limit movement of creative players only to pre-authorized ranges is going to become more of an issue. As for addition/removal of commands, check out what I added...

/change_sector should be limited only to admin-authorized sectors. Otherwise creative players can simply jump out of a locked sector to spawn an infinite amount of materials in survival. You may also want to take a peek at: Recognized - /add_admin_allowed_comand

I would prefer both a mandatory notification option upon edits, and a changelog which includes the quantity of like/funny/agree/etc relevant to that particular revision. This enables OPs to continue updating the original posting as a conversation evolves, while enabling anyone to determine which...

Would be neat if remotes could transfer stats...then your main mining ship could host displays w/ the desired info.

From the page you linked: and from the bottom of each webpage they have If they can't update their website in over a year and a half, how truly active is "Razer"? Why should effort be expended upon something that appears to be neglected/dying.

The game uses Axis Aligned Bounding Boxes (AABB). There are other standards as well: Minimum bounding box - Wikipedia, the free encyclopedia

Oh hell yes! Afterall, the routine's octree math/coding has already been implemented in the pre-existing command: /load_sector_range In-fact, your suggestion really should be a separate thread. :)

Request/Goal: Extend upon code from pre-existing routines /sector_chmod and /load_sector_range, to add support for specifying ranges to /sector_chmod, through a new command: /sector_chmod_range Currently: In order to designate a particular region (range) of space as + peace, + protected, etc...