A Scripter's Wishlist - For Future-Compatible Server Modding, creating Quests, Events, and More.

[Benevolent27]

So, I've spent a lot of time scripting and brainstorming for the LvD server, and I now have a quest engine up and running. Players can run a command, see their available quests for the day, and then start an instanced quest. I also have spontaneous events planned, random encounters with various AI factions, script guided admin events, ect. But there are a few things I really wish I could do, and it's limiting my ability to make these quests and events as enjoyable as they could be. So, in the interest of producing cool content for StarMade, here is my humble scripter's wishlist.

Briefly:

Right now, there is no admin command or way to script finding a home base or the systems claimed by a faction. There's also no way for admins to see a player's inventory. Being able to see a person's inventory is pretty important to a lot of modding ideas. There are also a ton of commands that can only be run in game, by selecting an entity or by running the command as a player, which makes them unusable through scripting or console commands. But if they could be used though a script, it would open a lot of doors to modding. Sandbox games like StarMade really do benefit a lot when the modding community has the ability to create content for the game. This kind of modding also doesn't inhibit the development of the game. I love all the other things the devs are doing with the game, but when a few extra commands would make a big difference, why not?


The long explanation, with specific implementation ideas and reasoning:

1. Inventory control (I went over this in a different thread, but with a different idea in mind, so I'll post this here since it fits into the other ideas here, which are very different):
   A. Give a new command, /player_inventory [PlayerName], that would list all the blocks in a player's inventory. Might look similar to the output of the /sector_info command, but would have blocks and their ID's instead of entities.
   
   B. "/store_player_inventory [PlayerName] [Inventory Name - optional]", "/restore_player_inventory [PlayerName] [Inventory Name - optional]", "/merge_player_inventory [PlayerName] [Inventory Name - optional]". This would allow a player's current inventory to be saved to a virtual inventory. If no name is specified, then it would only use one. If a name is specified, then multiple inventories could be saved for a player. This would be useful for things like allowing players to have alternate realities. The "merge" command would simply add the items from one inventory to the current. One use of this would be for a script that allows players to pop into a "creative mode sector" and build some stuff, and then pop out of the sector to return to survival gameplay.
2. /faction_info [faction ID] - I don't know why this isn't in there already. This would give a faction's home base coordinates (if it has one), and whatever systems are claimed by the faction, alongside the coordinates the systems are claimed from, perhaps even giving the UID's of the bases. I really want to be able to get a faction's home base coordinates for a lot of mods, which would include admin commands, server maintenance, spontaneous events, like attacks or distress calls, or other creative projects I am currently working on (which I don't want to divulge publicly at this time - but it is crucial to be able to obtain this information!).
3. Allow "/sector_info" to display whether a sector is in a claimed system or not and who has claim to that sector.
4. I wish I wish.. For a few extended uses of StarNet.jar can run.
   A. Allow StarNet to run in a mode similar to the console, but it can use a configuration file to only show certain events. Such as player joins, deaths, ect. This would allow for faster wrappers that don't have to parse through an enormous amount of info. or console screens for admins, which only shows certain events, like errors. Is it possible to parse the existing console? Sure, but when it's running at 50,000 lines a second (which I have seen on our server many times), this can be problematic for scripts that are running grep or other parsing on possibly hundreds of combinations of things.
   B. If I could have a run mode where it would keep the connection open, perhaps with a "-keepalive" argument specified, that would be good. It could run just like a console, but would only show the results of each command given. All typing would be hidden though, since it is likely that the output would be parsed by a wrapper. This would allow me to send isolated command streams much faster, rather than it having to run StarNet.jar for each command or using the console screen, which might have collisions if multiple groups of text are sent at a time. When comparing the speed between sending commands directly to the console window and starting individual StarNet.jar instances, the difference in speed was enormous when doing a LOT with scripting (such as removing hundreds of entities individually). This feature would also be 100% necessary for the next suggestion item on the list and is the main why I would like it.
5. This is a big one - Give the ability for a console or starnet.jar connection to simulate being a player, at a certain location, and/or selecting a specific entity. I will explain in just a second why this will be tremendously useful. But there could be 3 sets of commands:
   
   Sets the selection, as though selected from the Nav screen:
   "/select_uid true/false [Full_Entity_UID]"
   "/select_ship true/false [Ship Name]"
   "/select_player true/false [PlayerName]"
   
   Sets what player entity's perspective the command is run from (including location), but with the privileges of the console:
   "/run_command_as [PlayerName] true/false" command.
   
   Sets the location the script should occur in. If a player is already being simulated, it keeps simulating the player, but instead using this location:
   "/run_command_at_location true/false [SectorX] [SectorY] [SectorZ] [PosX] [PosY] [PosZ]"
   
   Now, this might seem kind of strange at first, and you are probably really wondering why the "true/false" options.. but I will explain. This would open up all kinds of new functionality and would also simplify scripting AND would be backwards compatible to how things are done now. To demonstrate what it would open up, here are some current commands that we cannot use at all for scripting, because it requires an entity to be selected in-game, to be run from a player account, or run from a specific location. I've broken it down into sub-groups for different purposes. "Build accounts" are accounts that are locked into a far away sector, given creative mode, and will have certain bot commands that will assist them with building.
   
   
   Simple Spontaneous events:
   /spawn_mobs
   /spawn_mobs_line
   
   Quests and events:
   /save <-- This might be useful for creating a temporary copy of a ship the player is currently in, and then spawning it somewhere. Perhaps a "dueling" even, where you duel your current ship.
   /jump <-- Would be an interesting way to have players leave or enter a quest, with effects. Or other creative uses.
   /start_ship_AI <-- this I really want to use for quests to make an individual ship become hostile to a quest participant if they choose wrong dialogue options.
   /stop_ship_AI <-- same as above
   /spawn_item <-- This would be useful to drop items as quest rewards in a more inventive way than it mysteriously, and silently, appearing in their inventory.
   /clear_system_ship_spawns <-- this would be useful for quests, spontaneous quests, and admin commands. Run the command from the perspectie of a player.. And all spawned ships near them disappear. Nice and easy. No need for the script to keep track of a bunch of UID's and remove them all with separate commands.. using for loops, while loops, or whatever loops.. building arrays.. This would be so simple and easy to script.
   /decay <-- This could be an effect that occurs within an event or quest.
   /explode_planet_sector <-- cool effect to happen during a quest or event, right?
   /explode_planet_sector_not_core <-- same as above
   /faction_set_entity <-- This would allow my events and quest entities to be changed to a player's faction easily. Perhaps it would be for a race event. Or maybe a base becomes the player's, and so the turrets start working for them in some "king of the hill" type of battle event. There are a few possibilities for this.
   /initiate_wave <-- This would allow me to easily script in some spontaneous pirate attacks on players.
   
   For the following, I'd like to use them during quests to simulate a failing ship and add some realistic storyline:
   /power_outage
   /power_regen
   /shield_damage
   /shield_outage
   /shield_regen
   
   This is 100% necessary for events and quests where the player needs to be able to respawn during the quest/event and continue:
   /set_spawn <-- This I really want to use for scripted quests and admin events so that players do not return to their spawn point, but rather one I designate. To do this, I'd use the "/run_command_as player" command, then "/run_command_at_location true X Y Z" command, then run the "/set_spawn". This would set the player's spawn point to the coordinates I specify.
   
   Custom shop scripts:
   /shop_restock
   /shop_restock_full
   /create_trade_party <-- I could use a "/select_uid true ENTITY_SPACESTATION_whatever" and then have a trading party actually go to a shop to restock it, via scripts. On our server, we have players purchase shops from the trade guild for credits. This would allow some pretty cool restocking features that uses actual ships and would help with the immersion.
   
   Build Accounts:
   /destroy_entity <-- For "build accounts" on our server, which are creative-mode players that are locked in far away sectors, it would allow me to give them specific access to delete ships that they can select. If the console has nothing selected, but has a "/run_command_as" command activated for a player.. then it would use the entity the player has selected when a command is run from the starnet console.
   /clear_overheating <-- though the bug where it crashes when multiple nearby entities are overheating would need to be fixed before I'd want to use this. But it would be useful in certain quest scenarios.
   /teleport_selected_to <-- Might be useful to allow build accounts to teleport entities close to them since they don't have the admin ability to F1 + F8 into the item (old TAB + F8)
   /despawn_sector <-- This would me to more easily script a way for build accounts to remove entities from their current sector.
   /destroy_entity <-- this would allow our build accounts to easily destroy an entity they have selected, without needing admin powers.
   /destroy_entity_dock <-- same as above
   /structure_set_minable <-- This would be useful for build accounts to turn this feature on and off for a structure to simulate block decay or to "paint" patterns into an entity using salvage beams.
   /structure_set_vulnerable <-- This would be useful for build accounts so that they could set their base or a ship as invulnerable, and then use other scripts to test combat vs pirates.
   /last_changed <-- I'd use this to allow founders of factions to have the ability to see who last edited their base (maybe) but also would be useful for players that have a shared build sector.
   
   Admin commands:
   /set_spawn_player <-- This would be useful for an admin to run a command and our friendly bot, Melvin would reassign the spawn point for a specific player to be where the admin is now.
   /teleport_self_home <-- This would make it possible to teleport someone to their spawn area without killing them.
   
   
   NPC Manipulation:
   These would be useful for having a player select different NPC's and the NPC's will become animated as they select different ones (though being able to get the UID of an NPC would be nice too):
   /spawn_creature
   /creature_animation_start
   /creature_animation_stop
   /creature_enter_gravity
   /creature_goto
   /creature_idle
   /creature_rename
   /creature_roam
   /creature_script
   /creature_sit
   /creature_stand_up
   
   Other:
   /ship_info_selected <-- this would allow me to create a variety of admin commands, build account, or other uses on an entity that a player/admin selects. It would essentially give my scripts the ability to see what a player is selecting and then react on it.
6. There were a few other requests listed in another thread, here. These include "/giveid" command returning success or not when using negative numbers, /force_exit and /force_enter commands (which force a player into or out of an entity's core). I thought I'd create a new thread because this post goes above and beyond the other and has unique ideas in it regarding scripting for StarMade.

Well, I know that was a long read if you read through my proposed uses of commands for idea #4. So thank you for your time.

 

[Benevolent27]

So, I've spent a lot of time scripting and brainstorming for the LvD server, and I now have a quest engine up and running. Players can run a command, see their available quests for the day, and then start an instanced quest. I also have spontaneous events planned, random encounters with various AI factions, script guided admin events, ect. But there are a few things I really wish I could do, and it's limiting my ability to make these quests and events as enjoyable as they could be. So, in the interest of producing cool content for StarMade, here is my humble scripter's wishlist.

Briefly:

Right now, there is no admin command or way to script finding a home base or the systems claimed by a faction. There's also no way for admins to see a player's inventory. Being able to see a person's inventory is pretty important to a lot of modding ideas. There are also a ton of commands that can only be run in game, by selecting an entity or by running the command as a player, which makes them unusable through scripting or console commands. But if they could be used though a script, it would open a lot of doors to modding. Sandbox games like StarMade really do benefit a lot when the modding community has the ability to create content for the game. This kind of modding also doesn't inhibit the development of the game. I love all the other things the devs are doing with the game, but when a few extra commands would make a big difference, why not?


The long explanation, with specific implementation ideas and reasoning:

1. Inventory control (I went over this in a different thread, but with a different idea in mind, so I'll post this here since it fits into the other ideas here, which are very different):
   A. Give a new command, /player_inventory [PlayerName], that would list all the blocks in a player's inventory. Might look similar to the output of the /sector_info command, but would have blocks and their ID's instead of entities.
   
   B. "/store_player_inventory [PlayerName] [Inventory Name - optional]", "/restore_player_inventory [PlayerName] [Inventory Name - optional]", "/merge_player_inventory [PlayerName] [Inventory Name - optional]". This would allow a player's current inventory to be saved to a virtual inventory. If no name is specified, then it would only use one. If a name is specified, then multiple inventories could be saved for a player. This would be useful for things like allowing players to have alternate realities. The "merge" command would simply add the items from one inventory to the current. One use of this would be for a script that allows players to pop into a "creative mode sector" and build some stuff, and then pop out of the sector to return to survival gameplay.
2. /faction_info [faction ID] - I don't know why this isn't in there already. This would give a faction's home base coordinates (if it has one), and whatever systems are claimed by the faction, alongside the coordinates the systems are claimed from, perhaps even giving the UID's of the bases. I really want to be able to get a faction's home base coordinates for a lot of mods, which would include admin commands, server maintenance, spontaneous events, like attacks or distress calls, or other creative projects I am currently working on (which I don't want to divulge publicly at this time - but it is crucial to be able to obtain this information!).
3. Allow "/sector_info" to display whether a sector is in a claimed system or not and who has claim to that sector.
4. I wish I wish.. For a few extended uses of StarNet.jar can run.
   A. Allow StarNet to run in a mode similar to the console, but it can use a configuration file to only show certain events. Such as player joins, deaths, ect. This would allow for faster wrappers that don't have to parse through an enormous amount of info. or console screens for admins, which only shows certain events, like errors. Is it possible to parse the existing console? Sure, but when it's running at 50,000 lines a second (which I have seen on our server many times), this can be problematic for scripts that are running grep or other parsing on possibly hundreds of combinations of things.
   B. If I could have a run mode where it would keep the connection open, perhaps with a "-keepalive" argument specified, that would be good. It could run just like a console, but would only show the results of each command given. All typing would be hidden though, since it is likely that the output would be parsed by a wrapper. This would allow me to send isolated command streams much faster, rather than it having to run StarNet.jar for each command or using the console screen, which might have collisions if multiple groups of text are sent at a time. When comparing the speed between sending commands directly to the console window and starting individual StarNet.jar instances, the difference in speed was enormous when doing a LOT with scripting (such as removing hundreds of entities individually). This feature would also be 100% necessary for the next suggestion item on the list and is the main why I would like it.
5. This is a big one - Give the ability for a console or starnet.jar connection to simulate being a player, at a certain location, and/or selecting a specific entity. I will explain in just a second why this will be tremendously useful. But there could be 3 sets of commands:
   
   Sets the selection, as though selected from the Nav screen:
   "/select_uid true/false [Full_Entity_UID]"
   "/select_ship true/false [Ship Name]"
   "/select_player true/false [PlayerName]"
   
   Sets what player entity's perspective the command is run from (including location), but with the privileges of the console:
   "/run_command_as [PlayerName] true/false" command.
   
   Sets the location the script should occur in. If a player is already being simulated, it keeps simulating the player, but instead using this location:
   "/run_command_at_location true/false [SectorX] [SectorY] [SectorZ] [PosX] [PosY] [PosZ]"
   
   Now, this might seem kind of strange at first, and you are probably really wondering why the "true/false" options.. but I will explain. This would open up all kinds of new functionality and would also simplify scripting AND would be backwards compatible to how things are done now. To demonstrate what it would open up, here are some current commands that we cannot use at all for scripting, because it requires an entity to be selected in-game, to be run from a player account, or run from a specific location. I've broken it down into sub-groups for different purposes. "Build accounts" are accounts that are locked into a far away sector, given creative mode, and will have certain bot commands that will assist them with building.
   
   
   Simple Spontaneous events:
   /spawn_mobs
   /spawn_mobs_line
   
   Quests and events:
   /save <-- This might be useful for creating a temporary copy of a ship the player is currently in, and then spawning it somewhere. Perhaps a "dueling" even, where you duel your current ship.
   /jump <-- Would be an interesting way to have players leave or enter a quest, with effects. Or other creative uses.
   /start_ship_AI <-- this I really want to use for quests to make an individual ship become hostile to a quest participant if they choose wrong dialogue options.
   /stop_ship_AI <-- same as above
   /spawn_item <-- This would be useful to drop items as quest rewards in a more inventive way than it mysteriously, and silently, appearing in their inventory.
   /clear_system_ship_spawns <-- this would be useful for quests, spontaneous quests, and admin commands. Run the command from the perspectie of a player.. And all spawned ships near them disappear. Nice and easy. No need for the script to keep track of a bunch of UID's and remove them all with separate commands.. using for loops, while loops, or whatever loops.. building arrays.. This would be so simple and easy to script.
   /decay <-- This could be an effect that occurs within an event or quest.
   /explode_planet_sector <-- cool effect to happen during a quest or event, right?
   /explode_planet_sector_not_core <-- same as above
   /faction_set_entity <-- This would allow my events and quest entities to be changed to a player's faction easily. Perhaps it would be for a race event. Or maybe a base becomes the player's, and so the turrets start working for them in some "king of the hill" type of battle event. There are a few possibilities for this.
   /initiate_wave <-- This would allow me to easily script in some spontaneous pirate attacks on players.
   
   For the following, I'd like to use them during quests to simulate a failing ship and add some realistic storyline:
   /power_outage
   /power_regen
   /shield_damage
   /shield_outage
   /shield_regen
   
   This is 100% necessary for events and quests where the player needs to be able to respawn during the quest/event and continue:
   /set_spawn <-- This I really want to use for scripted quests and admin events so that players do not return to their spawn point, but rather one I designate. To do this, I'd use the "/run_command_as player" command, then "/run_command_at_location true X Y Z" command, then run the "/set_spawn". This would set the player's spawn point to the coordinates I specify.
   
   Custom shop scripts:
   /shop_restock
   /shop_restock_full
   /create_trade_party <-- I could use a "/select_uid true ENTITY_SPACESTATION_whatever" and then have a trading party actually go to a shop to restock it, via scripts. On our server, we have players purchase shops from the trade guild for credits. This would allow some pretty cool restocking features that uses actual ships and would help with the immersion.
   
   Build Accounts:
   /destroy_entity <-- For "build accounts" on our server, which are creative-mode players that are locked in far away sectors, it would allow me to give them specific access to delete ships that they can select. If the console has nothing selected, but has a "/run_command_as" command activated for a player.. then it would use the entity the player has selected when a command is run from the starnet console.
   /clear_overheating <-- though the bug where it crashes when multiple nearby entities are overheating would need to be fixed before I'd want to use this. But it would be useful in certain quest scenarios.
   /teleport_selected_to <-- Might be useful to allow build accounts to teleport entities close to them since they don't have the admin ability to F1 + F8 into the item (old TAB + F8)
   /despawn_sector <-- This would me to more easily script a way for build accounts to remove entities from their current sector.
   /destroy_entity <-- this would allow our build accounts to easily destroy an entity they have selected, without needing admin powers.
   /destroy_entity_dock <-- same as above
   /structure_set_minable <-- This would be useful for build accounts to turn this feature on and off for a structure to simulate block decay or to "paint" patterns into an entity using salvage beams.
   /structure_set_vulnerable <-- This would be useful for build accounts so that they could set their base or a ship as invulnerable, and then use other scripts to test combat vs pirates.
   /last_changed <-- I'd use this to allow founders of factions to have the ability to see who last edited their base (maybe) but also would be useful for players that have a shared build sector.
   
   Admin commands:
   /set_spawn_player <-- This would be useful for an admin to run a command and our friendly bot, Melvin would reassign the spawn point for a specific player to be where the admin is now.
   /teleport_self_home <-- This would make it possible to teleport someone to their spawn area without killing them.
   
   
   NPC Manipulation:
   These would be useful for having a player select different NPC's and the NPC's will become animated as they select different ones (though being able to get the UID of an NPC would be nice too):
   /spawn_creature
   /creature_animation_start
   /creature_animation_stop
   /creature_enter_gravity
   /creature_goto
   /creature_idle
   /creature_rename
   /creature_roam
   /creature_script
   /creature_sit
   /creature_stand_up
   
   Other:
   /ship_info_selected <-- this would allow me to create a variety of admin commands, build account, or other uses on an entity that a player/admin selects. It would essentially give my scripts the ability to see what a player is selecting and then react on it.
6. There were a few other requests listed in another thread, here. These include "/giveid" command returning success or not when using negative numbers, /force_exit and /force_enter commands (which force a player into or out of an entity's core). I thought I'd create a new thread because this post goes above and beyond the other and has unique ideas in it regarding scripting for StarMade.

Well, I know that was a long read if you read through my proposed uses of commands for idea #4. So thank you for your time.

Just wondering, but is there anybody left who still scripts for server wrappers out there who might want to add to this?

 

[Jeryia]

Apologies as this thread is over a month old, but I think it's an important thread. I'd also like to add a few things on my wishlist...

# fleet commands
I badly want the ability to control fleets with a wrapper. This would allow me to create ship patrols, npc like ships (escort quest, etc). In general, it would allow us to make a more living breathing sort of universe with starmade wrappers.
- /fleet_create [ship flagship id] [fleet id] - creates a new fleet, with the first member being the ship id mentioned. The fleet id would be optional, as the command would return the fleet id of the newly spawned fleet.
- /fleet_add [fleet id] [ship id] - Adds a ship to a fleet.
- /fleet_remove [fleet id] [ship id] - Removes a ship from a fleet.
- /fleet_action [action] [sector x] [sector y] [sector z] - This would allow a fleet to perform any of the currently supported actions available to fleets.
- /fleet_disband - disbands the fleet (without deleting any of the ships)
- /fleet_despawn [fleet id] - despawns all members of the fleet

# Misc commands
- /blueprint_buy_mode [player] [mode] - This would allow the setting of the BUY_BLUEPRINTS_WITH_CREDITS server config option on a per player basis. The mode would either be credits or blocks.
- An addition to the /list_ships command that would provide ship information similar to how /player_list provides all the player information, or a /ship_info (maybe catalog_info?) command that would allow for the same thing. This command would at minimum give the ship name, the block count, and the credit cost.

Yes, there are still those working on writing wrappers . We're just insanely busy...

 

[Benevolent27]

Apologies as this thread is over a month old, but I think it's an important thread. I'd also like to add a few things on my wishlist...

# fleet commands
I badly want the ability to control fleets with a wrapper. This would allow me to create ship patrols, npc like ships (escort quest, etc). In general, it would allow us to make a more living breathing sort of universe with starmade wrappers.
- /fleet_create [ship flagship id] [fleet id] - creates a new fleet, with the first member being the ship id mentioned. The fleet id would be optional, as the command would return the fleet id of the newly spawned fleet.
- /fleet_add [fleet id] [ship id] - Adds a ship to a fleet.
- /fleet_remove [fleet id] [ship id] - Removes a ship from a fleet.
- /fleet_action [action] [sector x] [sector y] [sector z] - This would allow a fleet to perform any of the currently supported actions available to fleets.
- /fleet_disband - disbands the fleet (without deleting any of the ships)
- /fleet_despawn [fleet id] - despawns all members of the fleet

# Misc commands
- /blueprint_buy_mode [player] [mode] - This would allow the setting of the BUY_BLUEPRINTS_WITH_CREDITS server config option on a per player basis. The mode would either be credits or blocks.
- An addition to the /list_ships command that would provide ship information similar to how /player_list provides all the player information, or a /ship_info (maybe catalog_info?) command that would allow for the same thing. This command would at minimum give the ship name, the block count, and the credit cost.

Yes, there are still those working on writing wrappers . We're just insanely busy...

I completely agree with your recommendations for fleets! That's a good addition! Thank you for your input here.

It would allow setting some groups as sentries, some as defenders, others as attack forces.. even have NPC's out mining. Also being able to use the fleet controls to despawn groups of ships would simplify group spawns/despawns as well.

One question though, when creating these fleets, when they be virtual or would they be physically present in the universe? I ask because I think it'd be interesting to have control over both fleets and also be able to use virtual fleets to simplify spawning of diverse sets. For example, if we add a ship to a physical fleet, then would the ship need to exist already before being added? Or would it spawn in a new ship? With a virtual fleet, it would not exist anywhere in the observable universe, but would be simply be used for spawning the ships in later and then controlling them. Ships UID's added to the fleet would actually have a blueprint of their current form added to the fleet, to be spawned later.
Virtual Fleet Command examples:
/add_virtual_fleet_UID [virtual fleet ID] [ship UID] <-- This create a virtual fleet by ID if it does not exist and add a copy of an existing ship UID to it.
/add_virtual_fleet_BP [virtual fleet ID] [ship blueprint name] <-- does the same thing as above but adds a ship to the virtual fleet by blueprint.
/remove_virtual_fleet [virtual fleet ID]
/list_virtual_fleets
/spawn_virtual_fleet [Virtual Fleet ID] [SecX(Integer)] [SecY(Integer)] [SecZ(Integer)] (Fleet ID) (PosX(Float)) (PosY(Float)) (PosZ(Float)) <-- all values encased in [ and ] are REQUIRED, whereas values encased with ( and ) are optional.

Spawning a virtual fleet would create a new physical set of ships from that virtual fleet and then assign a new fleet ID.

So an example of usage in scripting, kind of merging our suggestions might look like:

1. A script that sets up a virtual fleet, which other scripts would then use. It would send the following commands to the console or use StarNet to send them:

/add_virtual_fleet_BP "Noob pirates raiders" "Junky Pirate Bomber"
/add_virtual_fleet_BP "Noob pirates raiders" "Junky Pirate Cannon Ship"
/add_virtual_fleet_BP "Noob pirates raiders" "Junky Pirate Miner"
/add_virtual_fleet_BP "Noob pirates raiders" "Junky Pirate Defender"
/add_virtual_fleet_BP "Noob pirates raiders" "Junky Pirate Intercepter"
/add_virtual_fleet_BP "Noob pirates raiders" "Junky Pirate Cargo Ship"

2. Another script that controls pirate attacks might run this command to create the physical fleet from a virtual fleet, and then give different commands to each fleet:

/spawn_virtual_fleet "Noob pirate raiders" 10 50 100 "Fleet-o-Pirate-Joe" 200 200 200
/fleet_action "Fleet-o-Pirate-Joe" defend 10 50 100
/spawn_virtual_fleet "Noob pirate raiders" 0 50 100 "Fleet-o-Pirate-Joe-Wave2"
/fleet_action "Fleet-o-Pirate-Joe-Wave2" attack 10 50 100
sleep 1200
/fleet_disband "Fleet-o-Pirate-Joe"
/fleet_despawn "Fleet-o-Pirate-Joe-Wave2"

Of course, this isn't what the script itself would actually look like. I'm just keeping things simple here to make it obvious what the script would be doing.

This kind of functionality would be awesome! It'd really allow me to liven the universe up a bit.

 

[Jeryia]

I agree that would be useful. I like it!

Though if we do that I'd want to also see a /virtual_fleet_info_BP and /virtual_fleet_info_UID to display what's in them.
Likely need a /fleet_info command as well to check to see how many ships remain (in the event they got attacked)

 

[Madman198237]

I don't do any scripting myself, but I still must ask: Why has this not gotten any attention from anyone? This seems simple (Forgive me for being a clueless, interfering idiot) and really should be a priority. Makes for more interesting servers, which is important to holding interest for those who can only build for so long before going back to the chat more and more.

 

[Benevolent27]

I agree that would be useful. I like it!

Though if we do that I'd want to also see a /virtual_fleet_info_BP and /virtual_fleet_info_UID to display what's in them.
Likely need a /fleet_info command as well to check to see how many ships remain (in the event they got attacked)

I agree with this too. Though the info commands could be shortened to "/virtual_fleet_info". Reason being that regardless of whether a blueprint or UID is used to add a ship, the virtual fleet would actually need to be made using copies of blueprints. If adding a ship to the virtual fleet, it would create the blueprint at the time the ship UID is added. Though this functionality isn't completely necessary, since admins can create a blueprint and then tie it to the virtual fleet. But my problem with this is that I have run into the issue of not having enough blueprint slots available for the various quests and other server functions. I would personally prefer separate, hidden blueprints be stored for these fleets for this reason.
[doublepost=1480421599,1480420634][/doublepost]

I don't do any scripting myself, but I still must ask: Why has this not gotten any attention from anyone? This seems simple (Forgive me for being a clueless, interfering idiot) and really should be a priority. Makes for more interesting servers, which is important to holding interest for those who can only build for so long before going back to the chat more and more.

Things are not always as simple as they might seem, but either way.. What makes sandbox games like MineCraft popular is not it's graphics or really even many of the in game features. It's the novelty. It's the exploration. The random events. The thrill of overcoming new and unexpected challenges.

What makes StarMade attractive is the novelty of a sandbox adventure in space. Being able to completely build all parts of your ship, block by block, and then use it in a changing galaxy. But when that novelty wears off, what is there? For MineCraft, some really smart people figured out how to reverse engineer the code and then inject mods into the code. I played vanilla MineCraft for a while, but what really kept me after the initial novelty wore off were all the mods people made for it. I imagine I am not the only person to have had this experience. There was always a new mod to try out which enhanced gameplay. New dimensions. New monsters. New armors, new crafting recipes, ect. This kept the novelty fresh. This is why I have been working so hard to try and use the tools I have available in StarMade to create new, unique features for StarMade servers.

I understand that the game devs don't want people tinkering with the code while the game is still in development, and I can see their point, but providing these kinds of commands is a way to give scripters like me the capabilities we need to help keep StarMade novel, diverse, and interesting right now. Then later on, a more full-fledged wrapper might add onto all of these capabilities. I fear the devs may be too focused on what their plans are, and they don't fully realize the immense worth of community driven modding and so they are putting it at low-priority.

But let's just say they had created the engine first, then focused a lot on modding. They implemented capabilities for modders to access player inventories. With each new feature, there were modding capabilities included, such as with fleets. Every time they'd release an update, new mods would come out, in addition to the features they added. If they finished the code on making weapons systems copyable and modable, including effects and projectile modification.. Imagine all the weapons that might be available through mods. Imagine different thruster types. Imagine new effects. If they were to make public their LUA calls and create new ones, based on demand, think about all the role playing content people would have been creating, with NPC's selling products, having quests where players turn in custom blocks, for rewards. If they had a way for modders to introduce new models into the game, think of all the aliens that might have already been created. Then think about how these mods might take into account the new features the developers are implementing. For example, with the NPC update, perhaps modders would be creating all sorts of character models for use of these various NPC factions. Perhaps they would be having different NPC factions also using different kinds of weapons, to vary gameplay. As new features come out, modding really broadens the breadth and depth of these features and has a profound impact on the popularity of a game. I feel they have definitely put some work in toward modding already, but going just a bit further would really have a dramatic effect for StarMade.

 

[Jeryia]

I agree with this too. Though the info commands could be shortened to "/virtual_fleet_info". Reason being that regardless of whether a blueprint or UID is used to add a ship, the virtual fleet would actually need to be made using copies of blueprints. If adding a ship to the virtual fleet, it would create the blueprint at the time the ship UID is added. Though this functionality isn't completely necessary, since admins can create a blueprint and then tie it to the virtual fleet. But my problem with this is that I have run into the issue of not having enough blueprint slots available for the various quests and other server functions. I would personally prefer separate, hidden blueprints be stored for these fleets for this reason.

Yeah, Note that you can add blueprints to the server blueprints folder and they won't be owned by anyone. I think this would bypass the issue you mentioned, though I always keep blueprint upload limits at max on the servers I run.


I also agree with you wholeheartedly on the modding. From my perspective StarMade has a tremendous amount of potential. My general goals in the creation of the wrapper programs has been to try to unlock some of that potential, and explore directions that StarMade has not gone in. The more tools at our disposal, the more we can explore what StarMade can be. That exploration doesn't need to just be Belevolent27 and myself. With new commands available perhaps others will get inspired to create things that we have not thought of.

 

[Benevolent27]

Yeah, Note that you can add blueprints to the server blueprints folder and they won't be owned by anyone. I think this would bypass the issue you mentioned, though I always keep blueprint upload limits at max on the servers I run.


I also agree with you wholeheartedly on the modding. From my perspective StarMade has a tremendous amount of potential. My general goals in the creation of the wrapper programs has been to try to unlock some of that potential, and explore directions that StarMade has not gone in. The more tools at our disposal, the more we can explore what StarMade can be. That exploration doesn't need to just be Belevolent27 and myself. With new commands available perhaps others will get inspired to create things that we have not thought of.

Exactly. I always strive to be creative and also build to needs, but it's the things we haven't thought of that create the most novel experiences. I am not all knowing or all wise, lol. The more tools at my disposal, the more creative I can be. The more creative other players are, the more I will want to be creative. It's a synergistic cycle.

 

[Benevolent27]

To add a few more ideas here for some more admin commands:
/set_personal_permission_selected_entity [PlayerName]
/set_personal_permission_UID [Entity_UID] [PlayerName]
/personal_permission_info_selected_entity
/personal_permission_info_UID [Entity_UID]

These would allow setting who owns a ship or seeing who owns it.

Additionally:
/set_permission_level_selected_entity [1-5]
/set_permission_level_UID [Entity_UID] [1-5]
/permission_level_info_selected_entity
/permission_level_info_UID [Entity_UID]

These would be allow setting the permission level of an entity within the faction it is factioned for.

This is to both allow admins more control over entities. For example, I was putting some prize items into a person's ship, but I wasn't able to set it back to be owned by that player. I also can't assist in resolving some permissions issues, but why not? I'm an admin, I should have full control here. These kinds of capabilities also would allow wrapper makers to have automated factions that are managed by scripts. For example, there may be ship spawns that only certain members of a faction can use. Or perhaps a quest reward isn't a blueprint, but rather a spawned in ship that is set to be privately owned by the winner.

 

[Benevolent27]

So, what do folks think about this? Think more modding in StarMade is needed?

 

[jayman38]

Yes, I still want to see more.

How has the SQL interface changed these suggestions? Is there an ability to "insert" or "alter" data in the SQL interface?

 

[arouq]

Just a tip, make a google doc with all these suggestions. Group them in some way, for example, grouping them by which ones would help modders the most. One single, easy to read document is going to be far easier for a developer to go over.

Just want to help your chances of getting this into the game

 

[Benevolent27]

Yes, I still want to see more.

How has the SQL interface changed these suggestions? Is there an ability to "insert" or "alter" data in the SQL interface?

Unfortunately, the SQL commands cannot be run via StarNet.jar. An error occurs, stating the user does not have permission to run the command. These commands can only be run manually in game as an admin (specified in the server.cfg) or on the console, both options not very usable by scripts, since scripts need to grab the return result. This is not possible when the command is run as a player. If sending directly to the console, trying to grab the output is rather problematic because it would require parsing the console output (which has a lot of other data - and parsing the console directly causes blocking of the server program when it can't keep up, which crashes the server). If a non-blocking method of parsing the console is used, then there is still the problem of multiple scripts running at the same time doing SQL queries. The console parsing script could not know which result was supposed to match to which script. So, as it stands, the SQL commands cannot be used till the permission issue for StarNet.jar is fixed. I did speak to AndyP though, and he said he'd see about getting it working! So I am very excited about that and will DEFINITELY be experimenting with it once it's usable. Though I will NOT be doing direct SQL edits using the commands to begin with, but rather coming up with a library of SQL queries to obtain information that is not currently feasible or possible through console commands (such as finding the locations of stars within systems and then have scripting create spontaneous events for players, being mindful of where those stars are and not placing the events too close to the damage radius).

 

[GDPR 302420]

Why is this not a thing yet?