1. We have added a Gift Upgrades feature that allows you to gift an account upgrade to another member, just in time for the holiday season. You can see the gift option when going to the Account Upgrades screen, or on any user profile screen.
    Dismiss Notice

Master of Orion 2 unofficial patch

Discussion in 'Other Civ-Related Games' started by Rocco.40, Feb 7, 2016.

  1. Rocco.40

    Rocco.40 King

    Joined:
    Mar 2, 2015
    Messages:
    638
    sounds like you're making good progress!
    you can create a language.ini file manually if there is none present, it's content is simply value 0-4, where 0 is for English language.
     
  2. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    I found another problem: you should add a new class for mod_class called "language" so that the language packs can be considered mods on their own, this would clean up the script a bit, making the language packs alternative as well and maybe even remove the need for $LANG$ variables. Then you could just write something nice like "enable french;"
     
  3. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    Hello.

    First, mod classes are arbitrary, you can assign class "language" to any mod.

    Second. I don't see how introducing "French language mod" should work. For example imagine that author of my_mod decided to rename "moleculartronic computer" to "quantum computer". For this to work when french is enabled, author has to provide french translations in all related lbxs and in configs (translate tech name, tech field name, ship system name). Generic "french mod" wouldn't have translations, so just saying "enable french" won't work.

    $LANG$ was introduced in order to allow a mod to load different lbxs depending on current language. I haven't come up with easier way, but I am open to suggestions.
     
    Last edited: Mar 23, 2019
  4. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    Config syntax is described in section Syntax, page 63 of current manual. It's not said there explicitly, but all config statements can be multiline. Because of this all statements have to end with ;. Allowed separators are spaces, tabs and newlines (whitespaces). Config is case-sensitive. Config format has been stable since introduction of mods (almost 2 years now), and there are no plans to change it. But, as Rocco says, it could change still.

    How do you see functionality of your tool, can you describe a usage scenario? I agree config editing is tedious, but I think it can't be helped, we have hundreds of parameters and you can't just place them all on a form.
     
    Last edited: Mar 23, 2019
  5. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    Hi there!
    The author of my_mod would have to edit the language mods too, or my_mod would have to override the names from the currently selected language mod, I don't see the problem in that. Anyway, if "mod_class = language" works then it means the language packs could be turned into mods right now, which is great! But like I said to Rocco, making texts available straight in the script would be a huge improvement, and if that's too hard to achieve then maybe using Lua would be a middle way.

    I'm still working on the program structure now so I can't give you a functional sample, but it's coming out very nicely. It's intended to be used by noobs so that everyone can mod MOO2 as they please, so ease of use it's my main priority.

    Your script has a huge number of keywords and they won't fit into one form, you're right about that, that's why the application will be modular, with a little module for every important thing, for example if you wanna edit the council stuff, you will select "Council" from the menu and only the council keywords will be edited in a very nice and clear way.

    For generic stuff that don't need a specific module there will also be a "Free Edit" module that can edit all keywords in the script (one by one) and have their arguments documented into an XML or something (at first only a few important keywords will be documented), which is a big bonus over editing a mod in Notepad.

    I have experience dealing with large scripts from games like Red Alert 2 (which has a script of like 700Kb :D), so it's not gonna be a problem, dividing work into modules is the key, but using C# to make these things is easy so I'm amazed how you managed to build such a big script system using DOS stuff, you've done a great job!
     
  6. Rocco.40

    Rocco.40 King

    Joined:
    Mar 2, 2015
    Messages:
    638
    perhaps a screenshot to entice us is possible? :)
     
  7. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    I'm not a fan of sharing work in progress, but I'll keep you posted. There will be a release most likely in a month or two and I think it's going to be huge! :D So far it feels like a modding IDE rather than just a simple editor. I just finished up a "hint" system and now every input field can have a comment above, this will especially make table editing very easy. And if there are no comments in some places, the users will be able to add them themselves, so I won't have to do all the work, although I'll probably comment the most important fields myself.
     
  8. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    Btw we could provide config structure in json. For example each parameter has type and value range, list of rows and columns for tables, short description, etc. It mostly can be found in EXAMPLE.CFG but in a form not suitable for automated processing. Let me know if you need it.
     
  9. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    That would be awesome, especially for the value range, this means I could also add data validation, right now I simply allow free edit so users can write whatever they want at their own risk.
     
  10. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    Attached is json describing config for 1.50.14. It's structured as follows:

    { patch_version : <ver>, parameters : [ <par1>, <par2>, ... ] }

    where each par is:

    { name : <par-name>, type : <par-type>, comment : <description-text>, <extra-options>... },

    par-type can be: ratio, string, integer, enum or table. Each has different extra-options:
    • integer: min, max. Denote allowed range, e.g.: {min : 1, max : 3} means 1, 2, or 3.
    • enum: values. Enum is choice between fixed options, list of those options is given in values. E.g. { "name" : "clear_button_shield", "type" : "enum", "values" : ["intact", "update", "clear"] }.
    • ratio: no extras, range of both numerator and denominator as same as for 15 bit integer and denominator can't be zero.
    • string: no extras, any text is allowed as a value.
    • table: rows, columns. Tables are a bit complex, because they can be multidimensional. Good examples for understanding them are: map_generation (1D table, i.e. single-row table), gravity_table (2D table, normal case), ai_race_variant_table (4D, multidimensional). Most common case is 2D.
    Hope this helps. If your tool works out, we will be shipping such json with every release.
     

    Attached Files:

  11. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    Thanks, I'll see what I can do with it. By the way, I just stumbled upon that ai_race_variant_table lol, had to restructure the code a bit, my initial design was only for 2D arrays :D

    Edit: maybe you should change the format for some tables as it is very confusing. For example:

    Code:
    map_generation small_galaxy_width  = 506 400 10 10 0 0;
    map_generation medium_galaxy_width = 759 600 15 15 1 1;
    Here "small_galaxy_width" and "medium_galaxy_width" look like rows, but they are actually columns, and the map_generation table actually has no rows.

    I believe the "tables" are actually trees, with the path (branches) on the left side and the value (leaf) on the right side of the expression, where the leaf is a 1D table (with 1 or more columns). If there is only one "row" then a column must be specified on the left side to complete the path, but this looks very confusing, maybe you should find a better format or at least restructure existing data, the above example should be:

    Code:
    map_generation
      \_ small_galaxy
           \_ width
           \_ height
           \_ star_spacing
           \_ zoom_factor
           \_ max_zoom_count
           \_ zoom_count
    Then you can write

    Code:
    map_generation small_galaxy = 506 400 10 10 0 0;
    or

    Code:
    map_generation small_galaxy width  = 506;
    map_generation small_galaxy height = 400;
    Edit2: Looking through the JSON file, I think the problem is that you have some tables with 0 rows when they should have one, it's not a big issue but it makes scripting kind of counter-intuitive.
     
    Last edited: Apr 4, 2019
  12. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    I applied the JSON and the processing changed dramatically :D Now all fields are generated based on type (textboxes for strings, numeric inputs with min and max set for integers, and combo boxes with fixed options for enums). Here's a screenshot with the results so far:

    tool.jpg

    Just a few things:
    - there is another type called "mask", could you explain it please? Right now I left it as numeric, but it would be nice if I could do more about it.
    - the comments are meant to be written into the EXAMPLE.CFG and as you can see they are not really suitable to be displayed in a program, I would suggest that you add two fields in the JSON file, "comment" for a nice display and something like "example" or "print" for printing to EXAMPLE.CFG. The nice comment should not contain unnecessary informations (like usage examples).
    - a "default" field in the JSON file for every parameter would be great, this would allow for a very handy parameter reset option. The default is now only present in the comments and it's not useful for processing.

    I will probably modify the JSON you gave me myself to get things working, but it would be nice if it could be done "officially". Let me know if my suggestions are useful to you, I don't wanna look bossy here.
     
  13. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    I forgot to mention masks in my post. It IS numeric, the only difference is that masks are printed out in binary when config is extracted to EXTRACT.CFG. Type mask is used where 16 bit integer is meant to represent a set of flags.

    For example each weapon has available mods mask. Each allowed mod corresponds to 1 set bit in it. It would be unnatural to represent and edit such mask as integer.

    In context of your program I'd limit editing such fields to strings of ones and zeros. It would be nicer still, if a user could see meanings of each flag, e.g. edit it as a set of labeled checkboxes. Sadly, we don't store such information in source code, so can't provide it in json.

    Edit: actually we can add such information in json. If you feel like making specialized bit field editor, then I'll provide flag names.

    First, if you mean usage examples at the bottom of each comment, then you could just filter out lines not starting with #.

    Second, as you correctly noted, comments were meant to be printed to EXAMPLE.CFG. I gave it to you for lack of better per-parameter documentation, that I can quickly generate. We can easily add alternative field, say "help", so you could take it when present, and use comment otherwise. Give me few examples of what you'd want see in help vs what you've got in comment now, and I'll make them appear in json, and think of a more general solution.

    I thought of adding default, but couldn't do it right away. The problem is, that defaults in our source are written in C language format, which I can't easily analyze in perl. Consider source for stock_race table:

    Code:
    add_config_key(
        name    => "stock_race",
        var     => "conf_stock_race",
        default => "{
            { .defense = 3, .arti_world = 1, .government = 2 },                                     // Alkari
            { .attack = 2, .ground = 2, .highg_world = 1, .government = 2 },                        // Bulrathi
            { .spying = 3, .stealthy_ships = 1, .government = 2 },                                  // Darloks
            { .defense = 2, .attack = 2, .telepathic = 1, .omniscient = 1 },                        // Elerians
            { .money = 3, .lowg_world = 1, .fantastic_traders = 1, .lucky = 1, .government = 2 },   // Gnolams
            { .charismatic = 1, .government = 4 },                                                  // Humans
            { .farming = 2, .industry = 2, .large_hw = 1, .uncreative = 1, .government = 6 },       // Klackons
            { .industry = 3, .cybernetic = 1, .government = 2 },                                    // Meklars
            { .attack = 3, .hw_richness = 1, .warlord = 1, .government = 2 },                       // Mrrshan
            { .science = 3, .lowg_world = 1, .large_hw = 1, .creative = 1, .government = 2 },       // Psilons
            { .growth = 3, .farming = 2, .spying = 1, .subterranean = 1, .large_hw = 1 },           // Sakkra
            { .growth = 1, .lithovore = 1, .repulsive = 1, .tolerant = 1, .government = 2 },        // Silicoids
            { .aquatic = 1, .trans_dimensional = 1, .government = 2 },                              // Trilarians
        }",
        levels  => [ "vtype_race", "vtype_stock_races_row" ],
        group   => "GROUP_PREGAME",
        comment => "
    ##
    # Stock races.
    # __NAME() <pick> = <value>;
    #
    # Where pick is one of:
    # __LEVEL(0)
    __NAME() Humans government = democracy;
    __NAME() Alkari growth = 0;     # no growth pick
    __NAME() Silicoids growth = 1;  # negative growth pick
    __NAME() Sakkra growth = 3;     # max growth pick
    ",
    );
    
    Here "default" is a string, which gets inserted in a C code later. To parse it for me is no easier than for you to parse example entry. For simple cases, where default is a single value, i can extract it, but table case is much more common and important imo.

    Edit: Actually I could extract defaults from compiler-generated binary, so that in effect compiler parses it for me. Not sure how easy it is, will give it a go.

    That json was meant as a first iteration. Go ahead and modify it'll let me understand your suggestions better. I'll tell you when change is too much work for me or makes no sense, bossy outlook won't change it, don't worry.

    Regarding your earlier comments on tables, I'll comment later. Basically it boils down to keeping parser as simple as possible and avoiding superfluous code. Yes, some things can look counter intuitive, but our bet is that a person smart enough to create full mod can cope with it.
     
    Last edited: Apr 6, 2019
  14. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    Yes, making a nice dialog where you can check every flag by name would be certainly better than 0s and 1s, so if you can tell me about those flags the input will look very cool :) Are all masks the same or are there different sets of flags for each stuff?

    I thought about processing those comments, like removing # and such, but it will still look kinda bad... I'll see what I can do.

    Having defaults would be very nice, but it's not vital, if it's too hard then we can forget about them. I thought it will be easy for you to include them since they are constant values. Maybe instead of defaults I could just take the initial value as a default, it's not the same thing, but it can help if the user wants to undo some changes.
     
  15. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    there are different mask fields and each should have own type, current mask type is a crude hack. Json should be providing additional info for each mask field, like for enumerations, like this:

    Code:
    {
      "name" : "natural_mods"
      "type" : "mask",
      "values": {
        "enveloping" : 2,
        "no_range_dissipation" : 4,
        "breaks_systems" : 8,
        "kills_marines" : 16,
        "extra_structure_damage" : 32,
      }
    }
    
     
  16. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    Well if you can detail these flags then I can hardcode them into some dialogs, I suppose they come directly from MOO2 so they will never change, if that's true there is no point in adding them to JSON, but if you add them they will be easy to read and you can also deploy them in your EXAMPLE.CFG for manual modding, whatever you think is best.
     
  17. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    They come from moo2, but we once added a flag and might do it again. Also we plan to add leader modding in config, and leaders have their own flags. So I'd suggest to use json over hardcoding.

    Attached is json file, and corresponding ORION150.EXE, which support masks in config.

    1. Json has new type "mask":
    Code:
    {
       "name" : "available_mods",
       "type" : "mask",
       "flags" : <flags>
    }
    
    where <flags> is an array:
    Code:
    [
       {
          "code" : "hv",
          "value" : 2,
          "desc" : "heavy mount",
       },
       {
          "code" : "ap",
          "value" : 8,
          "desc" : "armor piercing",
       },
       ...
    ]
    
    Code is what is given in config. E.g.:

    hv
    hv,ap
    none

    Sum of all values gives mask value. So if mods are given as "hv,ap", then value is 10. Numeric notation is supported, so 10 can be specified instead "hv,ap". Special code "none" is given when no flags are present. See EXTRACT.CFG for examples.

    2. exe is identical to 1.50.14 in all respects except masks support. You can use it to test edited configs load.

    3. There are just two mask types for now, corresponding to weapon "natural mods" and ordinary mods. "Natural mods" denotes traits inherent to weapon, say neutron blaster kills marines, so it will have natural mod flag "mar". Ordinary mods are mods that can be set in design screen: pd, hv, mirv, etc.
     

    Attached Files:

  18. Ponkyo

    Ponkyo Chieftain

    Joined:
    Mar 18, 2019
    Messages:
    53
    Gender:
    Male
    Awesome thanks, I'll work on it. Meanwhile, to complete the mod management (create, load, save, edit) I had to also add a fully functional launcher module, which will probably replace your launcher, I hope you don't mind about that.
     
  19. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    I don't mind, but since you're using C# I expect problems with Linux and Mac OS X. We'll consider partial replacement anyway.
     
    Last edited: Apr 12, 2019
  20. Alex/150

    Alex/150 Chieftain

    Joined:
    Mar 20, 2017
    Messages:
    41
    Gender:
    Male
    Attached is new json, which has few glitches corrected and includes defaults for all parameters.
     

    Attached Files:

Share This Page