Ludeon Forums
- February 28, 2020, 11:35:18 PM
- Welcome, Guest
|
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1
General Discussion / Re: What games are coming out in July?
« on: July 11, 2016, 06:12:32 PM »
Well, apparently Fallout Shelter for PC finally got a release date. July 14th, one day before Rimworld. Seeing as it is sorta of in the same vein it may cause problems, but who knows.
2
Mods / Re: What would make the game easier to mod?
« on: June 22, 2016, 05:15:28 PM »
Whatever. I'm done. Do with it what you want, I'm out. This is isn't worth the stress and the headaches. I'll go back to quietly lurking and being useless.
EDIT:
I have changed my mind. I won't go quietly. I understand that there will be repercussions for my actions, but at this point I have passed the point of caring of the consequences. I do not care if I get banned, both account and IP from this site. However, this needs to be said and I'll try and be civil.
The biggest problem with modding, is also the most costly to fix; the problem is you, Tynan and until that is fixed, no amount of "small and cheap" fixes will solve the problem.
You have worked in a large development team environment before starting rimworld, with Bioshock Infinite. You know from experience that communication with your fellows is critical in developing a game; if there is no communication there is no game, just a chaotic mess of code, assets, and dreams jammed together in a dysfunctional state. Therefore you, of all people on this site, should know what happens when there is ineffective communication between members working on a project.
Each major modder that works on the game should be considered an unofficial member on the development team as their mods ensures the longevity of the game when it is still in its Alpha Status; without modders, I can safely say that people would have likely forgotten about Rimworld soon after it got out of it's Kickstarter. These modders give life and greater enjoyment to users.
The reason there is modder burnout at all, is due to ineffective communication between yourself and those modders. The reason they can't update their mods is because of decisions you make without consulting them on how it will affect all the other members on the team; if you made similar decisions while working on Bioshock Infinite, without explaining to others the choices you made and why, it would cause huge problems to develop, as they usually do in game companies with ineffective communication. When you change something from public to private or completely refactor code without telling the other members on the team what you are doing, it will break their code and prevent them from doing their job. If you want modders to stick around and actively care about their burnout and the loss for the game as a whole then you need to setup a form of communication between modders and yourself; this wouldn't be necessary if you had only added modding at the end of the development cycle, but if you had, you probably wouldn't be as successful as you've been either.
Treat modders as team members, and explain your reasoning for changes with them, and listen to them on how the changes affect them. Without communication, modders will continue to burnout and many mods will never see the light of day. Your success as a developer and businessman depends on the success of Rimworld. If the modders all burn out before the actual release of the game then the content that they provide will not be present either. And as many users, for many games, feels that mods makes a dull game feel fresh again, you need modders to stick around. The only way that is going to happen is if you actively communicate with modders and try and avoid changing things that will directly prevent them from modding. By communicating with modders on a regular basis and knowing what things they use to make their mods work will help you in making better choices and ensure that modders stick around. Thus, working on learning how to communicate better with modders is the best way to make modding easier, for all involved. However, setting up an effective communication system will likely take a lot of work, trial and error, and working with community on a regular basis eating up development hours, so knowing you, you will likely say it costs too much, that it would take up too much time, divert critical development hours to communication time and dismiss my suggestion due to its cost. I hope that you will implement an effective communication system between yourself and modders; it is the best option. However, if you don't implement some way to communicate better, then I don't think that the potential I saw in the game in its Kickstarter will ever reach fruition and the game that I hoped to play and enjoy when it finally would release will never come to pass. ... But there is always the chance...
That is all.
EDIT:
I have changed my mind. I won't go quietly. I understand that there will be repercussions for my actions, but at this point I have passed the point of caring of the consequences. I do not care if I get banned, both account and IP from this site. However, this needs to be said and I'll try and be civil.
The biggest problem with modding, is also the most costly to fix; the problem is you, Tynan and until that is fixed, no amount of "small and cheap" fixes will solve the problem.
You have worked in a large development team environment before starting rimworld, with Bioshock Infinite. You know from experience that communication with your fellows is critical in developing a game; if there is no communication there is no game, just a chaotic mess of code, assets, and dreams jammed together in a dysfunctional state. Therefore you, of all people on this site, should know what happens when there is ineffective communication between members working on a project.
Each major modder that works on the game should be considered an unofficial member on the development team as their mods ensures the longevity of the game when it is still in its Alpha Status; without modders, I can safely say that people would have likely forgotten about Rimworld soon after it got out of it's Kickstarter. These modders give life and greater enjoyment to users.
The reason there is modder burnout at all, is due to ineffective communication between yourself and those modders. The reason they can't update their mods is because of decisions you make without consulting them on how it will affect all the other members on the team; if you made similar decisions while working on Bioshock Infinite, without explaining to others the choices you made and why, it would cause huge problems to develop, as they usually do in game companies with ineffective communication. When you change something from public to private or completely refactor code without telling the other members on the team what you are doing, it will break their code and prevent them from doing their job. If you want modders to stick around and actively care about their burnout and the loss for the game as a whole then you need to setup a form of communication between modders and yourself; this wouldn't be necessary if you had only added modding at the end of the development cycle, but if you had, you probably wouldn't be as successful as you've been either.
Treat modders as team members, and explain your reasoning for changes with them, and listen to them on how the changes affect them. Without communication, modders will continue to burnout and many mods will never see the light of day. Your success as a developer and businessman depends on the success of Rimworld. If the modders all burn out before the actual release of the game then the content that they provide will not be present either. And as many users, for many games, feels that mods makes a dull game feel fresh again, you need modders to stick around. The only way that is going to happen is if you actively communicate with modders and try and avoid changing things that will directly prevent them from modding. By communicating with modders on a regular basis and knowing what things they use to make their mods work will help you in making better choices and ensure that modders stick around. Thus, working on learning how to communicate better with modders is the best way to make modding easier, for all involved. However, setting up an effective communication system will likely take a lot of work, trial and error, and working with community on a regular basis eating up development hours, so knowing you, you will likely say it costs too much, that it would take up too much time, divert critical development hours to communication time and dismiss my suggestion due to its cost. I hope that you will implement an effective communication system between yourself and modders; it is the best option. However, if you don't implement some way to communicate better, then I don't think that the potential I saw in the game in its Kickstarter will ever reach fruition and the game that I hoped to play and enjoy when it finally would release will never come to pass. ... But there is always the chance...
That is all.
3
Mods / Re: What would make the game easier to mod?
« on: June 22, 2016, 01:14:47 AM »
Well, I did it anyway, and compiled a list of currently "private" variables that could be made "public". These are variables that are understandable to their purpose by just reading the variable OR by understanding the class and thus the variable logically then means "that" (whatever "that" may be). I put it all in a text file for perusal; the structure of it is as follows: Assembly C# -> "namespace" -> "class" -> "variables". The class name and variable name are taken verbatim from ILSpy of Assembly C# for Rimworld. You'll note that I didn't take "all" private variables and suggest turning them into public; instead I only chose the ones that appear logically understandable that could be made public.
While doing it I also noticed that there is A LOT of already made Public Variables, but are not currently moddable by XML, that people (including myself) would love access to.
My personal suggestion for making modding less difficult for us and less costly for you, Tynan, is to teach us how to create XML files of public classes and public variables to create the mods that we want to make. If we knew how to create the XML files (I checked the wiki and elsewhere and couldn't find any tutorials mentioning how to do, so sorry if this is already common knowledge), then we could do a lot of the work that you'd normally have to do to create the XML files yourself.
File attached is again all the possible currently private variables that could logically be made public and be understandable of their purpose to modders. I hope the information is useful in some way, as I did spend about 4 hours putting it together (lots of classes to look through).
[attachment deleted by admin - too old]
While doing it I also noticed that there is A LOT of already made Public Variables, but are not currently moddable by XML, that people (including myself) would love access to.
My personal suggestion for making modding less difficult for us and less costly for you, Tynan, is to teach us how to create XML files of public classes and public variables to create the mods that we want to make. If we knew how to create the XML files (I checked the wiki and elsewhere and couldn't find any tutorials mentioning how to do, so sorry if this is already common knowledge), then we could do a lot of the work that you'd normally have to do to create the XML files yourself.
File attached is again all the possible currently private variables that could logically be made public and be understandable of their purpose to modders. I hope the information is useful in some way, as I did spend about 4 hours putting it together (lots of classes to look through).
[attachment deleted by admin - too old]
4
Mods / Re: What would make the game easier to mod?
« on: June 20, 2016, 06:34:32 PM »
Beat me to the punch before I finished editing my post above yours. Sorry about that; forgot some things I wanted to say.
No, I'm not advocating for all variables to be public. I am advocating for making variables that directly control gameplay to be made public. While intermediary variables or variables that shouldn't be touched at all as modifying them may cause runtime errors, should be kept private.
EDIT:
A rule of thumb I'd use is if I can read a variable and instantly understand what it would do, then it should be made public. If I can't understand what it does without understanding how that variable is implemented or what are specific conditions that must remain "true" to have that variable perform as expected, then it should be private.
So, taking from Assembly # -> Rimworld -> InteractionWorker_RecruitAttempt:
private const float MinMoodToRecruit = 0.35f;
I can read the above variable and instantly know what this variable will do. It makes it so that any pawn with a mood score of 34 or less, cannot be recruited or stating it another way, a pawn needs 35+ to even have a chance at recruition.
However, something like (Assembly # -> Rimworld -> ITab_Pawn_Health):
private const int HideBloodLossTicksThreshold = 60000;
Looking at that variable above it is very hard to know what it does by simply looking at it. I'd need to understand how it is implemented to be able to use it, and thus, should be left private.
So, I'd suggest that to have powerful interfaces, that any variable that can be easily understood to what it does or doesn't do, should be make public, while variables that would require understanding what it does and what conditions are required to keep it working as intended, should be left private.
If you "want" I can take the time to go through the various files and make a list (including which class I found them in) of variables that I can instantly figure out their purpose and thus should be made public. I'd of course put it into a text file to avoid a super long post of details, and then upload the text file as an attachment. But only if you want me to.
I'd think it would be simpler to have me provide a list of variables that should be made public to make it easier on you in making the changes but it will take me a lot of work to do it and if you don't want it down, no point in doing it... right? So, if you do want me to look through the entire assembly and build you a list of variables that could be made public, then I'll do it.
No, I'm not advocating for all variables to be public. I am advocating for making variables that directly control gameplay to be made public. While intermediary variables or variables that shouldn't be touched at all as modifying them may cause runtime errors, should be kept private.
EDIT:
A rule of thumb I'd use is if I can read a variable and instantly understand what it would do, then it should be made public. If I can't understand what it does without understanding how that variable is implemented or what are specific conditions that must remain "true" to have that variable perform as expected, then it should be private.
So, taking from Assembly # -> Rimworld -> InteractionWorker_RecruitAttempt:
private const float MinMoodToRecruit = 0.35f;
I can read the above variable and instantly know what this variable will do. It makes it so that any pawn with a mood score of 34 or less, cannot be recruited or stating it another way, a pawn needs 35+ to even have a chance at recruition.
However, something like (Assembly # -> Rimworld -> ITab_Pawn_Health):
private const int HideBloodLossTicksThreshold = 60000;
Looking at that variable above it is very hard to know what it does by simply looking at it. I'd need to understand how it is implemented to be able to use it, and thus, should be left private.
So, I'd suggest that to have powerful interfaces, that any variable that can be easily understood to what it does or doesn't do, should be make public, while variables that would require understanding what it does and what conditions are required to keep it working as intended, should be left private.
If you "want" I can take the time to go through the various files and make a list (including which class I found them in) of variables that I can instantly figure out their purpose and thus should be made public. I'd of course put it into a text file to avoid a super long post of details, and then upload the text file as an attachment. But only if you want me to.
I'd think it would be simpler to have me provide a list of variables that should be made public to make it easier on you in making the changes but it will take me a lot of work to do it and if you don't want it down, no point in doing it... right? So, if you do want me to look through the entire assembly and build you a list of variables that could be made public, then I'll do it.
5
Mods / Re: What would make the game easier to mod?
« on: June 20, 2016, 06:17:52 PM »
Well, the simplest suggestion is to change your coding best practices to a style that supports modding.
What I mean by this is that when I took the time to learn C++ on my own, every tutorial and book I read always suggested making member variables of classes private with specific mutator functions to modify them or accessor functions to access them. However, all of these tutorials assume that no one else will be touching the code and assumes that users cannot modify the code; everything should be hard-coded and only touchable by the programmer(s). This is the style of "best programming practice" that is also taught in textbooks (I took a class in introductory C++ in College) and schools. However, as Rimworld is being designed as a game that supports and encourages modding, this implies that the common "best programming practices" do not necessarily apply fully to Rimworld (some still apply such as good variable names, good formatting, comments when necessary, etc)
So my suggestion is this:
1) Change all current Private Variables to Public Variables. Any variable that a user may want to modify, particularly pertaining to specific gameplay mechanics, should be made Public.
2) Only use Private Variables for Variables that should not be user edited at all. These are Variables that if incorrectly modified could cause severe Runtime Errors or Memory Leaks (or is a Memory Leak a form of Runtime Error; I ask because some say its a logic error due to improper usage of calls to delete and others call it a runtime error as it kills the program when the memory leak gets too big) that would be difficult to debug. Or variables that are used as intermediary temporary variables that would serve no real purpose for a modder anyway.
By keeping most of the gameplay mechanics public variables, and only specific variables that should never be user modifiable private, it would make modding easier and would hopefully make updating old mods to new mods a lot easier as well.
The simplest way to do the conversion is to use the Find and Replace tool; that would be the quickest way, and then go through it and change the few variables that should never be edited back to private.
To illustrate this point I'll refer to Assembly # -> Rimworld -> IntermittentSteamSprayer:
NOTE: Using this as an example, even though I doubt anyway would change this, but this class helps to illustrate my point so that is why I'm using it.
private const int MinTicksBetweenSprays = 500;
private const int MaxTicksBetweenSprays = 2000;
private const int MinSprayDuration = 200;
private const int MaxSprayDuration = 500;
private const float SprayThickness = 0.6f;
These should be made public variables. However:
private int sprayTicksLeft;
Should be left as private. It doesn't appear to be something modders should have access to as it looks like an intermediary temporary variable.
Hope that explains things better. I'm definitely not asking for everything to be made public. However, things that directly control gameplay should be available to modders while things that should never be touched by modders should remain private.
What I mean by this is that when I took the time to learn C++ on my own, every tutorial and book I read always suggested making member variables of classes private with specific mutator functions to modify them or accessor functions to access them. However, all of these tutorials assume that no one else will be touching the code and assumes that users cannot modify the code; everything should be hard-coded and only touchable by the programmer(s). This is the style of "best programming practice" that is also taught in textbooks (I took a class in introductory C++ in College) and schools. However, as Rimworld is being designed as a game that supports and encourages modding, this implies that the common "best programming practices" do not necessarily apply fully to Rimworld (some still apply such as good variable names, good formatting, comments when necessary, etc)
So my suggestion is this:
1) Change all current Private Variables to Public Variables. Any variable that a user may want to modify, particularly pertaining to specific gameplay mechanics, should be made Public.
2) Only use Private Variables for Variables that should not be user edited at all. These are Variables that if incorrectly modified could cause severe Runtime Errors or Memory Leaks (or is a Memory Leak a form of Runtime Error; I ask because some say its a logic error due to improper usage of calls to delete and others call it a runtime error as it kills the program when the memory leak gets too big) that would be difficult to debug. Or variables that are used as intermediary temporary variables that would serve no real purpose for a modder anyway.
By keeping most of the gameplay mechanics public variables, and only specific variables that should never be user modifiable private, it would make modding easier and would hopefully make updating old mods to new mods a lot easier as well.
The simplest way to do the conversion is to use the Find and Replace tool; that would be the quickest way, and then go through it and change the few variables that should never be edited back to private.
To illustrate this point I'll refer to Assembly # -> Rimworld -> IntermittentSteamSprayer:
NOTE: Using this as an example, even though I doubt anyway would change this, but this class helps to illustrate my point so that is why I'm using it.
private const int MinTicksBetweenSprays = 500;
private const int MaxTicksBetweenSprays = 2000;
private const int MinSprayDuration = 200;
private const int MaxSprayDuration = 500;
private const float SprayThickness = 0.6f;
These should be made public variables. However:
private int sprayTicksLeft;
Should be left as private. It doesn't appear to be something modders should have access to as it looks like an intermediary temporary variable.
Hope that explains things better. I'm definitely not asking for everything to be made public. However, things that directly control gameplay should be available to modders while things that should never be touched by modders should remain private.
6
Mods / Re: What would make the game easier to mod?
« on: June 19, 2016, 04:33:00 AM »
Not quite sure precisely where to find it in the Assembly, but:
Being able to mod the time-scale "buttons". What I mean by this is that there are currently three buttons: Normal, Fast and Faster. It would be great for modders to have these accessible for modding purposes.
Personally, I think "Normal" is too fast, and "Faster" is too slow, and would love to be able to modify these to personal preferences. "Normal" is the speed I play at only when it is "Combat" and that is because it is forced upon me, however I find that the progress of Combat goes too fast for me to create effective strategies, especially with large numbers of colonists and raiders having a pitched firefight. Thus, personally, I'd mod it to be slower than current game speed to make the creation and maintaining of strategies viable... but that is a personal preference. Similiarly, I'd want to make "Faster" go much faster than it currently is (probably about the same "sped up pace" that is shown in the Trailers) so that I can progress the base faster once I've decided upon layouts with "Faster". And then probably set "Fast" to the current "Normal" speed.
I'd specify the exact code to change but as I don't have a clue where to look in the Assembly file, I can't provide them. If someone does know what they are, could you point me to the file so that I can list of the specific variables I'd like to be Public/XML moddable?
Being able to mod the time-scale "buttons". What I mean by this is that there are currently three buttons: Normal, Fast and Faster. It would be great for modders to have these accessible for modding purposes.
Personally, I think "Normal" is too fast, and "Faster" is too slow, and would love to be able to modify these to personal preferences. "Normal" is the speed I play at only when it is "Combat" and that is because it is forced upon me, however I find that the progress of Combat goes too fast for me to create effective strategies, especially with large numbers of colonists and raiders having a pitched firefight. Thus, personally, I'd mod it to be slower than current game speed to make the creation and maintaining of strategies viable... but that is a personal preference. Similiarly, I'd want to make "Faster" go much faster than it currently is (probably about the same "sped up pace" that is shown in the Trailers) so that I can progress the base faster once I've decided upon layouts with "Faster". And then probably set "Fast" to the current "Normal" speed.
I'd specify the exact code to change but as I don't have a clue where to look in the Assembly file, I can't provide them. If someone does know what they are, could you point me to the file so that I can list of the specific variables I'd like to be Public/XML moddable?
7
Releases / Re: [A13] Glitter Tech v1.45 - New Surgery free version
« on: June 18, 2016, 09:28:14 PM »
Okay, nice. Appreciate the response. I look forward to the day when one can play as a full-out glitterworld colony, and wish you the best of luck with that! I've always enjoyed your mod and look forward to the future of it.
Some other high-tech ideas:
-> Cloaking Suit = Worn like a nano suit, but makes the pawn invisible until they fire, and they remain visible for a few seconds before recloaking. Ideal for snipers or assassins, allowing them to fire, relocate elsewhere, and wait for their next opportunity. Could also make it that if you attack with melee from cloaked, they deal x2 damage for a sneak attack.
-> Microjet Launcher (ie Devestator from Duke3D) = Fires mini rockets at a high rate of fire causing small explosions on impact. Great for destroying structures or vehicles quickly, but due to their size, are not very damaging to infantry.
-> Deflector Shield = A carried shield (not to be confused with personal shield; ie a physical shield worn on arm) that when energy-based weapons hit it, they are deflected harmlessly in a random direction. However, regular bullets, shells and rockets are unaffected. Helps infantry survive high-tech weaponry by making those weapons basically ineffective against them, but low-grade rifles can still give them a bad day.
-> Nanohive Implant (ie Nanorobots that Borg have) = An implant that causes all damaged limbs to slowly regenerate damage, aiding the natural healing process and can even remove scars or old wounds if given enough time.
-> Shoulder-Mounted Gauss Cannon = A high-powered weapon that deals extremely high damage to vehicles and structures and can kill infantry, but due to its extreme reload time, its better to use on heavily armored targets for best effect. Has extreme range and very accurate at extreme ranges, but its long-reload time (ie 1.5x to 2.0x that of the Sniper Rifle; so 5-8 second reload time) makes it a weapon good for a single shot before realistically having to find a new weapon to fight with.
-> Nano Rifle (ie think Red Faction 3) = A weapon when fired at an object destroys it an a molecular level, but has short range and is inaccurate, and thus is very powerful but only in tight corridors.
-> Neutron Cannon = A weapon that bypasses armor and other defenses to kill biological components. It will often cause massive organ failure, but leave armor, weapons, and even bionic parts fully intact and undamaged.
-> Rust Monster (new animal/genetically engineered) = A creature that will devour anything metallic and can only be fed metals as meals. Will happily devour your foes weapons, armor, and turrets, but leave them unharmed, and often nude. Ineffective against tribals, as most of their gear is non-metallic.
-> Nano Plague (Incident) = A plague on all advanced "component" based objects. Causes all objects that are created with "components" to break down, and cannot be fixed until the Nano Plague ends. Disasterous for a glitterworld colony.
-> Military Crash Site (Incident) = A military freighter crashes nearby containing various caches of supplies of weapons, armor, resources, and medicine ripe for the picking!
-> Regenerative Armor = Armor that repairs itself of damage over time, and thus if kept from complete destruction, will eventually fully repair itself.
-> Repair Mine = Taking the idea of the fire-popper introduced in A13, have a mine that when explodes, repairs all objects, furnishings, turrets, and wall/door of damage. Great for when you need repairs badly but all your colonists are busy fighting off enemies.
-> Kamikaze Droid = A robot that runs into a group of enemies and explodes violently damaging all of them. If "killed" before reaching it's intended target, it also explodes violently, making them a situationally useful unit; great for ambushes or areas where it can easily reach its target but not ideal for wide open areas or areas when it might suffer sustained fire destroying it before it reaches its target.
-> Psychic Tower (think Red Alert 2 Yuri's Revenge) = Projects a constant field of energy around it that affects different people differently. For colonists or friendlies it soothes them, improving their mood which goes away after leaving the area. For enemies it terrifies, maddens, or confuses them, causes a large mood loss which goes away after leaving the area. Ideal for colonists about to break to calm down in the area, and ideal for making some invaders go crazy and have mental breaks.
-> Tank Assembler = Can assemble your own "tanks" and use them to defend your base with. They act like colonists stuck in permanent "combat" mode, and can be ordered to stay in one spot or move forward. Benefits from cover.
-> Wall Turret (think StarCraft 1) = These hide in walls until a target comes within range and starts firing at them. Comes in minigun, flamethrower, and missile turrets.
-> Spider Mines (think StarCraft 1) = These hide in the ground until a target comes within range, unburrows, and kamikazes with that target if they can.
-> BFG 9000 = Nuff said. A powerful charge-up weapon that obliterates targets caught within it's blast radius.
-> Nano Anti-Viral Implant = An implant that makes the pawn immune to all diseases and cures any diseases they currently have.
-> Temporary Organs = An organ that functions at 75% capabilities, but is cheap to produce and keeps the subject alive. Ideal for when an organ is destroyed or you don't have a suitable replacement or when damage is so great to the organ, that a temporary organ is better anyway (ie brain is at 2/10 HP as an example)
-----
-> Weapon Ideas:
1) Belt-Fed Automatic Shotgun (ie the Schwarzer Zwerg from Russian Overkill; huge rate of fire, but very inaccurate)
2) Flak Cannon (fires hot lead like a shotgun but also applies a fire effect)
3) New "charge" weapons (ie Charge Rifle in game) = Pistol, Sniper Rifle, and Shotgun
4) Thermite Thrower = Like a flamethrower but much, much, much worse
5) Sonic Disruptor (ie think Disruptor tank from Tiberium Sun) = Great against everything but causes friendly fire as it hits all targets caught in its line of damage.
Could also include other modders stuff like:
-> Old wound removal
-> Animal Surgeries
-> Organ Growing
-----
EDIT: More Ideas:
Prison Suppression Turret = A powerful turret designed to inflict maximum pain, stunning, and bruising, but with the minimal amount of actual bodily harm. Effective at close range, such as inside a prison-designated area to suppress unhappy prisoners without blowing limbs/organs off and without killing them. Like being peppered with hundreds of paint balls every second; painful, causes lots of bruising but unlikely to be fatal.
Airlock Containment System = So in many military bases of today or even quarantine hospitals, they have an airlock that kills off bacteria and viruses on the skin/clothing of people walking into them to keep areas sterilized and to prevent airborne contaminants from entering. For a mountain fortress or even a medical hospital room, having an Airlock like this could be used to prevent the transmission of infectious diseases to other pawns and possibly even aid in killing off these diseases faster.
Advanced Cooling System = A powerful glitterworld cooler that can easily push temperatures below -100 (and blow out like 200+ out the other end) with some extra power consumption over a base model. Ideally used during heatwaves to keep a base cool, or during extremely cold winters to keep the base hot.
Blast Vent = A heavily reinforced vent used with the same materials and constructed in the same manner as Blast Doors. This is so that a raiding force doesn't decide to blow up the Vents and get into a mountain fortress by going through your venting system to strike at your base from the rear. Heavily reinforced vents would do this job quite well.
Laser Lattice Defense System (think first Resident Evil movie) = Can only be constructed for 1x1 hallways, where a lattice can optionally form (at high energy consumption so disable when not in use) and deals heavy damage to targets walking through the laser lattice. So to make it you need two Laser Walls built 1x1 square apart and power is toggled to them; when on lasers deal damage. When off, they don't deal damage or take up power. An ideal defense in a fortress where you can easily force funnel foes down the corridor for maximum effect.
Glitterworld Ceiling Blast Doors (think of the blast doors on Missile Silos) = So these can open or close, and thus remove or add a roof to an area. These can be built underground or out in the open and allows the adding or removing off these roofs. This would allow things like underground farms exposed to sunlight when doors open, having underground orbital trade beacons that function when the roof is removed, or even having artillery that can work when the roof is removed.
Planetary Defensive Cannon = A high-powered (huge energy consumption) weapon of massive destruction. Whenever an enemy ship, that normally would send down drop pods of raiders, comes within range, instead of having a raid, it blasts that ship to pieces. This causes metal slag, resources, and raider-faction escape pods to crash all over the map. An endgame weapon for deterring enemy ships from landing droppods in your sector of the planet.
Gas Chamber = Gasses whoever is inside the gas chamber when it is activated. Comes in several varieties of wall dispensers of gas = Nerve Gas (Kills Biological), Hallucigen (Causes huge negative thought penalty), Joy (Causes huge positive thought bonus), Sleep (Incaps targets affected by it) or Pepper Spray (Causes incredible agony and stunning). Great for a defensive measure, or to place in a prison, or to weaken invaders or aid defenders. Each dispenser covers a 3x3 area around the dispenser, so multiple would be needed to fully cover a large room.
Glitterworld Stasis Bed = A high-tech bed that greatly speeds up health recovery and restfulness allowing colonists to quickly regain rest and allowing more things to be done in a day. Stasis fields prevent the passage of time on the user, so they wake up refreshed as if no time went by at all.
Glitterworld Food Fabricator = A high-tech nutrient dispenser that actually produces extremely tasty and varied meals depending on the user's preference when getting a meal. Works similar to a Replicator in Star Trek, but only can produce meals. Provides a greater morale/joy boost than even Fine Meals, but maybe not Lavish Meals.
-----
More Stuff:
Large Scale Smelter = Pile all the metallic objects you want smelted down into their base resources inside a smelting room. Any non-metallic objects are burned to a crisp instead of producing resources. Then activate the smelter and it instantly converts any items inside into the various metals that would normally be used to make the items, to provide a faster way of mass-smelting items.
High Precision Cleaning Laser = Works to obliterate even the tiniest of dirty messes in its area of effect, and thus prevents mess of any kind from appearing within its radius and any existing is eliminated instantly when the cleaning laser is built. Causes no damage, but makes cleaning less of a chore.
Reversed Effect Field (think the Justice Field in Red Dwarf Episode "Justice") = Basically, whatever "bad" thing someone does to you, is harmless reflected back at them. So if a pawn tries to punch another pawn within this field, the pawn they touched feels no pain, but the one doing the punching feels like they just got punched full force. Same applies to breaking of bones; you try and break someone else's bones, you instead break your own bones. This kind of system would be great as a defense system in a Prison, as any attacks an angry prisoner throws damages themselves instead of their intended target.
Healing Gun = Heals damage instead of dealing damage. Much like the Medic's gun in Team Fortress 2.
Pacification Field = Targets under the effects of this field become easier to recruit over time. Very useful on captured Commandos, which are almost impossible to recruit. With this field in place in a prison though, you might after a couple days/weeks, be able to recruit one.
All for now
Some other high-tech ideas:
-> Cloaking Suit = Worn like a nano suit, but makes the pawn invisible until they fire, and they remain visible for a few seconds before recloaking. Ideal for snipers or assassins, allowing them to fire, relocate elsewhere, and wait for their next opportunity. Could also make it that if you attack with melee from cloaked, they deal x2 damage for a sneak attack.
-> Microjet Launcher (ie Devestator from Duke3D) = Fires mini rockets at a high rate of fire causing small explosions on impact. Great for destroying structures or vehicles quickly, but due to their size, are not very damaging to infantry.
-> Deflector Shield = A carried shield (not to be confused with personal shield; ie a physical shield worn on arm) that when energy-based weapons hit it, they are deflected harmlessly in a random direction. However, regular bullets, shells and rockets are unaffected. Helps infantry survive high-tech weaponry by making those weapons basically ineffective against them, but low-grade rifles can still give them a bad day.
-> Nanohive Implant (ie Nanorobots that Borg have) = An implant that causes all damaged limbs to slowly regenerate damage, aiding the natural healing process and can even remove scars or old wounds if given enough time.
-> Shoulder-Mounted Gauss Cannon = A high-powered weapon that deals extremely high damage to vehicles and structures and can kill infantry, but due to its extreme reload time, its better to use on heavily armored targets for best effect. Has extreme range and very accurate at extreme ranges, but its long-reload time (ie 1.5x to 2.0x that of the Sniper Rifle; so 5-8 second reload time) makes it a weapon good for a single shot before realistically having to find a new weapon to fight with.
-> Nano Rifle (ie think Red Faction 3) = A weapon when fired at an object destroys it an a molecular level, but has short range and is inaccurate, and thus is very powerful but only in tight corridors.
-> Neutron Cannon = A weapon that bypasses armor and other defenses to kill biological components. It will often cause massive organ failure, but leave armor, weapons, and even bionic parts fully intact and undamaged.
-> Rust Monster (new animal/genetically engineered) = A creature that will devour anything metallic and can only be fed metals as meals. Will happily devour your foes weapons, armor, and turrets, but leave them unharmed, and often nude. Ineffective against tribals, as most of their gear is non-metallic.
-> Nano Plague (Incident) = A plague on all advanced "component" based objects. Causes all objects that are created with "components" to break down, and cannot be fixed until the Nano Plague ends. Disasterous for a glitterworld colony.
-> Military Crash Site (Incident) = A military freighter crashes nearby containing various caches of supplies of weapons, armor, resources, and medicine ripe for the picking!
-> Regenerative Armor = Armor that repairs itself of damage over time, and thus if kept from complete destruction, will eventually fully repair itself.
-> Repair Mine = Taking the idea of the fire-popper introduced in A13, have a mine that when explodes, repairs all objects, furnishings, turrets, and wall/door of damage. Great for when you need repairs badly but all your colonists are busy fighting off enemies.
-> Kamikaze Droid = A robot that runs into a group of enemies and explodes violently damaging all of them. If "killed" before reaching it's intended target, it also explodes violently, making them a situationally useful unit; great for ambushes or areas where it can easily reach its target but not ideal for wide open areas or areas when it might suffer sustained fire destroying it before it reaches its target.
-> Psychic Tower (think Red Alert 2 Yuri's Revenge) = Projects a constant field of energy around it that affects different people differently. For colonists or friendlies it soothes them, improving their mood which goes away after leaving the area. For enemies it terrifies, maddens, or confuses them, causes a large mood loss which goes away after leaving the area. Ideal for colonists about to break to calm down in the area, and ideal for making some invaders go crazy and have mental breaks.
-> Tank Assembler = Can assemble your own "tanks" and use them to defend your base with. They act like colonists stuck in permanent "combat" mode, and can be ordered to stay in one spot or move forward. Benefits from cover.
-> Wall Turret (think StarCraft 1) = These hide in walls until a target comes within range and starts firing at them. Comes in minigun, flamethrower, and missile turrets.
-> Spider Mines (think StarCraft 1) = These hide in the ground until a target comes within range, unburrows, and kamikazes with that target if they can.
-> BFG 9000 = Nuff said. A powerful charge-up weapon that obliterates targets caught within it's blast radius.
-> Nano Anti-Viral Implant = An implant that makes the pawn immune to all diseases and cures any diseases they currently have.
-> Temporary Organs = An organ that functions at 75% capabilities, but is cheap to produce and keeps the subject alive. Ideal for when an organ is destroyed or you don't have a suitable replacement or when damage is so great to the organ, that a temporary organ is better anyway (ie brain is at 2/10 HP as an example)
-----
-> Weapon Ideas:
1) Belt-Fed Automatic Shotgun (ie the Schwarzer Zwerg from Russian Overkill; huge rate of fire, but very inaccurate)
2) Flak Cannon (fires hot lead like a shotgun but also applies a fire effect)
3) New "charge" weapons (ie Charge Rifle in game) = Pistol, Sniper Rifle, and Shotgun
4) Thermite Thrower = Like a flamethrower but much, much, much worse
5) Sonic Disruptor (ie think Disruptor tank from Tiberium Sun) = Great against everything but causes friendly fire as it hits all targets caught in its line of damage.
Could also include other modders stuff like:
-> Old wound removal
-> Animal Surgeries
-> Organ Growing
-----
EDIT: More Ideas:
Prison Suppression Turret = A powerful turret designed to inflict maximum pain, stunning, and bruising, but with the minimal amount of actual bodily harm. Effective at close range, such as inside a prison-designated area to suppress unhappy prisoners without blowing limbs/organs off and without killing them. Like being peppered with hundreds of paint balls every second; painful, causes lots of bruising but unlikely to be fatal.
Airlock Containment System = So in many military bases of today or even quarantine hospitals, they have an airlock that kills off bacteria and viruses on the skin/clothing of people walking into them to keep areas sterilized and to prevent airborne contaminants from entering. For a mountain fortress or even a medical hospital room, having an Airlock like this could be used to prevent the transmission of infectious diseases to other pawns and possibly even aid in killing off these diseases faster.
Advanced Cooling System = A powerful glitterworld cooler that can easily push temperatures below -100 (and blow out like 200+ out the other end) with some extra power consumption over a base model. Ideally used during heatwaves to keep a base cool, or during extremely cold winters to keep the base hot.
Blast Vent = A heavily reinforced vent used with the same materials and constructed in the same manner as Blast Doors. This is so that a raiding force doesn't decide to blow up the Vents and get into a mountain fortress by going through your venting system to strike at your base from the rear. Heavily reinforced vents would do this job quite well.
Laser Lattice Defense System (think first Resident Evil movie) = Can only be constructed for 1x1 hallways, where a lattice can optionally form (at high energy consumption so disable when not in use) and deals heavy damage to targets walking through the laser lattice. So to make it you need two Laser Walls built 1x1 square apart and power is toggled to them; when on lasers deal damage. When off, they don't deal damage or take up power. An ideal defense in a fortress where you can easily force funnel foes down the corridor for maximum effect.
Glitterworld Ceiling Blast Doors (think of the blast doors on Missile Silos) = So these can open or close, and thus remove or add a roof to an area. These can be built underground or out in the open and allows the adding or removing off these roofs. This would allow things like underground farms exposed to sunlight when doors open, having underground orbital trade beacons that function when the roof is removed, or even having artillery that can work when the roof is removed.
Planetary Defensive Cannon = A high-powered (huge energy consumption) weapon of massive destruction. Whenever an enemy ship, that normally would send down drop pods of raiders, comes within range, instead of having a raid, it blasts that ship to pieces. This causes metal slag, resources, and raider-faction escape pods to crash all over the map. An endgame weapon for deterring enemy ships from landing droppods in your sector of the planet.
Gas Chamber = Gasses whoever is inside the gas chamber when it is activated. Comes in several varieties of wall dispensers of gas = Nerve Gas (Kills Biological), Hallucigen (Causes huge negative thought penalty), Joy (Causes huge positive thought bonus), Sleep (Incaps targets affected by it) or Pepper Spray (Causes incredible agony and stunning). Great for a defensive measure, or to place in a prison, or to weaken invaders or aid defenders. Each dispenser covers a 3x3 area around the dispenser, so multiple would be needed to fully cover a large room.
Glitterworld Stasis Bed = A high-tech bed that greatly speeds up health recovery and restfulness allowing colonists to quickly regain rest and allowing more things to be done in a day. Stasis fields prevent the passage of time on the user, so they wake up refreshed as if no time went by at all.
Glitterworld Food Fabricator = A high-tech nutrient dispenser that actually produces extremely tasty and varied meals depending on the user's preference when getting a meal. Works similar to a Replicator in Star Trek, but only can produce meals. Provides a greater morale/joy boost than even Fine Meals, but maybe not Lavish Meals.
-----
More Stuff:
Large Scale Smelter = Pile all the metallic objects you want smelted down into their base resources inside a smelting room. Any non-metallic objects are burned to a crisp instead of producing resources. Then activate the smelter and it instantly converts any items inside into the various metals that would normally be used to make the items, to provide a faster way of mass-smelting items.
High Precision Cleaning Laser = Works to obliterate even the tiniest of dirty messes in its area of effect, and thus prevents mess of any kind from appearing within its radius and any existing is eliminated instantly when the cleaning laser is built. Causes no damage, but makes cleaning less of a chore.
Reversed Effect Field (think the Justice Field in Red Dwarf Episode "Justice") = Basically, whatever "bad" thing someone does to you, is harmless reflected back at them. So if a pawn tries to punch another pawn within this field, the pawn they touched feels no pain, but the one doing the punching feels like they just got punched full force. Same applies to breaking of bones; you try and break someone else's bones, you instead break your own bones. This kind of system would be great as a defense system in a Prison, as any attacks an angry prisoner throws damages themselves instead of their intended target.
Healing Gun = Heals damage instead of dealing damage. Much like the Medic's gun in Team Fortress 2.
Pacification Field = Targets under the effects of this field become easier to recruit over time. Very useful on captured Commandos, which are almost impossible to recruit. With this field in place in a prison though, you might after a couple days/weeks, be able to recruit one.
All for now
8
General Discussion / Re: what happend to the regular updates on rimworld development that we use to get?
« on: June 18, 2016, 02:33:28 PM »
On this topic, what happened to that Sticky that referred people to that "daily updates" / "daily progress" thing? I know a second one was created sometime in 2015, but I can't find a link for that anymore.
9
General Discussion / Re: What games are coming out in July?
« on: June 18, 2016, 01:05:04 AM »
Other things in July are dlc for fallout 4, and EITR and Below will likely come out soon; Below is summer 2016, while EITR is q2/q3 2016.
As far as similiar in simulation/combat, I cant think of any except fallout shelter.
Likely its best to release early July rather than later to avoid people saving money for summer sale or other big releases. Or even beat everyone, and release on last day of June to beat July frenzy.
Also, here is a list of July releases:
http://www.vg247.com/2016/05/11/video-game-release-dates-2016/
As far as similiar in simulation/combat, I cant think of any except fallout shelter.
Likely its best to release early July rather than later to avoid people saving money for summer sale or other big releases. Or even beat everyone, and release on last day of June to beat July frenzy.
Also, here is a list of July releases:
http://www.vg247.com/2016/05/11/video-game-release-dates-2016/
10
Mods / Re: What would make the game easier to mod?
« on: June 17, 2016, 04:52:06 AM »
Specific C# Changes:
Most important to me:
Assembly # -> Rimworld -> LearnRates
Could you please make each of these variables XML moddable.
------
Other areas I'd love access to, but less so than above:
Assembly # -> Rimworld -> InfestationCellFinder
private const float MinRequiredScore = 6f;
private const int MountainousnessScoreRadialPatternIdx = 700;
private const int MountainousnessScoreRadialPatternSkip = 10;
private const float MountainousnessScorePerRock = 1f;
private const float MountainousnessScorePerThickRoof = 0.5f;
private const float MinCellTempToSpawnHive = -17f;
Can you make these all public (or make them XML moddable), so that modders can modify how insect hives behave, and how quickly they can multiply, etc...
Assembly # -> Rimworld -> InteractionWorker_RecruitAttempt
private const float MinMoodToRecruit = 0.35f;
private const float MinRecruitChance = 0.005f;
private const float BondRelationChanceFactor = 1.5f;
I like having fine-tuned control over recruitment, sometimes making it easier other times harder. Would love to have access to this stuff in either public or xml.
Most important to me:
Assembly # -> Rimworld -> LearnRates
Could you please make each of these variables XML moddable.
------
Other areas I'd love access to, but less so than above:
Assembly # -> Rimworld -> InfestationCellFinder
private const float MinRequiredScore = 6f;
private const int MountainousnessScoreRadialPatternIdx = 700;
private const int MountainousnessScoreRadialPatternSkip = 10;
private const float MountainousnessScorePerRock = 1f;
private const float MountainousnessScorePerThickRoof = 0.5f;
private const float MinCellTempToSpawnHive = -17f;
Can you make these all public (or make them XML moddable), so that modders can modify how insect hives behave, and how quickly they can multiply, etc...
Assembly # -> Rimworld -> InteractionWorker_RecruitAttempt
private const float MinMoodToRecruit = 0.35f;
private const float MinRecruitChance = 0.005f;
private const float BondRelationChanceFactor = 1.5f;
I like having fine-tuned control over recruitment, sometimes making it easier other times harder. Would love to have access to this stuff in either public or xml.
11
Mods / Re: What would make the game easier to mod?
« on: June 17, 2016, 12:52:11 AM »
Well, if there was a specific XML request, it would be to have editable files in each of the folders in Core. Several folders have nothing in them like, BrokenStateDefs and PawnKindsDefs. That or remove the empty folders to avoid confusion.
12
Mods / Re: What would make the game easier to mod?
« on: June 16, 2016, 04:00:29 PM »
Well, it is good to hear that you still will take XMLs suggestions, but I got none. The only really good suggestion is thus:
Keep a list of contact email addresses of prominent modders that have been burnt out by the current modding scene, with the constant changing code base, and contact them when the game is close to final stable release telling them that the code isn't likely to change as much anymore, so that updating their mods isn't torturous to do anymore. As mods keep the game interesting with extra content, having modders get burned out is a huge loss for the community and game. Most quit after being unable to update their mod to the next alpha, thus if the code is relatively final, they might be encouraged to come back.
All I got though. Cheers!
Keep a list of contact email addresses of prominent modders that have been burnt out by the current modding scene, with the constant changing code base, and contact them when the game is close to final stable release telling them that the code isn't likely to change as much anymore, so that updating their mods isn't torturous to do anymore. As mods keep the game interesting with extra content, having modders get burned out is a huge loss for the community and game. Most quit after being unable to update their mod to the next alpha, thus if the code is relatively final, they might be encouraged to come back.
All I got though. Cheers!
13
Mods / Re: What would make the game easier to mod?
« on: June 16, 2016, 02:31:43 AM »
Fine I'll stop.
Again, simple is relative. But, I digress. In the future, Tynan, clarify exactly what you are looking for and you'll get a lot less garbage to sift through and a lot fewer crushed spirits. We don't know what you are looking for and thus cannot provide responses that you want.
Now that we know that you only want specific C# code changes for just C# modders, I'm sure that is the only responses you will get from now on in, now that we know you don't want XML changes. Thank you for the clarification.
Again, simple is relative. But, I digress. In the future, Tynan, clarify exactly what you are looking for and you'll get a lot less garbage to sift through and a lot fewer crushed spirits. We don't know what you are looking for and thus cannot provide responses that you want.
Now that we know that you only want specific C# code changes for just C# modders, I'm sure that is the only responses you will get from now on in, now that we know you don't want XML changes. Thank you for the clarification.
14
Mods / Re: What would make the game easier to mod?
« on: June 15, 2016, 09:32:44 PM »
The problem with any suggestion is what is defined as simple or cheap to implement; always depends on multiple factors from coding style, how much refactoring is necessary, personal view on what should be allowed to be modded and if the suggestion is something one feels like doing. Without knowing precisely how Tynan defines simple, I'm kind of using the "shotgun approach", and firing off multiple possible areas that I'd love to see made more open, but not necessarily having any expectation that any of them will be implemented.
Something I might see as complicated to implement, Tynan might see it as simple to implement and some things I think are simple to implement are in fact extremely hard to implement. So, I don't mind the criticism, Cupro, but I still intend to fire off more possibles that may or may not get implemented, till Tynan tells me to stop.
Something I might see as complicated to implement, Tynan might see it as simple to implement and some things I think are simple to implement are in fact extremely hard to implement. So, I don't mind the criticism, Cupro, but I still intend to fire off more possibles that may or may not get implemented, till Tynan tells me to stop.
15
Mods / Re: What would make the game easier to mod?
« on: June 15, 2016, 07:50:27 PM »
I agree with Cupro, having a special product type definable by modders during animal butchering, or even mechanoid butchering would be very useful. A potential application for human butchering would be able to take out all the still fully functioning organs and reuse them (organ donor style).
I agree with Lupin III, for both 1 and 2. It would be very useful for debugging purposes to know which mod or mods modify which entries in the game. It would also be useful if instead of replacing existing orders, recipes, etc... it would add to the bottom of the list, as long as the old recipes aren't touched in the file... so in C++ terms, have those orders, recipes, etc... "append" to the end of the file, rather than replace the entire contents of the file. That way multiple modders could add recipes without having to make a brand new workbench to have those recipes.
Other simple changes I can think of:
1] I'm not entirely sure if this is currently possible in the current system so mentioning it here. Being able to dictate what kinds of filth are produced by people/animals as a result of performing some kind of activity. Personally, I'd love to see "sticky white stuff" left behind after a couple does their thing. Or "water puddle" after an animal pregnancy. Or angry prisoners flinging "brown stuff" at the walls. That kind of thing to help boost immersion. If that currently isn't possible, could you make it possible.
2] Allow modders to modify behaviours of manhunter animals, and give unique behaviours to different animals when in manhunter mode. As an example, modders could make wargs focus on corpses already on the ground first tearing all flesh from them before moving on, while elephants will try to break down doors to get at the humans inside.
3] Allow modders to modify behaviours of drop pods. Allow modders to decide if they can drop inside a mountain fortress or burst through roofs in general, and other properties of drop pods such as drop pod "movement speed" and other characteristics.
4] Allow modders to modify behaviours of orbital beacons. Allow modders to decide if they can receive resources inside a mountain fortress or burst through roofs in general, and other properties of resource pods such as resource pod "movement speed" and other characteristics.
5] Allow modders to add or remove roofs based on a structure placement. For example, have the equivalent of missile silo blast doors that open up, and thus expose that area to the outside when open and when closed, it is closed. Being able to remove or add ceiling in this manner could make underground fortresses viable for even orbital beacons.
----
Other Suggestions = Probably not simple to implement, but mentioning them anyway.
----
1) Give the player the option of refusing to allow wanderers to join the colony. Its really irritating having a wanderer with cataracts, bad back, non-violent, and can't perform most skills anyway joining the colony. It would be better if we could look at their skills tab, much like when buying slaves or choosing your first 3 colonists and decide if we want them or not. If we don't then they wander in and wander out after a period of time. If we do want them, they stay with the colony.
2) Give the player the option of seeing what this "fleeing" pawn from raiders, what their skills are like. Getting a cataracts, bad back, non-violent, and can't perform most skills anyway to get a raider group as well, makes me usually ignore most requests as I don't want the double risk of bad colonist and bad raid. If we could see their skills before we accept their request, it would make it easier to weigh the risk of letting them join or not.
I agree with Lupin III, for both 1 and 2. It would be very useful for debugging purposes to know which mod or mods modify which entries in the game. It would also be useful if instead of replacing existing orders, recipes, etc... it would add to the bottom of the list, as long as the old recipes aren't touched in the file... so in C++ terms, have those orders, recipes, etc... "append" to the end of the file, rather than replace the entire contents of the file. That way multiple modders could add recipes without having to make a brand new workbench to have those recipes.
Other simple changes I can think of:
1] I'm not entirely sure if this is currently possible in the current system so mentioning it here. Being able to dictate what kinds of filth are produced by people/animals as a result of performing some kind of activity. Personally, I'd love to see "sticky white stuff" left behind after a couple does their thing. Or "water puddle" after an animal pregnancy. Or angry prisoners flinging "brown stuff" at the walls. That kind of thing to help boost immersion. If that currently isn't possible, could you make it possible.
2] Allow modders to modify behaviours of manhunter animals, and give unique behaviours to different animals when in manhunter mode. As an example, modders could make wargs focus on corpses already on the ground first tearing all flesh from them before moving on, while elephants will try to break down doors to get at the humans inside.
3] Allow modders to modify behaviours of drop pods. Allow modders to decide if they can drop inside a mountain fortress or burst through roofs in general, and other properties of drop pods such as drop pod "movement speed" and other characteristics.
4] Allow modders to modify behaviours of orbital beacons. Allow modders to decide if they can receive resources inside a mountain fortress or burst through roofs in general, and other properties of resource pods such as resource pod "movement speed" and other characteristics.
5] Allow modders to add or remove roofs based on a structure placement. For example, have the equivalent of missile silo blast doors that open up, and thus expose that area to the outside when open and when closed, it is closed. Being able to remove or add ceiling in this manner could make underground fortresses viable for even orbital beacons.
----
Other Suggestions = Probably not simple to implement, but mentioning them anyway.
----
1) Give the player the option of refusing to allow wanderers to join the colony. Its really irritating having a wanderer with cataracts, bad back, non-violent, and can't perform most skills anyway joining the colony. It would be better if we could look at their skills tab, much like when buying slaves or choosing your first 3 colonists and decide if we want them or not. If we don't then they wander in and wander out after a period of time. If we do want them, they stay with the colony.
2) Give the player the option of seeing what this "fleeing" pawn from raiders, what their skills are like. Getting a cataracts, bad back, non-violent, and can't perform most skills anyway to get a raider group as well, makes me usually ignore most requests as I don't want the double risk of bad colonist and bad raid. If we could see their skills before we accept their request, it would make it easier to weigh the risk of letting them join or not.