Nest eradication
Moderator: Oberlus
Re: Nest eradication
Regarding the ideas about buildings where you need only one to affect all colonies with nests in your empire: As you people correctly pointed out, having to produce a building on the planets with nests doesn't get even close to levels which could be considered micromanagement. Hence no need to resort to buildings with empire wide effects to avoid (non-existing) micromanagement.
(Sidenote: TBH, I think we already have too much of those kind of buildings anyway, I'd rather get rid of those we have instead of adding new ones. Buildings with empire wide effects seem pointless to me, they more or less just add one-time PP cost to the RP costs of the techs to get the effect, compared to techs that give empire wide effects without requiring you to produce some building first. The distinct thing about buildings is that they have a specific location, and therefore should always come with some kind of location dependent effect(s), at the very least only affecting supply connected colonies. Or only the planet/system they are on/in. The location of a building should always matter.)
Anyway, as I already stated earlier, the proposal under discussion here makes sense only as stop-gap solution. A more thorough/detailed/sophisticated solution to make the entire domesticated monsters feature more interesting is preferred, so all your more detailed/complex suggestions here what other solutions/buildings we can come up with are certainly good, but not really the point of the discussion here. We're talking about something very simple and quickly to implement which could alleviate some unnecessary micromanagement.
Personally, I think the most obvious solution for now would be to decouple the Mega Fauna tech from the organic hull line techs. Make it completely separate, so only those who actually want domesticated space monsters will research it, and those who don't but want organic hulls don't need to research it. This way, no need at all to deal with any extra buildings. If you don't want to have to scrap those annoying monsters that pop up every few turns, just don't research the tech. If you want, well, go ahead. Problem solved.
(Sidenote: TBH, I think we already have too much of those kind of buildings anyway, I'd rather get rid of those we have instead of adding new ones. Buildings with empire wide effects seem pointless to me, they more or less just add one-time PP cost to the RP costs of the techs to get the effect, compared to techs that give empire wide effects without requiring you to produce some building first. The distinct thing about buildings is that they have a specific location, and therefore should always come with some kind of location dependent effect(s), at the very least only affecting supply connected colonies. Or only the planet/system they are on/in. The location of a building should always matter.)
Anyway, as I already stated earlier, the proposal under discussion here makes sense only as stop-gap solution. A more thorough/detailed/sophisticated solution to make the entire domesticated monsters feature more interesting is preferred, so all your more detailed/complex suggestions here what other solutions/buildings we can come up with are certainly good, but not really the point of the discussion here. We're talking about something very simple and quickly to implement which could alleviate some unnecessary micromanagement.
Personally, I think the most obvious solution for now would be to decouple the Mega Fauna tech from the organic hull line techs. Make it completely separate, so only those who actually want domesticated space monsters will research it, and those who don't but want organic hulls don't need to research it. This way, no need at all to deal with any extra buildings. If you don't want to have to scrap those annoying monsters that pop up every few turns, just don't research the tech. If you want, well, go ahead. Problem solved.
Re: Nest eradication
I don't think it's necessary to make one commit for each file you changed. It very much depends on how extensive the changes are to implement a certain feature. Something very simple which just changes a few lines in a few files could be done in one commit.Tualha wrote:Only then did I read CONTRIBUTING.md. So I guess I should redo the stringtable commit, at least, adding one change at a time? Or at least one contiguous chunk at a time? One for the tech, one for the building, one for the building effects.
If it gets a more complicated, you probably should split the implementation into several commits, one commit should then comprise a logical step, things which belong together to make a specific part of your implementation work. E.g. the addition of one building: This might encompass the building script itself, the necessary entries in the stringtable for that building, maybe some bits of scripting in other content script that are required to make your building work.
In your case:
That sounds quite fine to me, you might consider adding the stringtable entries to the commit which contains the item they belong to (if you add a building, but not the stringtable entries for that building, you are left with unresolved references). That would be the bare minimum to get something to work and not produce any errors when trying to play a game with it. You could, in theory, split the building+associated icon/stringtable entries and the tech+associated icon/stringtable entries into two commits (the commit with the tech being the second one, as the tech without the building it references/unlocks would produce errors, and keeping icons/stringtable entries with the item they belong to in the same commit for the same reason), but with a change as simple and small as that I don't really see the point....and added my new code, images, and English stringtable entries to it. I used one commit to add four files (tech script, building script, icon for each) and another commit to make all changes to the stringtable.
A commit should contain everything necessary to not break the build (that is, you should be able to build FO with that commit applied without errors, very important if someone needs to go hunting for bugs using git bisect), and to be able to run and play the game without anything being broken. Your additions/changes might render something unfinished/unusable, but shouldn't break the game.
Re: Nest eradication
Mmm, yes, that all sounds very sensible. Thanks. I’ll redo the commits that way.Vezzra wrote:(Assorted good advice on how to structure one’s commits.)
Re: Nest eradication
The PR is up. Hope I did it right … not very experienced with Git, even less so with GitHub. I don’t see a way to set the PR labels — I’m guessing the developers do that, not me.
Re: Nest eradication
Ah, looking at the code, I gather if you own the nested planet but don’t have the tech, monsters never appear? Didn’t realize that. IIRC, in 0.4.5 you would still get wild monsters if you owned the planet; researching DMF was the only way to stop them, converting wild spawns to tame ones. Hence my desire for nest eradication … if I’d realized I could just avoid researching DMF, this thread would not have happenedVezzra wrote:If you don't want to have to scrap those annoying monsters that pop up every few turns, just don't research the tech. If you want, well, go ahead. Problem solved.
Later: yes, confirmed by testing, it does work that way. Ah well. ’Tis still worthwhile for those who want to have organic hulls, at least until Vezzra’s idea of separating those from DMF is implemented. And it’s a start on doing more with monsters.
Re: Nest eradication
The PR looks fine.Tualha wrote:The PR is up. Hope I did it right … not very experienced with Git, even less so with GitHub.
Correct. However, you can suggest labels e.g. by adding them to the title of your issue/PR in square brackets (like this: "[Bug] Game crashes when..."). Or mention such suggestions in the description.I don’t see a way to set the PR labels — I’m guessing the developers do that, not me.
Re: Nest eradication
Provided my idea meets general approval (and while we are at it: any comments on my suggestion, anyone? Good idea, bad idea?). The best course of action is probably to try to reach a general consensus about which of the suggested stop-gap solution we want to use, then someone can implement that and put up a PR. Or, if we decide to go with the Monster Nest Eradicator, just use the PR you already put up.Tualha wrote:Tis still worthwhile for those who want to have organic hulls, at least until Vezzra’s idea of separating those from DMF is implemented.
As this is a quite simple and straightforward decision, comments/opinions appreciated, so we can come to a quick conclusion. I've already given my vote, so lets hear the others...
Re: Nest eradication
At that PP and RP cost I'd never bother to either research or build it, I'd just tolerate scrapping the monsters. As a stopgap it's definitely a good idea but reduce it down a fair amount.
Also worth considering a bombardment weapon, but that'd need a bit more testing/balancing if you can use it on owned planets, the AI invests in monster nests and if you're destroying them easily it'd be wasted points.
Also worth considering a bombardment weapon, but that'd need a bit more testing/balancing if you can use it on owned planets, the AI invests in monster nests and if you're destroying them easily it'd be wasted points.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Nest eradication
Hmm, well. Space monsters and organic-hulled ships do have some things in common; large, space-faring organisms with slots for weapons and other parts. Perhaps both sequences should start with an inexpensive theoretical prereq called “Spaceborne Life” or some such, then branch out into two series, one dealing with organic hulls, the other with space monsters: domesticating them, eradicating their nests, making them more likely to hatch or to grow larger … domesticating krill … feeding other monsters to vacuum dragons to tame them … bioweapons that work against them …
Re: Nest eradication
It can be adjusted, of course. My thought was that with the techs you need before you can research it, and having occupied several nests, you’d probably have RP and PP to spare by the time you wanted it. But maybe that’s just my experience playing against the AI’s; they’re not very challenging. So I tend to end up dominating the galaxy, with all the capacity I could want.MatGB wrote:At that PP and RP cost I'd never bother to either research or build it, I'd just tolerate scrapping the monsters. As a stopgap it's definitely a good idea but reduce it down a fair amount.
Re: Nest eradication
I prefer Vezzra's idea of moving the Mega Fauna tech into a side line tech so that all of the organic hulls are not dependent on it.
Re: Nest eradication
One of the things I've got in mind for the hull line, which I'm planning to go through after I've done the Research and Grwth tech lines, is that the building tech is a prerequisite for any hulls, the building unlocks first and you don't have to get all the hulls for a particular building if you don't want (exact details to be worked on/balanced).
So currently the megafauna tech is the prereq for the organic hull/incubator tech, if we make the incubator tech first, call that 'space life' or similar and let the megafauna tech and the organic hull tech come from it that'd work fine within that plan and solve this problem.
So currently the megafauna tech is the prereq for the organic hull/incubator tech, if we make the incubator tech first, call that 'space life' or similar and let the megafauna tech and the organic hull tech come from it that'd work fine within that plan and solve this problem.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Nest eradication
I'd like to point out, that eradicating nests could do well as an option to hinder enemy empire that uses domesticated mega fauna.
As such, eradicating bombardment option could be a good idea, it should also be research-able outside of organic hull line.
As such, eradicating bombardment option could be a good idea, it should also be research-able outside of organic hull line.
https://github.com/mmoderau
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556
[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. - Randall Munroe, title text to xkcd #556
Re: Nest eradication
@Mat, @em3, I definitely like your ideas, but I want to point out that all these go beyond a mere stop-gap solution, which is what we should focus on right here and now. Everything beyond that should be part of a more thorough design discussion, which should be done in a separate thread.
For a quick stop-gap solution there have been these three options suggested:
For a quick stop-gap solution there have been these three options suggested:
- A building which removes monster nests.
- A building that enables colonies on planets with monster nests breed domesticated monsters.
- Decouple the Mega-Fauna tech from the organic hull line techs.
Re: Nest eradication
Immediate short term, go with 3, it's simplest and easiest, and only requires a few changes to scripts and AI.
Medium term, I think, 2 plus a bombardment thing, but you're right that should be in a design thread alongside other monster based ideas, possibly throwing in Sloth's old work on the monster boosting building I tested once.
Medium term, I think, 2 plus a bombardment thing, but you're right that should be in a design thread alongside other monster based ideas, possibly throwing in Sloth's old work on the monster boosting building I tested once.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.