Nevermind, not worth it.

Well, its not about particularly you being worth or not worth it, as its an overall useful info anyway.

If you unload troops on one of your planets, then try to unload troops in the same system immediately afterwards, you'll get a message that reads "Option disabled during multi-player games" (even if you're in single-player mode).

Sigh, again. I shouldn't rise to the bait, which is why I deleted my last reply. But I find it so amusing you think you're being helpful.

I refer you to a standard part of manuals, the Table of Contents, where a user with a problem is intended to go. What would they look for? Build queue management ... here it is, pages 9 & 10. Swell. Nowhere in the section on build queue management does it mention where build.cfg is located, nor that it could be in a non-standard location. The user, opening their MOO2 directory, sees build.cfg right there, plain as day. They have zero reason to expect that there is something hidden elsewhere they should actually be doing, as they follow the instructions in the Build Queue section correctly and trustingly.

Of course build.cfg shows up in the search function, in a section on modding, and changing other configuration files. The user doesn't necessarily consider changing a config value "modding", doesn't want to change that other configuration file, and in fact has no reason to do so. It's just that hidden inside that configuration file is the information on where the actually-used build.cfg is located. This is not intuitive, and an oversight in the manual. It is a very reasonable and predictable user error for this to be overlooked, and a small error in manual design to skip this. And I'm not slamming the manual which is overall very good, very useful, and made out of the goodness of someone's heart. But in fact this is not well-handled by the manual, and that's an understandable oversight.

One can give people the benefit of the doubt. I know, you would rather patrol the forum and gripe about others wasting your precious time - as if you didn't seem to have more than enough - instead of accidentally helping someone who isn't worthy. Yes, arguing is more satisfying than trying to help. But I feel like I do remember you being very helpful, once upon a time.

I'm done arguing, but feel free to mock some more. That way you win, I guess?

Sorry, i had no chance to know if that message of your been longer initially. In its short form it looked weird tbh.

I fully agree with you here, real help would be rewrite this part of manual more clear way. Its indeed written very obscure and puzzling way, if you bother my opinion. Just i personally really cant be too much critical to the Manual. Well, the way devs runs a project now, with them merely become a bitches to a VDC; badly written manual is just a peanuts. Yet the all the info about stuff mentioned is there. If you just checked the manual prior providing wrong info hidden behind "I believe", and instead wrote something like "...there is manual with solution, but i think you will not manage though it, so my advice is..." (tho it, in turn, will be pretty offensive to the user asking), ofc i wouldnt comment it then.

Problem is that you pretty much missed the whole point with that searching for Build lists management in the Manual. Say, most easy way to manage them is via Launcher, as it, well, know where they are located. But, inability of find a needed Build.cfg its not a problem, described by user. Its only your own guess about it, not confirmed at all. Yet you spent all the time defending his right to not been able to get it (you understand what its about first ever complain about Build list location ever, and that feature is, err, quite some years old? if it so unbearable explained, how all the other users manage to, err, use them?). The way user wrote about his problem, he even didnt seemd to know about a need to press a button to apply the changes. Or could had some broken installation. Or that build list changes by him shouldnt create any change in the game state he was. Or he could editing the wrong Build.cfg in wrong location, and so on. We cannot know without asking. And he started to lie at a "did you read manual" step already (i still did more than one try, despite it).

But the really silly thing that shine there was idea of providing incomplete list of actions performed and then ask "is there anything else I need to do to make the changes actually work?" Yes. Everything that wasnt included to that list. For example reading of the manual, as after doing so, user cannot anymore ask "is there anything else i need to do?", as it would been obviously not, already, assuming user did the stuff described there. The question could be "i did the stuff as it written there, but it doesnt work still; either manual is wrong, or i went some unusual circumstances about it". But it already cannot be "what else to do" after that. As his incomplete list even didnt included reading manual as performed, the answer to cover all the possible issues is obviously RTFM. As the way it was written he didnt even pressed any Q while awaiting for the changes to come.

And ofc, it turned what steps the incomplete list is lacks are not necessary not performed, some of them just skipped from mention, so ones, willing to help supposedly should just name skipped steps one-by-one and waiting for confirmation if this certain step is indeed wasnt performed or user just decided to not mention it. Its a pure waste of forum space, and actually it would be simply a good thing, if such users felt bored fast and gone for good to some other place. And in case user is able to perform the needed work (being pointed to) on his own capacities - it will make it even more win-win scenario. Thats about winning in this context. Being helpful is a collective work usually.

Good catch as usual, man: Simtex messed a messages, and if player trying to unload troops onto own planet, but have no Transport ship selected in that fleet, warning message erroneously set as (unrelated) "Option disabled during multi-player games" instead of correct "No transport ships selected". Its an easy one-byte fix. "Immediately afterwards" here simply caused by losing a selection as an aftereffect of a previous unloading; its not required on its own, any such attempt without Transport selected would result in wrong message.

No Darza, the thing that really shines here is that you are rambling about possibilities, 3 weeks after the issue of Qiaosi, or "the user" as you insist in calling him, has been solved. BTW, I spent about 40 words helping "the user" solve the issue, while you have been derailing this thread with paragraph after paragraph with stuff off-topic to the 1.50 patch. legraf is right, you used to be very helpful, once upon a time.

You left the 1.50 project in early 2018 without much explanation, after having worked together for a good 3 years. After that you blocked me on Hangouts and IRC. If you have some gripes, then I suggest you man up, unblock me and have actual conversation instead of bitching about us on this forum to "users" that you don't even know.

I may have missed something, but is there a way to add population to asteroid belts and gas giants with moo2mod via a cfg change?

(As a note I'm on "1.50.15 (July 21, 2019)" because I ran into problems when using corion2 1.1.1 on later versions)

The way I have my game setup is no planet building, terraforming, etc, techs and just wondered if it was something that was possible currently I missed. Currently, I just change asteroids & GGs to tiny planets but that makes for a strange looking aesthetic.

You cannot really add population and so on via a cfg change of moo2mod, as its a website, it will not affect your game directly, even if you will be able to change its (website's) configuration.
Assuming you actually about 1.50 patch, you can prevent appearing of asteroid belts and gas giants during map generation process, by setting desired values in cfg. Also you can change them (already generated asteroid belts and gas giants) into planets via scripting or save editor (strictly speaking its not a cfg change already). Adding population to asteroid belts and gas giants is pretty useless on its own, as game will not properly operate that population anyway, so its not directly possible by cfg (while still possible other ways, without some exciting result from tho).

So all that hassle is merely to change a grafix for tinies and huges? Dont forget also that 42 max pop is really max pop for a planet (so it will not act weird with technology added later).

Playing MOO2-1.50.18.3 with core set to 1.50 improved + picks and am surprised about the performance of missiles. Having a ship fire a bunch of missiles and retreat has always been a valid tactic I used in ice. But in the current game, missiles vanish, when the ship that fired them retreats. Is this new? Is this intended?

Amazing coincidence, as i just literally currently working on some possible solution to mentioned problem, thats looks like one of the most major design flaws of this game, causing huge part of its problems. In bout free retreats ofc here, will write more detailed bout them later, with ready-to-test version at hand.

Is there a way to get an older version of 1.50? I mean, missiles used to work.

Yes, but im not sure bout any older. I surely have the latest "official" one, tho later test versions should hаve fixed few couples more of bugs there and there.