Server Configurations

[Glutton]

Hey folks,

I've been experimenting with some server configurations. I wanted to get some thoughts and opinions about what you like and dislike in a server setup. Some of the things I've been messing with are:

- Universe Day
- Collision
- Sector Size
- Dropping money upon death
- spawn rate for shops and such

What have you experienced to be a positive or negative on servers or in your own configurations? Did you notice performance increases with no Universe Day set? Did allowing money to be dropped upon death help or hurt pvp. Do you like large sectors?

Just wanted to get some thoughts rolling while I mess with it.

Thanks!

 

[Qweesdy]

My opinions...

1) To avoid lag, server speed limit needs to depend on the client's networking speed (not the server's). In general, "about 200" used to be about right for most people; but now players can use overdrive effect to go faster the server's speed so I'd recommend setting the speed limit to about 150 instead.

2a) For a server, custom blocks prevent people from shifting their ship from one server to another (including to/from single-player); and prevent people from testing with (and suggesting improvements to) the game's default blocks. Custom blocks should be banned on all normal servers until the game is close to the end of beta (and it's still in alpha, so that's going to take a while); and should only be used by people trying to find a better defaults for the game.

2b) For similar reasons; if/when Schema adds a "mod API" its use should also be banned on all normal servers until the game is close to the end of beta; and should only be used as a tool for people creating suggestion to the default game, and/or people who are privately working on a mod for after beta.

3) The "TURNING_DIMENSION_SCALE" setting is a bad work-around for ship balance issues that should be fixed properly instead (e.g. a huge ship that's 99% thrusters should turn faster than a tiny ship that is only 1% thrusters). I'd nerf it to oblivion ("TURNING_DIMENSION_SCALE = 0.0") and hope the (planned) thruster changes come sooner rather than later (and aren't insanely broken too). However, the game's turning speed is too fast and too twitchy for tiny ships; and while you can't fix the turning speed for tiny ships you can fix it for large ships by setting "TURNING_DIMENSION_SCALE" to about 0.6.

4) The default values for "PHYSICS_LINEAR_DAMPING" and "PHYSICS_ROTATIONAL_DAMPING" are too low; which means that if your ship ever goes flying off by itself (either it was bumped by something else, or you accidentally pressed 'R' while flying for the 9th time today) it takes a very long time to stop. Increase these values to make the game less annoying in these situations. Note: I do realise that for a realistic simulation they should be zero, but people play games because games are more fun than reality, so...

5) Universe day is probably best left "as is" - it doesn't cost much and it's worthwhile to make the game more interesting for players.

6) Unfortunately, collision damage should probably be left disabled. In theory it'd be awesome. In practice it's too slow and you do not want to encourage deliberate ramming.

7) For sector size; I prefer setting it to about 5000, which results in sectors that are about 16000 meters wide. If you increase it too much normal travel becomes excessively boring (travelling for ages to get nowhere) and jump drives become over powered (8 sectors is not far when sectors are small, and a very long way when sectors are very large). If it's too small (e.g. the default value) then you end up with everything/everyone too close together.

8) For planet size; the default value is too laggy and too small. A good value isn't possible, so give up and leave it as default.

9) The trading guild's shops are broken (e.g. don't update at all unless a player is near, and constantly running out of stock or running out of money). It doesn't matter how you set them up they will still be broken.

10) For number of blueprint slots; if you set this too low then people will just upload from their local blueprints all the time (wasting bandwidth). Disk space is cheap (and uploading is slow/annoying), so give people plenty of blueprint slots (e.g. 20 or more). Also make sure "DEFAULT_BLUEPRINT_ENEMY_USE" and "BLUEPRINT_DEFAULT_PRIVATE" are set to true. If I see pirates trying to fly around in a turret that doesn't have any thrusters, I will assume the server administrator is a noob.

 

[Megacrafter127]

My opinions...

1) To avoid lag, server speed limit needs to depend on the client's networking speed (not the server's). In general, "about 200" used to be about right for most people; but now players can use overdrive effect to go faster the server's speed so I'd recommend setting the speed limit to about 150 instead.

2b) For similar reasons; if/when Schema adds a "mod API" its use should also be banned on all normal servers until the game is close to the end of beta; and should only be used as a tool for people creating suggestion to the default game, and/or people who are privately working on a mod for after beta.

10) For number of blueprint slots; if you set this too low then people will just upload from their local blueprints all the time (wasting bandwidth). Disk space is cheap (and uploading is slow/annoying), so give people plenty of blueprint slots (e.g. 20 or more). Also make sure "DEFAULT_BLUEPRINT_ENEMY_USE" and "BLUEPRINT_DEFAULT_PRIVATE" are set to true. If I see pirates trying to fly around in a turret that doesn't have any thrusters, I will assume the server administrator is a noob.

1) so the networking speed is determined on connect and then the max-speed readjusted?

2b) you do know modders will then make a mod that enables the modding API, effectively negating any point. Also, if a list of all loaded mods is transmitted on connecting, the client/server should just refuse to finish connecting due to modding incompatibilities.

10)the only exception being setting blueprint slots to 0 to disable them alltogether.

 

[jayman38]

Thoughts on dropping money:
0. To establish numbers for the following points: The dying player loses 10 percent of their money when they die. So if a player with 25k dies, they lose 2.5k. If a player with 250m dies, they lose 25 million.
1. The money dropped should probably be a server-configurable percent (probably default to 10%?) of the lost money. So the first player would leave behind a pile of 250 credits. The second player would leave behind over 2 million. (What a payday!)
2. The money dropped should probably have a soft limit, beyond which, the increase drops exponentially. So while the first player drops 250 credits, the second player might hit the 1 million mark, and then only get up to about 1.15 million credits in the dropped pile. The more wealthy player will still be a good target, but won't necessarily make their killer filthy rich on death.
3. Faction bounties might automatically give the killer (and their helpers) money on the death of a known enemy.

There should probably a killer-assist mechanic in the game that records who helps who kill someone, so that credit for the kill can be distributed kind-of fairly. (Example: A bounty on player A is 50 credits. Player B, C, and D from an opposing faction attack and kill player A. Everybody gets in at least 3 shots of any damage, or at least 2 shots with a minimum of 100 damage each. Player D makes the killing shot. Player D gets 25 credits. Players B and C get 12 credits each for the assist. Maybe player E gets to the party late and gets in one single hit on player A, but will get no bounty reward or assist credit, due to his limited involvement.) You'll still get kill-stealing, but it won't be as bad.

 

[FunnyBunny14]

Somebody mentioned modderd? The block editor and custom configs/textures are the first step towards the API, and when at least the block editor and custom configs are finished, I'll give a go at making my own mod.

Wait... @Qweesdy why are you against modders? Seriously, that would cause a lot of bad things to happen to our community, and I really doubt schema needs suggestions. Besides, we can't use it to suggest things because it is a lot harder to code a completely new feature than simple messing around with an API (I think).

I also don't know how you figure that if you set sector size to 5000 makes a sector 16000 wide. The sector size is nothing else than how long one side of a sector is in blocks, so in your example it would be a sector of 5000 x 5000 x 5000 blocks. The longest side is then 8660 blocks (the longest diagonal).

The speed limit really shouldn't be too high. I'd recommend not setting it higher than 100, because above 150 strange things start to occur (ships flying through station, etc.)

I'd personally recommend changing the sector size to 2000, which will make it seem a lot bigger already. Also just keep the server speed at 75 then, overdrive can still boost to 150.

 

[Megacrafter127]

The speed limit really shouldn't be too high. I'd recommend not setting it higher than 100, because above 150 strange things start to occur (ships flying through station, etc.)

I only start to get those issues at 250+km/h

 

[FunnyBunny14]

I've already got them at 150 m/s. I don't suppose you've ever flown directly into a planet a default speed with overdrive? It isn't fun, trudt me. I had to literally dig my ship out of the planet once.

 

[Viridis00]

Hey folks,

I've been experimenting with some server configurations. I wanted to get some thoughts and opinions about what you like and dislike in a server setup. Some of the things I've been messing with are:

- Universe Day
- Collision
- Sector Size
- Dropping money upon death
- spawn rate for shops and such

What have you experienced to be a positive or negative on servers or in your own configurations? Did you notice performance increases with no Universe Day set? Did allowing money to be dropped upon death help or hurt pvp. Do you like large sectors?

Just wanted to get some thoughts rolling while I mess with it.

Thanks!

I like to keep universe days the same, collision off, sector sizes of 10k, default money dropped on death, and shop spawn rate was something like half the default spawn rate. Large sectors and low spawn rates for shops make them more special. Now that we have gates and jump drives, travel is no problem. I also keep my max planet sizes small for performance issues. I set my speed to something like 200, but I'm probably going to revert back to 100 because I think I've been getting non-responsive server messages when I go too fast.

I honestly feel that the adjustable sector sizes are literally one of the best features we've ever gotten in SM. It really makes space feel more like—
Space.

 

[Glutton]

My opinions...

1) To avoid lag, server speed limit needs to depend on the client's networking speed (not the server's). In general, "about 200" used to be about right for most people; but now players can use overdrive effect to go faster the server's speed so I'd recommend setting the speed limit to about 150 instead.

2a) For a server, custom blocks prevent people from shifting their ship from one server to another (including to/from single-player); and prevent people from testing with (and suggesting improvements to) the game's default blocks. Custom blocks should be banned on all normal servers until the game is close to the end of beta (and it's still in alpha, so that's going to take a while); and should only be used by people trying to find a better defaults for the game.

2b) For similar reasons; if/when Schema adds a "mod API" its use should also be banned on all normal servers until the game is close to the end of beta; and should only be used as a tool for people creating suggestion to the default game, and/or people who are privately working on a mod for after beta.

3) The "TURNING_DIMENSION_SCALE" setting is a bad work-around for ship balance issues that should be fixed properly instead (e.g. a huge ship that's 99% thrusters should turn faster than a tiny ship that is only 1% thrusters). I'd nerf it to oblivion ("TURNING_DIMENSION_SCALE = 0.0") and hope the (planned) thruster changes come sooner rather than later (and aren't insanely broken too). However, the game's turning speed is too fast and too twitchy for tiny ships; and while you can't fix the turning speed for tiny ships you can fix it for large ships by setting "TURNING_DIMENSION_SCALE" to about 0.6.

4) The default values for "PHYSICS_LINEAR_DAMPING" and "PHYSICS_ROTATIONAL_DAMPING" are too low; which means that if your ship ever goes flying off by itself (either it was bumped by something else, or you accidentally pressed 'R' while flying for the 9th time today) it takes a very long time to stop. Increase these values to make the game less annoying in these situations. Note: I do realise that for a realistic simulation they should be zero, but people play games because games are more fun than reality, so...

5) Universe day is probably best left "as is" - it doesn't cost much and it's worthwhile to make the game more interesting for players.

7) For sector size; I prefer setting it to about 5000, which results in sectors that are about 16000 meters wide. If you increase it too much normal travel becomes excessively boring (travelling for ages to get nowhere) and jump drives become over powered (8 sectors is not far when sectors are small, and a very long way when sectors are very large). If it's too small (e.g. the default value) then you end up with everything/everyone too close together.

10) For number of blueprint slots; if you set this too low then people will just upload from their local blueprints all the time (wasting bandwidth). Disk space is cheap (and uploading is slow/annoying), so give people plenty of blueprint slots (e.g. 20 or more). Also make sure "DEFAULT_BLUEPRINT_ENEMY_USE" and "BLUEPRINT_DEFAULT_PRIVATE" are set to true. If I see pirates trying to fly around in a turret that doesn't have any thrusters, I will assume the server administrator is a noob.

A lot of great feedback. A lot of what you've mentioned I haven't even looked at yet. I was planning on messing with the Blueprints and Physics after I got an idea of what the universe was going to be like. I really appreciate info.

I've given up on Collisions. That was a fun mess, but I think I'm good. Now that I know the Universe Day is not too resource intensive, I'll keep it as is.

Awesome stuff.[DOUBLEPOST=1413912421,1413911830][/DOUBLEPOST]

I like to keep universe days the same, collision off, sector sizes of 10k, default money dropped on death, and shop spawn rate was something like half the default spawn rate. Large sectors and low spawn rates for shops make them more special. Now that we have gates and jump drives, travel is no problem. I also keep my max planet sizes small for performance issues. I set my speed to something like 200, but I'm probably going to revert back to 100 because I think I've been getting non-responsive server messages when I go too fast.

I honestly feel that the adjustable sector sizes are literally one of the best features we've ever gotten in SM. It really makes space feel more like—
Space.

Agreed. I love the ability to change the size of the sectors. It makes such a big difference.[DOUBLEPOST=1413913110][/DOUBLEPOST]

I've already got them at 150 m/s. I don't suppose you've ever flown directly into a planet a default speed with overdrive? It isn't fun, trudt me. I had to literally dig my ship out of the planet once.

I'll be experimenting with the size and speed a lot. It does seem like a little goes a long way with the sector sizing. I'll keep that in mind

 

[Qweesdy]

Wait... @Qweesdy why are you against modders? Seriously, that would cause a lot of bad things to happen to our community, and I really doubt schema needs suggestions. Besides, we can't use it to suggest things because it is a lot harder to code a completely new feature than simple messing around with an API (I think).

Could you imagine what it'd be like if every server had a different set of mods? It would mean:

• For a lot of bug reports, Schema won't be able to tell if the bug was caused by the default game or a buggy mod.
• Most people won't be able to figure out if the default mechanics are good or bad and provide useful feedback (because servers aren't using default game mechanics)
• The StarMade wiki will be permanently useless (as it'd contain information for the default game, not for "random mod of the week"); so no new players will be able to figure out game mechanics easily.
• Instead of being guided by community feedback, mod developers will do whatever they feel like. This will mean that a large number mods will be crappy gimmicks that most people don't like and/or are too laggy ("Oh yay, a big laggy space whale in my face caused by a stupid mod that the server owner thinks if funny and everyone else hates!").
• Because the game is alpha and constantly changing, any/all mods will be broken every week; frustrating and alienating the players and gaining StarMade the reputation for being unstable (even if the default game is not).
• Suckers will make ships for a specific set of mods, and will be screwed when they want to shift to a different server (because the server they were playing is broken every week because of mods).
• Smart people will avoid making ships that depend on a specific set of mods, so the mods would be mostly pointless for these people anyway.
• There will be arguments between Schema and mod developers every time Schema tries to implement new features ("OMG, Schema total stole that from a Dave's mod!").

For a game developer's perspective; the best time to add a mod API is when you need to revive interest in a dying game. I'm an impatient prick and I do wish Schema could finish everything tomorrow; but he really is still going strong (adding new stuff people want regularly) and there's no sign that the game is on a downward spiral or that a mod API is desirable (yet).

Please note that I am talking about actual mods that add or modify game mechanics. I'm not talking about things that make superficial changes (like texture packs, different shaders, different skins, etc).

I also don't know how you figure that if you set sector size to 5000 makes a sector 16000 wide. The sector size is nothing else than how long one side of a sector is in blocks, so in your example it would be a sector of 5000 x 5000 x 5000 blocks. The longest side is then 8660 blocks (the longest diagonal).

There's grey diamond markers in the HUD showing how far until the next sector (and the sector number), in each of the 6 directions. If you set the sector size to 5000 and use these grey markers to find the exact middle of the sector, you'll find that the distance from the middle of the sector to all edges is 5.3 Km. 5300+5300=16000.

 

[Megacrafter127]

Could you imagine what it'd be like if every server had a different set of mods? It would mean:

• For a lot of bug reports, Schema won't be able to tell if the bug was caused by the default game or a buggy mod.
• Most people won't be able to figure out if the default mechanics are good or bad and provide useful feedback (because servers aren't using default game mechanics)
• The StarMade wiki will be permanently useless (as it'd contain information for the default game, not for "random mod of the week"); so no new players will be able to figure out game mechanics easily.
• Instead of being guided by community feedback, mod developers will do whatever they feel like. This will mean that a large number mods will be crappy gimmicks that most people don't like and/or are too laggy ("Oh yay, a big laggy space whale in my face caused by a stupid mod that the server owner thinks if funny and everyone else hates!").
• Because the game is alpha and constantly changing, any/all mods will be broken every week; frustrating and alienating the players and gaining StarMade the reputation for being unstable (even if the default game is not).
• Suckers will make ships for a specific set of mods, and will be screwed when they want to shift to a different server (because the server they were playing is broken every week because of mods).
• Smart people will avoid making ships that depend on a specific set of mods, so the mods would be mostly pointless for these people anyway.
• There will be arguments between Schema and mod developers every time Schema tries to implement new features ("OMG, Schema total stole that from a Dave's mod!").

1. If a mod is installed on a server, and that mod isn't a modified config file, the client would need said mod too, thus preventing such reports, because users who install mods generally don't blame the vanilla game for a crash, unless they find same crash in the vanilla version.
2. Same as 1. If it is just a modified config it is one of the following:
   1. part of the vanilla game
   2. requires the configs to be synchronized, which could be disabled in a setting
3. same as 1 and 2
4. Such a useless mod won't be used, and if it used 1 and 2 apply
5. It is to be expected of modders, who mod an alpha game, to do their best to keep up. If there wouldn't be such modders there wouldn't be any mods. There also are countermeasures to this: my mod MusicMade e.g. is compatible to EVERY version of SM
6. same as 1 and 2
7. wrong
8. No modder is stupid enough to ruin a game they made a mod for.(Unless we are talking about a serious copyright infringement)

 

[FunnyBunny14]

@Qweesdy the diamonds display the distance to the next sector center.

Also, the mods currently only change blocks, and they can't be bugged unless the game is bugged.

The custom config doesn't require updating a lot (only when game mechanics change).

The API will prevent bugs onfe we get more options.

Players can store blueprints on servers, and most people son't forget that ship used mods.

Players can choose to dowoad the mod, which means they know it is modded.

And the wiki argument is the worst argument of all. The whole point of mods is to change the game, and there is no reason why the wiki wouldn't exist. Other games that support mods also have a wiki, so why wouldn't starmade have one too?

All in all, it really seems like you've played minecraft more than you should have. Lets not forget that starmade is already way better, and that ghe API (which minecraft still doesn't have) will prevent most of the "problems" you just listed.

And expect to see whales in by default, kupu loves them.

 

[Qweesdy]

If a mod is installed on a server, and that mod isn't a modified config file, the client would need said mod too, thus preventing such reports, because users who install mods generally don't blame the vanilla game for a crash, unless they find same crash in the vanilla version.

Wrong. People tend to do whatever is easiest for them. Removing their mods then recreating it in a vanilla world is not easier than submitting the bug without caring and hoping Schema will sort it out.

Of course this does go both ways. For example, if there's bugs in the mod API then people might blame the mod developer when the problem isn't the mod. It can even go both ways at the same time - e.g. users blaming Schema and the mod developer, Schema blaming the mod developer, and the mod developer blaming Schema.

Same as 1. If it is just a modified config it is one of the following:part of the vanilla game

1. requires the configs to be synchronized, which could be disabled in a setting
2. same as 1 and 2

This doesn't make sense. If people are using game mechanics from mods, how are they providing feedback about the vanilla game mechanics? How is this related to bugs at all?

Are you saying people will stop playing the modded servers and (e.g.) build a huge capital ship in single-player just so they can provide feedback about things like big ship vs. small ship balance in the vanilla game?

same as 1 and 2

Um, players being unable to get good information on the "modded beyond recognition by server owner" game they're actually playing, is somehow the same as problems with bugs, which also happens to be the same as problems with getting feedback on the vanilla game's mechanics?

Such a useless mod won't be used, and if it used 1 and 2 apply

Wrong. Different people have different ideas about what is good/bad; and for every mod that a server uses there's going to be half the community thinking it's a bad/useless mod.

Why do you hate StarMade so much that you want to see the community splintered into hundreds of little "mod communities" anyway?

It is to be expected of modders, who mod an alpha game, to do their best to keep up. If there wouldn't be such modders there wouldn't be any mods. There also are countermeasures to this: my mod MusicMade e.g. is compatible to EVERY version of SM

Sure, it's expected that they'll try to keep up; but that doesn't change the fact that they won't be able to or that people (including mod developers) can and will make mistakes.

Your mod is a superficial thing that doesn't change the game's mechanics and doesn't require a mod API. I'm not talking about mods like this. I'm talking about mods that (e.g.) completely change how power reactors work, or add a new "Doomsday Bomb", or add a radically different crafting system - things that actually change the game's mechanics.

same as 1 and 2

Not the same at all. Imagine a mod that adds solar power blocks. You build a ship that uses solar power, will you be able to load that ship's blueprint on a different server (or vanilla) without the mod? Nope, you're screwed.

wrong

What you mean here is that you're not a smart person, and would use (e.g.) the solar power blocks on your ship and end up screwed.

No modder is stupid enough to ruin a game they made a mod for.(Unless we are talking about a serious copyright infringement)

Bullshit. This happened for Minecraft often enough, even though Mojang were smart enough to avoid implementing a mod API (while cunningly pretending they might).[DOUBLEPOST=1413992903,1413991585][/DOUBLEPOST]

Also, the mods currently only change blocks, and they can't be bugged unless the game is bugged.

Currently there is no mod API; so there's no mods that use the mod API. Please note that an API (Application Programming Interface) is a programming interface - e.g. to allow modders to write their own code (in Java or Lua or some other programming language) that controls various aspects of the gam. It is not just some tweaks to a few configuration files.

The API will prevent bugs onfe we get more options.

Wrong. The mod API itself will be buggy, and because the game is still continually changing the mod API will also be continually changing. In addition, the programming done by mod developers will also have bugs. It's like a smorgasbord of bugs.

It will also take a significant amount of Schema time to design, implementing and fix the mod API. The amount of time he's has left to work on vanilla game could easily be halved.

Of course this assumes people have good intentions. Once you've got an API you can't control what people use it for - it'll be like web browser plugins (where a lot of them are malicious). Don't make the mistake of thinking Java is safe (it allows people to use native DLLs, which is how this game is able to use OpenGL, and isn't safe at all). Lua isn't safe either (it allows you to execute native code too).

And the wiki argument is the worst argument of all. The whole point of mods is to change the game, and there is no reason why the wiki wouldn't exist. Other games that support mods also have a wiki, so why wouldn't starmade have one too?

If all the servers are using different mods (that change the game mechanics); will the wiki provide information that's useful for all the people playing on servers (that have different game mechanics to vanilla)?

All in all, it really seems like you've played minecraft more than you should have. Lets not forget that starmade is already way better, and that ghe API (which minecraft still doesn't have) will prevent most of the "problems" you just listed.

More like Minecraft doesn't have a mod API because of all the problems I've mentioned.

 

[Megacrafter127]

Wrong. People tend to do whatever is easiest for them. Removing their mods then recreating it in a vanilla world is not easier than submitting the bug without caring and hoping Schema will sort it out.

My point was not that people remove their mods to test it, my point was that people never accidentally mistake a modded version with an unmodded version.

It can even go both ways at the same time - e.g. users blaming Schema and the mod developer, Schema blaming the mod developer, and the mod developer blaming Schema.

That would be the case, if there wouldn't be a fast and easy way of contacting schema.

This doesn't make sense. If people are using game mechanics from mods, how are they providing feedback about the vanilla game mechanics? How is this related to bugs at all?

Are you saying people will stop playing the modded servers and (e.g.) build a huge capital ship in single-player just so they can provide feedback about things like big ship vs. small ship balance in the vanilla game?

I am expecting the vast majority of players to not ONLY play modded Starmade.

Um, players being unable to get good information on the "modded beyond recognition by server owner" game they're actually playing, is somehow the same as problems with bugs, which also happens to be the same as problems with getting feedback on the vanilla game's mechanics?

This is what mod-specialized or server-specialized wikis are for.

Wrong. Different people have different ideas about what is good/bad; and for every mod that a server uses there's going to be half the community thinking it's a bad/useless mod.

If a server us using a mod or not is the owner's choice.

Why do you hate StarMade so much

If I would hate starmade:

1. I wouldn't be here responding or even looking at the forums
   
2. I wouldn't help schema with the modding API

that you want to see the community splintered into hundreds of little "mod communities" anyway?

I don't, because I know that won't happen. OFC there will always be some people who only use versions of SM, which are "modded beyond recognition", but the vast majority won't be splintered. In society, would you forbid hobbies because you fear it would splinter society? No because it turns out it doesn't shatter society.

Sure, it's expected that they'll try to keep up; but that doesn't change the fact that they won't be able

Which is always sad, but happens in every game, regardless how slow the update-cycle is.

to or that people (including mod developers) can and will make mistakes.

This includes the game's developer(s). Bugs are to be reported and fixed. People who report bugs are to be expected to know what they're doing.
Besides, Starmade has the testers, who check if they can encounter said bug in a vanilla version, and if that doesn't happen the report is rejected by them and it doesn't even have to catch the attention of schema.

Your mod is a superficial thing that doesn't change the game's mechanics and doesn't require a mod API. I'm not talking about mods like this. I'm talking about mods that (e.g.) completely change how power reactors work, or add a new "Doomsday Bomb", or add a radically different crafting system - things that actually change the game's mechanics.

I know that as well as you, which is why I didn't even used it as an example nor was even referring to it.
Heck, the mod I made can be installed on EVERY java program, thus it isn't really a starmademod, but a mod that can be installed on Starmade

But the same goes for "mods", which just involve changing a config file.

Not the same at all. Imagine a mod that adds solar power blocks. You build a ship that uses solar power, will you be able to load that ship's blueprint on a different server (or vanilla) without the mod? Nope, you're screwed.

AFAIK if a blueprint with some invalid block data is loaded the invalid blocks are missing. You can spawn the blueprint, but all the solar panels are going to be gone from the spawned entity. You're not screwed.

What you mean here is that you're not a smart person, and would use (e.g.) the solar power blocks on your ship and end up screwed.

See above.

Bullshit. This happened for Minecraft often enough, even though Mojang were smart enough to avoid implementing a mod API (while cunningly pretending they might).

Minecraft isn't StarMade.
Schema isn't Mojang.

Currently there is no mod API; so there's no mods that use the mod API. Please note that an API (Application Programming Interface) is a programming interface - e.g. to allow modders to write their own code (in Java or Lua or some other programming language) that controls various aspects of the gam. It is not just some tweaks to a few configuration files.

Which is why I normally call those "mods" not mods.

Wrong. The mod API itself will be buggy, and because the game is still continually changing the mod API will also be continually changing. In addition, the programming done by mod developers will also have bugs. It's like a smorgasbord of bugs.

Bugs in the API will be reported by the modders or might be directly found by schema.
Bugs in the mods are the modder's problem.

It will also take a significant amount of Schema time to design, implementing and fix the mod API. The amount of time he's has left to work on vanilla game could easily be halved.

If done like currently, where some modders submit good and fitting code, I have to disagree.

Of course this assumes people have good intentions. Once you've got an API you can't control what people use it for - it'll be like web browser plugins (where a lot of them are malicious). Don't make the mistake of thinking Java is safe (it allows people to use native DLLs, which is how this game is able to use OpenGL, and isn't safe at all). Lua isn't safe either (it allows you to execute native code too).

That is not a problem of the API since mods aren't shipped with the game itself, and it is for the person to install a mod to decide if they do so, and thus it is their problem.
It'd be similar to completely banning computers, because some hacker might abuse one.

If all the servers are using different mods (that change the game mechanics); will the wiki provide information that's useful for all the people playing on servers (that have different game mechanics to vanilla)?

The official wiki is supposed to give information on unmodded Starmade, it is the job of the modder/server-owner to provide the information.

More like Minecraft doesn't have a mod API because of all the problems I've mentioned.

1. Proof?
2. How many players of minecraft don't regularly use mods compared to the amount of players regularly or only using modded minecraft?

 

[FunnyBunny14]

Duuuuuuuude, calm the heck down! This isn't supposed to be a flame thread about custom configs, so please don't make it one.

The whole purpose of an API is to make things less buggy, and you really shouldn't say that the API itself will be buggy because the game is constantly getting updated, because the API exists BECAUSE it is constantly being updated.

Minecraft isn't updated a lot, so your reasoning definitely doesn't apply there. Nor does it apply to starmade, or any game for that matter. The API will only need updating when a core feature gets changed, which doesn't happen a lot. Things like new blocks and recipes aren't core features. Core features would be things like new NPCs and new phenomena in the universe. We don't see a lot of updates like that. And even those updates won't necessarily break the API, as it should get updated alongside those features.

Yes, there will be bugs at first, but it will be a lot less than if people would not be using the API.

 

[Azurite]

Hi. Azu here. Amateur break-dancing "sucka" and novelty crystal-like entity.

Said it in chat and will retort once more:

Portal was once a mod for Half-Life before Valve hired the entire modding team to work on developing the game into a AAA title.

Horses were put in Minecraft only after a mod was made before hand, which Mojang took and ran with.

DOTA or "Defence Against the Ancients" was a modded version of Warcraft III before Valve swooped in and hired those guys as well.

Point being, modding is essential. Modding allows for creative breakthroughs. New ideas. New concepts and game modes. More importantly, ideas that the devs may not have thought of before. It is in this game's and every game after it's best interest to allow and praise the creation of mods. Free publicity if popular. Never stifles creativity. Learn a programming language or two in the process. Why the hate for mods?

*flies away gracefully*

EDIT: More games that came from mods: Counter-Strike. Team Fortress. The ship (personal favorite). Dear Esther. The Stanley Parable. Natural Selection. I know it's not the main point. But still is fun to list off.

 

[therimmer96]

I also wish to point out modding has already had a positive impact on the game. You know those snazzy caution stripes and grates? they were first seen in Crusade's IBM mod.

 

[Azurite]

Wow I totally forgot! That's true! Dem synchronous dancing Asians, doh.

 

[Qweesdy]

My point was not that people remove their mods to test it, my point was that people never accidentally mistake a modded version with an unmodded version.

And that's irrelevant, because even though they know they're playing a modded version, they'll still report bugs to Schema (and even forget to mention which the mod/s they're using in their bug report) and Schema will still have to do extra work to figure out what is/isn't a bug with vanilla StarMade.

That would be the case, if there wouldn't be a fast and easy way of contacting schema.

It's because there is a fast/easy way to contact Schema (and that there's a decent/official bug tracker) that people will use that as their preferred option when they have bugs with mods.

I am expecting the vast majority of players to not ONLY play modded Starmade.

If the mods are good, people will only play with the mods. If the mods are bad, then why bother supporting them? You can't have it both ways.

I don't, because I know that won't happen. OFC there will always be some people who only use versions of SM, which are "modded beyond recognition", but the vast majority won't be splintered. In society, would you forbid hobbies because you fear it would splinter society? No because it turns out it doesn't shatter society.

Starmade isn't "many hobbies", it's one game. Or at least I hope it's one game; and not 100 slightly different variations.

Which is always sad, but happens in every game, regardless how slow the update-cycle is.

During alpha, yes. All software "matures" though, and by the time it's almost finished beta you can expect fewer major changes (like, completely changing weapon systems, or planets, or solar systems/galaxies) and a lot more "minor polishing". With far less major changes the modders will need to update their mods less often, and the changes they'll need to make will be minor.

AFAIK if a blueprint with some invalid block data is loaded the invalid blocks are missing. You can spawn the blueprint, but all the solar panels are going to be gone from the spawned entity. You're not screwed.

That depends on what the mod is and how it effected your ship; and where you attempt to load it (for most servers you probably get kicked for trying to use a modified blueprint). For example, imagine a mod that removes the ship's core and replaces it with pilot seats - do you think uploading a "core-less" ship is going to work (even if it loads and the pilot seats disappear)?

Minecraft isn't StarMade.
Schema isn't Mojang.

If your name is Dave; stabbing yourself in the eye is probably a bad idea. Fortunately my name isn't Dave, so therefore stabbing myself in the eye must be a good idea!

If done like currently, where some modders submit good and fitting code, I have to disagree.

If the mod API (which doesn't exist) is done like the current mod API (that doesn't exist), then, um, what???

IThat is not a problem of the API since mods aren't shipped with the game itself, and it is for the person to install a mod to decide if they do so, and thus it is their problem.

Are you seriously that naive? Within 1 month of a mod API being released I can guarantee there will be a mod that secretly sends player's login details to a server in Russia. Within 2 months we'll have full botnets.

It'd be similar to completely banning computers, because some hacker might abuse one.

It'd be similar to Microsoft adding a whole pile of additional security features to IE, and then everyone downloading Chrome because they don't trust IE.

Proof?

Do you honestly think that Mojang wouldn't have added a mod API if it was easy, didn't create significant problems, and they thought it was a good idea?

How many players of minecraft don't regularly use mods compared to the amount of players regularly or only using modded minecraft?

Excluding superficial stuff (texture packs); most of the people I know played vanilla Minecraft until after beta, then got bored with it and started looking for mods, and stopped playing it soon after.[DOUBLEPOST=1414001574,1414001364][/DOUBLEPOST]

I also wish to point out modding has already had a positive impact on the game. You know those snazzy caution stripes and grates? they were first seen in Crusade's IBM mod.

In that case, I'd like to point out what I originally wrote:

"For similar reasons; if/when Schema adds a "mod API" its use should also be banned on all normal servers until the game is close to the end of beta; and should only be used as a tool for people creating suggestion to the default game, and/or people who are privately working on a mod for after beta"

 

[FunnyBunny14]

I just feel that mojang is lazy. My opinion though, but it would explain why they still don't support modding. But to be fair, it looks like they are on their way to one currently.

But @Qweesdy , please don't pick posts apart like that. It looks very immature (that's just my opinion) and it is very annoying (also my opinion).

But you seem t be in the minority luckily (I think you're the only one who doesn't want mods), so i'm still a happy person who's just starting to get into modding.