bit
-
Posts
22 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by bit
-
-
Boring background stuff:
Over the last few weeks, I've been working on a project, provisionally (and slightly ostentatiously) monikered AVCMM (Avorion Community Mod Manager). At its core, it is a cross-platform text-based interface for (theoretically) generalized mod management for both client end users and server providers. Current development is targeting Python 3.5+ though porting and backwards compatibility (not to 2.x) would be an option per support and interest. In concert with another developer, AVCMM will additionally be embedded as part of a larger (and slick) graphical framework to greatly enhance the custom Avorion experience (more detail available pending approval from the other developer).
The design is complete and the implementation is also nearing completion. However, there is a need to concretely characterize how mods are currently modifying data lua files. In order to properly provide the types of interfaces which mod developers might find useful, it is important to know where in each file changes are made. While public mods are, as the name suggests, public, classifying each mod, into 'active and updated' versus 'legacy', and then further inspecting them demands more time than I can currently supply.
What I am seeking is for individuals familiar with currently functional and supported mods to respond with a list of changes a particular mod makes to existing lua files (any format acceptable although diff format is greatly appreciated). The goal is to have, over the next two weeks, a final tabulation of all locations in each lua file where moddders have previously made changes. If there appears to be enough public interest, I will additionally be releasing a package metadata format to help bundle mods in an AVCMM-compatible manner. Ultimately, the aim is to hit the ground running with a meaningful base of mods already available to end users.
-
Well, programmatically, diff-ing the functions is a bit tricky. I was indeed hoping for even something like a reliable header comment at the top of a file or something promised to be consistent.
Ah yes, I did post it in the wrong place. Would a mod be able to lock or move it?
-
I too am having some trouble finding the latest (or any) copy of the mod. Is it hosted separately?
-
Unmarked sectors tend to be fairly dry as a place to be while the hyperdrive warms up. Understandably, it would not cost prohibitive to populate every such unmarked sector.
I propose adding environmental hazards to different sectors which would encourage more interaction and planning on the part of the player.
Examples (these are just examples off the top of my head, not necessarily recommendations themselves):
- cold system: system is powered by an old star making lifesystem costs increase and solar panels less effective
- magnetic anomoly: navigation within the world impaired causing hyperdrive to take longer
- subspace anomoly: ship no longer able to hold bearing without active control
- stellar storm: scanning range and hyperdrive range impaired
- abandoned sector: traders less likely to spawn
- watering hole: ships likely to warp into area
These would also add some more complexity as to where you chose to build a base, etc.
-
It'd be really great for compatability-aware mods if there were a text file somewhere which stored the Avorion version (rather than parse the .html).
-
I'll move this over to a PM.
-
Ah yeah, I forgot to mention that I added the line back for normal mining. The new mining commands should appear below the old one.
-
Just an FYI, I got the mod when it first was released (big fan btw), and I had to manually patch shipyard.lua to incorporate thee fixes from Koonschi's last patch on the beta branch.
-
Sure, I'll take a look at it. I'll also add an update to the main page with changes to the mining scripts tonight.
-
I'll see if I can post two versions. There will also be a nifty little update to the mining scripts coming up soon, but I'll post an update for that.
-
Bugfix:
Users may have been unable to start the game after running the script. This was due to the unpacking of the snapshot one directory level too far. The attached AVCML.ZIP should provide a fix for this.
-
Sure, go for it.
-
AVCML: Avorion Community Mod Linker
AVCML is a set of scripts I've been using to quickly install mods in a nice, clean way. Before you continue on, this is not a full-fledged installer with all the bells and whistles of a full mod manager. If you're looking for that, I believe Steam workshop support should be arriving which will officially support a much more robust, featureful system. I wrote the scripts originally for myself, but I figured since it's working pretty well, I'd release it for those who might be interested.
What is does:
AVCML helps with the installation of mods, but more importantly, with the rapid removal or swapping of mod content. Rather than editting files inside the Steam directory, AVCML will automatically snapshot the scripts directory and install mods from an isolated directory. This prevents unnecessary data loss (forgetting to back up files) while also providing the ability to selectively install sets of mods by reverting to older scripts directories. While useful to any user, it was designed with developers in mind, keeping the environment clutter free, organized, and well-archived.
How would it be used:
Instead of installing a mod to the Steam directory, the user is able to install it to a local (more easily accessible) directory (I periodically refer to this directory as the local scripts directory). Then, by running AVCML, the locally installed mods are mapped onto the Steam installation's scripts folder. The process is conducted in such a way that backups are maintained so that if the user wants to revert back to an earlier installation, either an unaltered one or a previous setup of mods, the user maintains the ability to quickly do so. Because it takes a full snapshot, even if you made changes in the local scripts folder, prior versions are maintained.
About the program:
Things AVCML (the program) handles:
- Installing sets of mods to the relevent directories
- Keeping meticulous backups of editted directories
Things AVCML does not handle:
- Installing a particular mod
- Uninstalling a particular mod
- Merging mods
- Handling conflicting mods
- Handling dependencies
Requirements:
- Python 3.6 (support for 3.0-3.5 available upon request)
- Windows 7, 8, 10; or Linux with Bash
Additional Requirements:
Windows: Admin access or ability to change user permissions*
Installation:
Download the files (avcml.py for everyone, avcml.bat and avcml.sh for Windows and *nix respectively)
* For Windows, in its current form, the program will require the ability to create symbolic links. The Python script is written to be as language-agnostic as possible to make it easy to write for everybody, but unfortunately at least on Win7, symbollic links are not provided to all users. One option is to run avcml.bat as an administrator. Another option is to give yourself the correct privileges. Refer to here for more info on that process.
Setup:
There will be commented text at the top of avcml.bat and avcml.sh. Read it some time during installation, preferably before you start.
Windows
1. Make a few folder somewhere on your harddrive. This will contain the mods (local mods folder) you install. Inside, make another folder and name it scripts (local scripts folder). My setup looks like:
C:\Users\bit\Documents\AvorionMods\scripts
2. Compress a copy of your Steam installation data/scripts folder (installation folder). This is different from your APPDATA Avorion folder. The default installation directory should be C:\Program Files (x86)\Steam\steamapps\common\Avorion\data\scripts, though those with custom setups may have it placed elsewhere. Any mods installed in this compressed copy will be persist into every installation, possibly causing problems down the line. You can use Steam's "Verify integrity..." to retrieve an unaltered copy.
3. Store this compressed copy (snapshot) preferably somewhere inside your local mod folder, but NOT in the local scripts folder you just made.
3. Open avcml.bat in your favourite editor.
4. Uncomment lines 10, 20, 24, 38 and fill in the relevant details. They correspond to SET STEAM_AVORION_..., etc. An example will apear below.
5. Set STEAM_AVORION_SCRIPTS_PATH to point to wherever your Avorion installation folder is. Remember, this is the one under the Steam directory.
6. Set AVORION_MOD_PATH to the folders you made earlier.
7. Optional: Set ARCHIVE_MODE to "zip". The program will default on "zip", but for the adventurous seeking those sweet extra bytes of compression can also set it to "gz", "gztar", "xztar", "xztar", or "bztar". The available compression methods depend on what your system and python installation offers.
8. Set ORIG_SNAPSHOT to the path of the compressed copy you made in step 2.
* It is imperative that you do not add any spacing to the fields in steps 4-8 except for the spaces in your paths. You may need to embed your paths in quotation marks.
By now, it should look something like
... :: Usually installed by default under :: C:\Program Files (x86)\Steam\steamapps\common\Avorion\data\scripts :: SET STEAM_AVORION_SCRIPTS_PATH=C:\Program Files (x86)\Steam\steamapps\common\Avorion\data\scripts :: Here is where your local mod directory should be. This can be whatever folder you want, but the program will :: mirror ALL files inside. :: It will also backup your current vanilla scripts to the parent directory. :: Make sure that the only files contained are mod files. :: It'll back everything up just to be safe, but you don't want to risk anything. :: :: :: SET AVORION_MOD_PATH=C:\Users\bit\Documents\AvorionMods\scripts :: Backup mode (type of archive used for backups, unrelated to ORIG_SNAPSHOT :: :: ARCHIVE_MODE= :: :: :: :: This is where your base snapshot of the scripts folder should be stored. :: If you have not already done so, archive your Steam installation's scripts folder to the directory :: provided in ORIG_SNAPSHOT. :: Make sure your Steam installation's scripts folder is cleared of all mods :: as this is the base-state the script will revert to. :: It should include a filename and type. E.g. ~/.avorion/mods/base_snapshot.tar.gz :: It must be conformant with the types the script can read, namely tar, zip, gz, tar.gz, tar.bz, tar.lzma. Further, :: your computer must have the appropriate Python modules to process these. zip, gz, and tar and well supported and so :: I would recommend sticking to those. :: :: ORIG_SNAPSHOT= :: ...
Try running it. If you get an error about Python not being found or pythonexec not being a command, or error messages and you are sure you have Python 3.6, edit line 39 from
:: set pythonexec=
to
set pythonexec=C:\Python36\python.exe
Or wherever your Python 3.6 installation is.
Linux
1. Make nested folders. The parent can be named anything (usually mods, and i'll refer to it as the local mods folder), but the child should be named scripts (which I refer to as the local scripts folder).
1. Make a snapshot of your data/scripts folder in your Steam installation and place it somewhere, preferably inside the local mods folder from Step 1. Do NOT place it inside the local scripts folder. Any mods installed in this compressed copy will be persist into every installation, possibly causing problems down the line. You can download a copy using Steam's "Verify integrity..." to retrieve an unaltered copy. The Steam installation directory is trickier on Linux, but it is definitely not ~/.avorion. Usually it is under ~/.local/share or ~/.steam or ~/.steamapps but this is highly distro dependent.
2. Just like with Windows, you'll edit your avcml.sh. Uncomment lines 12, 20, 24, 36.
3. Fill in the uncommented lines of with your Steam Avorion folder, a local nested folder, compression type, and base snapshot. On Linux, ARCHIVE_MODE defaults to "gz" and so if this is satisfactory, there is no need to uncomment that line unless you wish to try a different compression method. The available compression methods depend on what your system and python installation offers.
* It is imperative that you do not add any spacing to the fields in steps 4-8 except for the spaces in your paths. You may need to embed your paths in quotation marks.
... # STEAM_AVORION_SCRIPTS_PATH=~/.local/share/Steam/steamapps/common/Avorion/data/scripts # Here is where your local mod directory should be. This can be whatever folder you want, but the program will mirror ALL files inside. # It will also backup your current vanilla scripts to the parent directory. # Make sure that the only files contained are mod files. It'll back everything up just to be safe, but you don't want to risk anything. # # I keep mine in ~/.avorion/mods/scripts # AVORION_MOD_PATH=~/.avorion/mods/scripts # Backup mode (type of archive) ARCHIVE_MODE="gztar" # # This is where your base snapshot of the scripts folder should be stored. # If you have not already done so, archive your Steam installation's scripts folder to the directory # provided in ORIG_SNAPSHOT. # Make sure your Steam installation's scripts folder is cleared of all mods # as this is the base-state the script will revert to. # It should include a filename and type. E.g. ~/.avorion/mods/base_snapshot.tar.gz # It must be conformant with the types the script can read, namely tar, zip, gz, tar.gz, tar.bz, tar.lzma. Further, # your computer must have the appropriate Python modules to process these. zip, gz, and tar and well supported and so # I would recommend sticking to those. # ORIG_SNAPSHOT=~/.avorion/mods/snapshot.tar.gz ...
Execution
Terminal
The .bat and .sh files should now contain all configuration required to run without problem.
Instead of installing scripts to your /data/scripts folder, install them into the relevant places in your mod folder.
For example, if I am supposed to install a script to scripts/entity/ai/flee.lua, I would install it to ~/.avorion/mods/scripts/entity/ai/flee.lua instead of the longer Steam path. I would confirm everything inside of my local scripts folder is what I want to be in there; everything not there shouldn't be as well. Then, I would call avcml.sh (or avcml.bat). It can be done from anywhere as long as you used absolute paths in your configuration, although I like to keep mine in my local mods folder.
For those interested in access to the Python script, the -h/--help were quickly written but should provide enough information to allow for use.
What It's Doing
1. Backs up the target directory provided by STEAM_AVORION_SCRIPT_PATH.
2. Removes all symbolic links from the target directory. As of the most recent release, the scripts folder is normally free of symbolic links and so all symbolic links were previously installed mods.
3. Unarchives a pristine scripts folder (the snapshot) to fill in any files that are now missing.
4. Symbollically maps all files in the local mods folder (AVORION_MODS_PATH) to the target directory.
Advanced usage
With access to the raw Python, the user could do any number of useful tasks. But, there are some interesting use-cases for those who want to stick strictly to the .sh/.bat scripts. By maintaining multiple copies of local scripts (the one where mods are installed) (using various filenames), whole sets of mods can be swapped out extremely quickly. On Linux, this might look like:
./mods
|-avcml.py
|-avcml.sh
|-scripts
|-scripts_loadout_1
|-scripts_loadout_2
|-scripts_loadout_3
|-...
To install scripts_loadout_2, the user might use rm -r scripts && cp -r scripts_loadout_2 scripts && source avcml.sh.
Similar operations exist for Windows.
Future updates and closing remarks
If there is great demand for Python 3.0-3.5 support, I can certainly try porting it over, although the process will take time. There was quite a bit of hoop-jumping to make this as obscure-dependency-free and so the permission settings on Windows is quite infuriating. I don't have a finished solution at the moment, but if people are running into this problem often, let me know and I'll push a fix for that.
There may be those who look at this and wonder if the effort of installing all of this is worth it for the enduser (usually themselves). And they make a valid point. This tool is primarily for developers. For the enduser who only installs mods once in a while, it may not be worth it.
In the works is a much more extensive mod manager which will handle the functions of AVCML along with more advanced diffpatch-based mod-merging, repository searching, etc (AVCML was actually originally written as a library for the larger project). While the layout, list of features, vague architecture are developed by now, there is still quite a bit more work to be done. Of course, that takes a tremendous amount of time to write, time I personally do not have to complete and so I am opening up the project to development within the community. If there are those interested in helping develop this mod manager, please contact me either through the forum's messaging support or through Discord.
Earlier today I came across an interesting tool already posted on the Mods page. I'd like to give a shoutout to NMaster's Mod Patch Generate & Apply tool. I havn't used it personally, but for those looking for an already developed tool which handles the patchdiff system, I would encourage you to look there.
Notice
The provided code was developed and primarily tested on Linux using Python 3.6 and only received partial testing on Windows 7. While all IO operations are performed in Python with an excellent track record for cross-platform behavior, I cannot promise that AVCML will work under all conditions, especially in custom or complex architectures. I do believe, though, that with proper configuration, AVCML regardless of operational behavior, should not cause any data loss other than what is expected (refer to Step 2 of What It's Doing)
The usual lack of warranty, responsibility, and promise of data integrity apply. I am releasing this as a resource for others to use under Creative Commons Attribution-NonCommerical-ShareAlike 4.0 International (CC BY-NC-SA 4.0). A link to the license is provided below.
https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode
TLDRLegal is an excellent resource for understanding what the various licenses mean. While not a replacement for true legal advice, generally speaking I find them to be decently accurate.
Update (6 Feb. 2017)
Removed AVCML.zip attachment to prevent use of outdated version.
-
Are there any screenshots you could show? I'll install it this weekend anyways, but I'm super curious.
-
Ah great, I knew I forgot something. It should go into scripts/entity/crewboard.lua. I'll update the original post as well.
-
It overrides the previous mining command. If you would like, I can post it a version that adds back the old mining option - it wouldn't be too hard at all, just let me know.
-
I read somewhere that someone was frustrated with how hard it was to populate very large ships. Rather than work on my work or any of the other mods I had in mind, I made this.
The attached mod makes a change to the way the hiring pool is generated at stations to [nonlinearly] scale for the distance from the center.
Enjoy. Have fun. Tinker with it. As always, please do inform me of bugs.
Installation
Install to /scripts/entity/crewboard.lua
Remarks on the mod, internal details, etc.
In theory, you could scale it by whatever you want, but I chose to make a scale which would provide two bands of high-population. Within the lore, this might be other wayward travellers struggling towards the center. Functionally, the outer bands are somewhat depleted as players don't likely need as many people and the drive for more crew would hopefully facilitate exploration. The two bands correspond roughly to when naonite/trinium and xanion are found. If materials are balanced away from a heirarchical system and more towards each-one-has-pros-and-cons, there's a fair chance the weightings would be redone. Of course, there's a wonderful graphic for those who wish to see the details without seeing the code (provided below). There may have been a slight typo - the X axis is squared-distance from the center and the Y is the modifier over the standard hiring pool. "Slight".
The file editted was crewboard.lua. I basically modified the range for how many members of particular classes could spawn. Only the upper bound was change as I didn't want it to seem like I was making metropoleis out there.
Should you choose to tinker with it, I do have a Python(3.6) script I used to generate some of the Lua code (you'll know it when you see it). If you are interested, you can certainly try to message me through here, or find me on discord. That's what I used to generate the figures, etc. NOTE: The python code is highly insecure and so don't allow for arbitrary input (i.e. don't let other people use your computer while it's running; on Linux, if for some godawful reason you're calling it with root access...). There was a quick fix to a problem. Personally, I would just delete the file after I were done.
-
I haven't been following too much so hopefully this isn't a repeat of something already out there.
Safe Mining
If the health of the mining ship is less than 50%, the ship will stop and wait to heal. It will also send a chat notification to the player, which could be useful if you plan on remote-healing it (select the mining ship, press F, go to Build, then repair the ship; this is a vanilla feature, not a part of the mod; it's also a great way to slave the camera to a ship you control).
Note, I made this on the fly to stop my drones from blowing themselves up. If you decide to use it, I can't guarantee your ship won't succumb to the Kraken or anything else. Also, please let me know if you find a bug! It really isn't the Mona Lisa of coding so any feedback would be appreciated.
Download and Installation
safemine.lua (./scripts/entity/ai/safemine.lua)
craftorders.lua (./scripts/entity/ai/craftorders.lua)
craftorders.patch - a patchfile for the technologically inclined; I'm playing around with the patch-diff system and figured I might as well include it
Upcoming (hopefully, technology and time allowing):
Clear all asteroids: Allows a mining ship to target all asteroids, not just ore-carrying ones
Steady-mining: Tells the ship to stay put when mining
Follow mode: Slaves the user's ship to follow a particular vessel/autonavigate to a point
Update (Feb. 6, 2017)
- Added a Mine All command (implements Safe Mining features as well).
craftorders.lua (entity/ai/craftorders.lua)
safemine.lua (./scripts/entity/ai/safemine.lua)
safeallmine.lua (./scripts/entity/ai/safeallmine.lua)
- Re-included standard mining to try to maintain as much compatibility as possible.
Unfortunately, the AI which controls the movement of mining ships is not exposed, at least as far as I can see. It'll take far more effort that initially thought to handle steady-mining.
I'll continue looking into Follow Mode. It is heavily dependent on how the unexposed code handles user input and AI simultaneously which could cause instability, etc. No promises.
As per request, I'll also look into Safe Salvaging. There does already exist a salvaging mod I'll link below, but I'll see if I can add the safety feature to it as well.
-
I like the idea - it would also give reason to have different kinds of ships for different purposes and give reason for certain factions/alliances/bases (thinking forward to future updates here) to be stationed in not-just-the-center. It'd also make ship battles really interesing, trying to use ships that accentuate the weakness of targets. Neat idea you got there Lannik.
-
Minor addenda.
These are just features whose justifications don't require quite the verbosity:
Mail reply system - add a button to reply to message sender
Changing the build menu's F1 (list hotkeys) - Instead of saying XYZ mirror along an axis, say it flips or inverts on/about an axis to avoid confusion with mirrored-building mode
Hover tips - Add hover tips to various health/status bars to show what they are, what they represent, how to read them, etc.
-
I didn't want to flood the board with a bunch of posts so I'll list several ideas in one post. If this is inconvenient or not the norm, let me know and I'd be happy to break it into separate posts.
On another note, many of these features pair up as individually they would not be enough of a meaningful change to warrant effort. Keep that in mind as you peruse.
Also, there will probably be typos. Keep that in mind also as you peruse.
Modified accuracy at a distance
Proposal: Add stability modifier for aiming "long range" weapons, by reducing projectile's lateral velocity either
- for long range weapons based off of its rated range
- when long range weapons are focusing on the same target for long periods of time or tracking at the same angle
Rational:
For long-range weapons (6+km), accuracy matters less and less as the shots seem to have inherent somewhat-random lateral momentum, causing especially 10+ km shots to go wide regardless of how well you try to aim. This really weakens cannons and railguns which fail to work even against very large ships at these distances, negating one of their strongest aspects. One idea is to apply some sort of accuracy-range curve would make weapons with longer ranges have reduced lateral momentum. In other words, make accuracy represent the frequency of hitting a target at the weapon's max range.
With the recent change to the IFG, this might be extremely overpowered as the player would have the ability to selectively attack particular blocks at a sub-5k distances. Then again, that may be within the spirit of the combat system. Another suggestion is to allow for focusing the reticle on a particular target to temporarily increase accuracy (to a certain amount).
Reduced effects of arbitrage
Note: I'm no economist. I'm just really sleepy and couldn't remember the exact word. Hopefully I'm using the right one.
Proposal: Reduce the effects of the disparity between buying and selling prices by:
- Directly reducing differences in prices
- Increasing the volumetric size of trade goods
Rational:
One of the fastest ways to make money is to \[ab\]use arbitrage by buying from one sector at a low price, then selling at another at a high price. Due to the ease of expanding cargo bays and the relative price differences, making money becomes simple. There is little risk of being attacked by NPCs (as you're moving as fast as you can anyays) and so outside of multiplayer and as long as you aren't in excessively dangerous territory, cargo hauling becomes a less-than-stimulating task. With the trade goods system, even moreso. However, rather than removing a potent source of information, reducing the arbitrage by directly change price differences, or increasing the volume required to hold trade goods addresses the problem in several positive manners. Immediately, it directly makes hauling/trading strategic. It's a balance of potential profit, speed, price of ship, crew, etc. It also gives more economic power to haulers/traders. Especially in multiplayer, this stratifies part of the economy and adds a dimension to alliances.
Scaling of money
Proposal: Scale the prices of end-game goods and services as you near the center (gates, repairs, etc.)
Rational:
Money seems terribly easy to come by. One million can buy almost any system or turret, fund the creation of fleets, etc. Aside from creating stations, etc., after a certain point, money becomes inconsequential. While care should be taken to prevent prices from being increased too much (which would stratify people by experience and remove the sandbox anybody-can-do-anything feel Avorion currently has, money shouldn't become just another number.
Creation of service stations
Proposal: Allow for the creation of service stations (gates, shipyards, repair docks)
Rational:
There is currently little reason to invest the time to creation stations. It costs too much money for single players and even when Alliance arrives, there is little reason for the average player to use any of the features provided by the available player-creatable stations. The ability to create these service stations is potent however. And so, stations and factories could have a rating for the potency of their ability to produce goods or render services. The more money is spent and the more crew provided to operate such stations, the more potent the return. Furthermore, the cost of creating service stations (separate from factories) would be higher than the current rate, potentially making it only available to the dedicated, well-connected, or sneaky. To prevent expansion into unfilled systems, densifying the local sectors, restrictions can be placed on where such stations can be made. Off the top of my head, I can imagine the requirement that the system already be under player control, although there is much to be considered in that regard.
A separate but closely related notion is the concept of player-made gates which I would imagine to be extremely expensive, increasingly so for longer-distance travels. They could extoll an optional fee from the user. Those who refuse to pay would lose influence with the owning faction. Additional, those with extremely negative influence are not asked at all. Presumably it would be up to the owning alliance to man, protect, and enforce their own gates.
Manual alteration of faction status
Proposal: Allow players to control their relationship with other factions
Rational:
With the advent of player-alliances and the current presence of player-owned mines/factories, it would make sense to deny usage to enemies. And so, I propose that a faction/alliance would have the ability to alter standing with any other faction/alliance as well as exhibit the personality traits that NPC factions currently exhibit. This would facilitate Friend-or-Foe identification in combat scenarios as well as give granular control over the use of player-owned facilities.
Separation of fleet from gates
Proposal: Spread out members of a fleet when appearing out of a gate
Rational:
The current system allows for too little space, causing players (me) to run into or be run into by a ship when passing through a gate. One option is to vertically and horizontally separate the player. Another is the distribute about the gate at a random distance/direction (but still relatively close). Another option is to temporally separate by seconds the movement time.
Add set-home feature
Proposal: Officially support the set-home feature
Rational:
The community has already modded in the ability to set the player's spawn to any system. Some have gone further to add graphical interfaces and influence-related balancing. This would help players make their way into the galaxy without resorting repeatedly to numerous jumps. To accomodate the potential downside of players using this system to "leapfrog to the finish-line", a cost and faction-friendliness factor could be added. As factions are increasingly hostile near the center, this would accentuate the need to slow the inward motion of players as they place footholds in safe system. This would also encourage players to stay in systems longer to improve relations.
Revert to forward direction outside of build mode
Proposal: Revert to the original direction of the ship when exiting build mode
Rational:
Currently, except for in cases of exceptional situational awareness, after making quick edits, my ship turns around. If these edits are made near other ships, I collide.
Follow-mode
Proposal: Add follow-mode to allow players to follow other players/travelling merchants
Rational:
There is nothing more frustrating than trying to buy from a merchant that constantly moves out of purchasing range. This seems to be less of a problem nowadays so perhaps it was fixed or I used to be terrible at flying.
Listing local objects
Proposal: Add an interface to view in tabular form a list of local objects; add filtering to such list
Rational:
Allow for a list of local objects/ships/etc. and allow for filtering capabilities. This would make it easier to find stations without spinning like a madman. Filtering would also make it easier to determine the closest foe, friend, etc.
Spatial bookmark/waypoints
Proposal: Allow the user to bookmark/waypoint discrete points in space (where blocks are)
Rational:
It is terribly difficult to find things whilst in the middle of a large battle or evading asteroids or foes (or asteroids which act like foes by sprouting out of nowhere and punching your hull in the gut). This would permit users to actually mark things and come back to them. This could augment or replace Listing local objects.
Repair turret AI
Proposal: Fix the problem where repair turrets under "attack", will attack friend or foe ships.
Rational:
It seems that repair turrets will attack foes ships on occassion as well. I like a challenge. I just don't like the challenge to be coming from the wayward crew manning the repair turrets.
Acceleration/speed modifiers
Proposal: Allow for smaller ships to have an acceleration boost either:
- via a block whose potency decreases with ship-size that provides excellent thrust
- directly modifying how thrust/velocity are calculated
Rational:
In combined arms conflict, the largest ships oft are faster and more nimble than their smaller counterparts. This leads smaller ships to become more of a hinderance to maneuvers than an aid. For example, if one made small manned repair-drones, these drones often do not have the engines to match high-acceleration maneuvers the way larger ships can. There are some analogues to this in real life with carriers often being far faster than their support ships. However, the support ships are much more manueverable.
Add/augment manned AI-controlled ship functionality
Proposal:
Add to AI options:
- Orbiting the player
- Healing specifically the player (for repair turrets)
- Fleeing to safety/go away/go to
Augment:
- Allowing AI ships to use boost the way players do
- Allowing AI ships to follow at range
- Allowing AI ships to follow along other vectors other than "right behind you"
Rational:
Currently, having a large interoperable fleet is useful for primarily firepower-augmentation. Support ships such as miners and salvagers can stray into danger and repair ships target whomever they care for (as far as I can tell). The lack of more granular fleet commands makes it difficult to coordinate large fleets. While it can never and was never expected to replace playing with other individuals, the AI in its current state is useful in very particular cases but cannot handle multifaceted ones (follow but not too close, repair me and not the station I'm protecting, etc.).
AI inform player on status
Proposal: Allow the player to see the status (battery level, hyperdrive status, system-info such as trading systems, radar, object detector) of player-owned ships in the system
Rational:
At the moment it is impossible to tell if your mining drone is ambushed or if your follow-me support ship is still 2-seconds away from being able to warp other than switching to that ship. If you are able to communicate with the ship and see its health, it makes sense to provide full operational details to facilitate true fleet-level command strategies.
Indirect battle mechanics
Proposal: Create alternative methods of doing combat focused on denial of capability
Rational:
With the addition of hyperdrive jammers to AI ships, the point of denying enemy ships the ability to move/maneuver opened up an interesting concept of electronic warfare. I propose a set of turrets which would affect the ability of ships to move/jump/target. This would also be useful in finding non-destructive means of avoiding conflict with overzealously aggressive Ai factions and supporting fleet maneuvers. Due to the potentially gamebreaking power of these weapons, they would either require a new type of specialist or a larger crew. Additionally, it would not be beyond realm of reason to balance these weapons with energy costs,
It's absurdly late in the night right now and so I probably wording some things poorly or too strongly or both. Koonschi, you've made an excellent game. If it's any measure of how exceptional and captivating, I spent so long writing this post that the forum kicked me for exceeding the default 60 minute login time. That's how much I enjoy the game, and so I mean no offense in anything I said, especially parts I'll probably look at in the morning and cringe. These are simply my humble opinion on things which I thought could be interesting. Thanks for Avarion and can't wait to see what comes next.
- for long range weapons based off of its rated range
[MOD] Goods Hauler (Automatically buy/sell/move goods!)
in Mods
Posted
Thanks! Just turned out I wasn't logged in while I was looking.