Posted: Thu Sep 01, 2016 8:26 pm Post subject:
YR INI Extension
YR INI Extension is a preprocessor providing new functionality to our INI files which can be compiled to code understandable by the YR engine.
This utility is completely independent from Yuris Revenge and runs on Java 8.
This program is manly tested on Yuris Revenge, but should also work with TS. Ares should not be a problem.
This tool was made out of boredom and I don't except much hype. I was inspired by the SASS extension for CSS.
Here is full feature list:
Imports:
It's now possible to organize your code in a much cleaner way, by splitting a INI file into multiple files.
Somewhere in your INI file:
Code:
@import=soviets/soviet_tanks.ini
The content of soviet_tanks.ini will be pasted at the exact location of the import statement(replacing it).
Nested files may also contain import statements. The file path is relative to the current file.
Variables:
You can declare variables now. Example:
Variables must be accessed with a dollar sign at the beginning. Further more, variables may only be used on values.
Inheritance:
Any techno type can inherit tags from another one, by referencing it by id. The new type can also define it's own tags. For example, if you want the AI to build two extra war factories, you could do something like this:
Code:
[GAWEAPCLONE1]
@extend=GAWEAP
TechLevel=-1 ;Override the parent tag.
[GAWEAPCLONE2]
@extend=GAWEAPCLONE
GAWEAPCLONE and GAWEAPCLONE2 will inherit all tags from GAWEAP. Tags in the derived type will override the tags from the base type.
Math:
You can now use math expressions! This is achieved with the help of the @calc keyword.
Code:
Damage=@calc 10 * 5
Can be combined with variables:
Code:
[Variables]
ten=10
five=5
[SomeWeapon]
Damage=@calc $ten + $five
Math functions such as pow, sqrt, sin, cos etc are also available.
Code:
Damage=@calc Math.sqrt($ten)
Custom Tags:
Custom tags can now be defined. If a custom tag is set to true, it will be replaced by a bunch of other tags. Example:
Multi Line Comments:
Every line starting with a hash sign(#) will be excluded while compiling until an other one is found.
Code:
#
This code will not be compiled
#
Thats all. Dollar and at sign are reserved.
Compiling an original rules file takes about 450 milliseconds. Here is batch file for windows that first compiles a file named dev_rulesmd.ini to rulesmd.ini(in the same directory) and then immediately run Ares:
The former of the two files is the source. The latter is the compiled file. Last edited by Josh Is 25% Larger on Tue Feb 07, 2017 3:28 pm; edited 2 times in total QUICK_EDIT
Interesting, and looks well thought out -- except the purpose eludes me.
Why would you deliberately use shorthand for this compiler of sorts, when you could just write the ini properly the first time? Aside from neatness, the annoyance of having th preprocess the thing each time you make changes, would seem to outweigh any gain? _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
I'm with G-E here and don't see much purpose of it, since it adds work steps instead of reducing them.
If you would implement the other way round however, this could be interesting for future OpenRA conversions. Because OpenRA is using separate yaml files for structures, weapons, infantry etc etc.
If this tool would be able to split up art and rules.ini into a folder and files structure like OpenRA is using, this could help in getting things better organized for a following ini to yaml conversion. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Well, coding properly is what caused me to create this utility; it's inefficient.
Back when I coded YR, I always wanted to organise my code better. For example, have all soviet types in one file, all allied stuff in an other file, etc. And a lot of code copying all the time. And when I changed one thing, I had to search and replace etc.
I am not sure how OpenRA works, but separating art and rules into a folder should work the way you imagine.
To both: There are no additional steps here. If you think about it, when do we want to compile our ini files? Before running the game right? So we create batch file which first compile the INI files and then runs the game. So we no longer double click on our ra2md.exe to run the game, we use the batch file. So no extra steps!
A bit off topic, but am thinking about contributing to OpenRA. QUICK_EDIT
extra steps come already when you have to open multiple ini files (weapons, units, art) in different tabs/editors and then constantly have to switch between them.
If you organize your single rules.ini well, you also find very fast what you're looking for.
ctrl+f in one file just faster than switching to other files and doing a search in these.
It's often a newbie mistake to just slap new ini code in the middle or end of the ini without keeping it well organized. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Why would you want the end user to compile code each run? Normally you distribute compiled code so they don't need any extra stuff. _________________ Free Map Editor - Game Requirements - Stucuk.Net QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Fri Sep 02, 2016 7:02 pm Post subject:
I don't know what's the problem with you guys, but I see a great potential with this tool as, not just a way to better organize your files, but also the possibility of assigning variables that could be used to ballance the gameplay in an easier way, or inherit other units to create variations, etc. This tool should be pretty much fast to compile your ini code, which won't be a problem, supposing that it doesn't corrupt it. QUICK_EDIT
to compensate other values like speed, firepower etc.
So in the end you have to adjust each individual value anyway.
Such a system would only become useful if you put everything in super complex formulas which consider every tiny aspect of an object.
e.g.
$StealthFactor=2.0
$SpeedFactor=0.5
$HeavyArmorFactor=1.5
$BaseStrength=1000
and then calculate a units hitpoints like this
[UnitC]
Cloaking=yes
Armor=heavy
Strength=@calc $BaseStrength / $HeavyArmorFactor / $StealthFactor * $SpeedFactor
with the formula in the end including every single aspect of the unit in certain variables.
So later you only adjust the main variables and all numeric unit properties like Strength, Speed, WeaponDamage, WeaponRange etc depend on such very long and complex formulas.
But finding these formulas would be a super hard job, where it's surely just easier to listen to your gut feeling and simply assign a value you find nice and fitting. Then after some testing ingame you would adjust a bit the value and fine.
Thus i'm really not sure if variables would really make your life easier.
The inherit system is the only major benefit here imo.
This is very cool for those endless repeating sections like the hundreds of civil buildings in TI.
With this you create only one section and then let all civil buildings inherit from this.
If you ever feel the civil buildings need to be stronger/weaker you only have to adjust the base section.
This is really a big time saver! _________________ SHP Artist of Twisted Insurrection: Nod buildings
Exactly, it's like putting on shoes to walk between the kitchen and bathroom, but taking them off before entering. You've added work at both ends for what?
All I see with this is just tool for lazy man developer, if you THINK copying long lines of same is already bad in TS/RA2, then look at C&C Generals ini...
OpenRA benefits more from this approach as it natively support inheriting in its yaml and such 'clever reduce of same code approaches' thus it is better destination for this kinda tools.
All use I can think for this 'tool' is just do the boring sections of mostly same once and never compile it again once those are done.
Plus I would never ship such thing for the end user, asking people to run a bat than exe when they never read instructions is another disaster waiting to happen
Plus should you even consider making end user (non-modder) use such, it might be prone to compiling error which gets help request and that could be harder to track down than a ini you intentionally hand built and checked its ok. QUICK_EDIT
Jeez, this community is rather depressing. The lack of constructive and objective feedback make it sounds like bashing.
The fact that it took LKO three posts before mentioning something good is because he hadn't figured out the potential of this tool yet. So think a bit more and you may get more ideas
Moreover If you think switching between files time to time weights more than having a huge rule file on the scale of badness, then that's your subjective opinion.
Apollo you don't distribute a non-compiled INI file. You would never have to ask the user to click on a bat rather than the exe. You distribute the compiled file, which you put in a mix before zipping the project. Like always. Collaborators are an other story though. QUICK_EDIT
You know I wrote a few scripts that do the reverse of this, they clean the original rules.ini of unnecessary junk, can reorder/renumber lists so they are contiguous and unique, removes comments etc... basically designed to produce something cleaner for distribution. I also have the ai.ini cleaner which will translate the scripts so you can read wtf is going on in words to verify you did things right, along with other housekeeping like moving the lists ahead of sections. Both do a good job at finding errors.
This thing you wrote makes things more complex and introduces potentially all new errors that no one is used to, which means easy to miss. What constructive criticism do you want when the whole project solves a problem that didn't exist? _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
I think this is a great idea. While this creates cleaner "source code" for the legacy engines right now, it also gives us the opportunity for smarter rules when we adjust our currently very primitive INI rules importers so this also helps OpenRA migrations in the future. QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Sep 04, 2016 4:50 pm Post subject:
Disagree, if anything, this just complicates the INI-to-YAML converters. Really, it's better to not even imply supporting the end result of this by OpenRA.
I also disagree with this being useful to OpenRA modders, most of them can't even utilize inheritation properly - this is speaking from experience, some OpenRA mods are worse than what TibEd would do in terms of YAML quality. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Complexity is always bad. Yes. If you are G-E. Complexity can be a good thing.
Anyone with a decent amount of brain power should be able to capitalize on something semi-complicated and benefit from it.
If a tool like this is to complicated for you, then that's your subjective opinion. For example, it's not to complicated for me. Matter fact, this tool would severely improve development speed for me. QUICK_EDIT
IMPORTS!!!! If this had existed 9 years ago, I might have finished PreRA2... Great work! If I get bored this week I might create an organized, split INI file.
You've got some party poopers in this thread. Don't listen to them. This is a great tool, and modders ought to appreciate its ability to make their jobs a lot easier.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum