zizo 0 Posted February 15, 2012 Maybe it will introduce the same bug to them, but only like 1% have those ini fixed, other 99% people still have the original rules.ini and play with it online, that England and France is almost unplayable by people, besides Arda is now Incompatible with 3.03 right? it has it's own World now. Share this post Link to post
AlexB 8 Posted February 15, 2012 Hi all, the next release will fix the country bug. The tags are changed so ROF and Armor are actually understood as "1/ROF" and "1/Armor". It is not exactly like setting the rules.ini values to 0.9 (it is about 0.91) but I think that is closer to the intended modifiers than 1.1 . @loveu8: Thanks! Share this post Link to post
Bullet 0 Posted February 15, 2012 (edited) What do you mean by 1/ROF and 1/Armor?? You just should change the way the game interprets these tags so that they are proportional again like the others like Firepower and Speed, so that they are fixed if they stay Armor=1.1 and ROF=1.1 Firepower is also 1.1 because its always 10% better!! If you change both the values and the way the tags are read then ... This would make it crap and even more complicated because all people would have to change their values although the tags are changed Edited February 15, 2012 by Bullet Share this post Link to post
AlexB 8 Posted February 15, 2012 How can such a simple thing as a multiplicative inverse be so complicated? And for what reason should i change the way the values are used and the values themselves? (Usually, I don't like to use this smiley...) 1/x is the multiplicative inverse, the reciprocal value. Kehrwert. The slash is the "division operator". If ROF is 1.1 (which is WW-wrong because it makes the reload time longer), 1/1.1 ("1/ROF") is about 0.91. Arda converts the value in the background to this and leaves the handling unchanged, thus the reload time is now multiplied by 0.91, which makes the reload time shorter. Now it is a bonus. Analoguous, the Armor: the damage a unit receives is multiplied by 0.91, which makes the armor appear stronger. Bonus. The rules does not have to be changed, and Arda does not include a new version of rules.ini. If the original values are used, the maluses now become bonuses, as they were supposed to be. Btw. BuildTime and Cost are also positively worded, but larger values do not mean better performance. Share this post Link to post
Chad1233 0 Posted February 16, 2012 (edited) Can you tell me how to enable all music for all sides? I cannot find the complete Theme.ini anywhere.... Edit: I replaced ra95.dat with the original 3.03 one and there seems to be a terrible crash when I try to log-in into Westwood online and I mean right before it takes you to the lobby itself. Edited February 16, 2012 by Chad1233 Share this post Link to post
Sonarpulse 1 Posted February 16, 2012 (edited) Yeah, multiplicative inverse is definitely the way to go (especially if there is no easy way to change hitpoints directly). In case anybody is confused, making the game interpret 1.1 as .9 is not correct. 1 - (INI_number- 1) = 2 - INI_number = damage_multiplier This means 1.1→0.9, 1.2→0.8, 1.5→0.5, etc. This is WRONG 1 / INI_number = damage_multiplier This is RIGHT (AlexB's stated method). Edited February 16, 2012 by Sonarpulse Share this post Link to post
Bullet 0 Posted February 16, 2012 (edited) AlexB your solution would mean we have to set very uneven values like 0.91 (and its rather 0,909090909090909090909..... which is 1/1.1) so its very imprecise because 1/ROF would cause periodic numbers. So if we want to set a 10% Bonus for the ROF we have to set it to ROF=0,9090909090909090909 which is not precisely as well as 0.91 is not precisely. And the game can not handle such long values. So that we can use even and short numbers the Armor tag should actually be read as Armor and not as Damage as it is supposed to be!! Now as it is with the bug Armor=1.1 means 110% Damage, so you should make it 110% Armor to fix it and stay by the value 1.1 which means 110% Armor and which is correct and the only correct way. And with this way the actually rules.ini is correct and we do not have to include another rules.ini! This logic also applies for Firepower and Speed! The higher the variable the higher the Firepower and the higher the Speed. The same goes for ROF! Westwood made ROF anitproportional because in the rules.ini system ROF sets the value for the time between the shots. But they forget it here and set it to 1.1 because they thought it is the real ROF. Actually it was meant to be like this from Westwood, which is also the reason, why they set it to 1.1: The higher the value the higher the ROF. This logic also applies to any mathematical variables btw: The higher the variable for length the higher the length. The higher the variable for weight the higher the weight, not the other way around!! See? And yeah AlexB the Cost also uses this logic from Firepower and Speed and not yours with 1/x! It uses x/1 So why you want to use a totally new system like 1/Armor and 1/ROF and not actually real Armor and real ROF? The higher the value for ROF the better the ROF logically With this system it is easy to set any bonuses or handicaps: 1.0 means 100% (no bonus and no handicap) 1.1 means 110% (10% bonus) 1.2 means 120% (20% bonus) and 0.9 means 90% (10% handicap) 0.8 means 80% (20% handicap)! Naturally for Cost 10% more means a handicap because more Cost itself is not a advantage If you want it to be positive just call it Relief instead of Cost and it matches again. See this system do not cause any uneven and too long values And it is the system from Westwood!!! Do you want us to have to set values like 0.909090909090909090909090909? Edited February 16, 2012 by Bullet Share this post Link to post
AlexB 8 Posted February 16, 2012 Hi Chad1233, themes.ini is not included in Arda, it just defaults to the game's original settings. To make all tracks available to all sides, add "ThemeID=1" to [ThemeControl] in rules.ini. ThemeIDs are the filenames for the tracks without the AUD extension. The new theme IDs are WORKMREM, RADIO2RX, RELDFIRE, HELLMREM, CRUSHREM, MUDREMIX and JOURNEY. To make a theme side specific, add ",soviet" or ",allies". Thanks for the note, I'll have to check WOL yet. I couldn't get it to work either. Hi Bullet! 1) "Very impercise" may be true regarding mathematics, but don't forget this is computer science. 2) You gave no reason why somebody should be as pedantic about setting ROF= to a "percise" value. 3) The "only correct way" is not open to me, because I'm not coding something new. I have to work with what exists. 4) The rules.ini does not have to be changed. The values are bent internally to fit the intended purpose. If you want to be pedantic, see below. Do you know in how many locations in the game rounding occurs? And do you know that RA does not even have a way of using a real value of either 0.9 or 1.1? Why should I waste time trying to make something perfect that is ok (as in: not that much worse than the original) already? An example: Red Alert saves decimal values in two bytes, first one holds the number, second holds the decimals. In other words, both bytes together hold "256 times the value". 0.9 * 256 is 230.4, and 230 after rounding. 1.1 * 256 = 281.6, rounded down to 281. In other words, from an infinite set of decimal numbers from 0.0 to 2.0 (both endings included), you can only use 513 without rounding. That's quite a bad ratio, but it is neither limiting the game beyond reason nor important. It is true that the frame of reference is unintuitive for those values (but WW did it, not me) and the values are rounded for a third time, but the errors in the "0.9 <-> 1.1" conversion cases are 3/256, a deviation of about 1.17 percent points (1.3 percent in the worst case). Increased rate means "faster succession" or "more often", larger ROF= value means faster. Consistent. Increased armor means it can take more damage, larger Armor= means incoming damage is reduced, so it can take more of the same. Consistent. What is the problem? The manual says England and France get some bonuses, but they got maluses instead. I fixed it, save for rounding errors. If you use 1.11 and 0.913 respectively, the values will, due to rounding, be exactly the same as the other bonuses. (Besides, for ROF the consequences would be the same if I left reading the values the way it is and changed the way the values were applied. The rounding would happen later, but it would not vanish. Changing Armor your way would have more severe problems.) Share this post Link to post
Sonarpulse 1 Posted February 17, 2012 I am a math stickler too, but the whole design of x86 and C(++) makes rounding errors pretty much inevitable. Huge floating-point numbers in both make rounding errors much less of a practical worry, but do nothing "theoretical" to circumvent the problem. In theory, I guess somebody could create a whole new architecture and language that tries to do things algebraically (think Mathematica/maple vs simple calculator), but besides that, rounding errors will always be with us. If the game reads time/projectile, and damage_coefficient, I am guessing that it uses those values internally. Therefore, even if AlexB reverses more of the "pipeline" these variables go through, there will still have to be a precision-reducing multiplicative inversion somewhere. If you really want precision, maybe AlexB can make two overriding variables, which take the counter-intuitive, actually-used variables in their proper binary form. Share this post Link to post
Chad1233 0 Posted February 17, 2012 By the way while playing a large skirmish game my game would slow down to a crawl every time I build something! I am not sure what is the cause of this slow down when I build something... Did not happen to my 3.03 version of RA1. Share this post Link to post
AlexB 8 Posted February 17, 2012 Hi Sonarpulse, most of the time the precision is not needed at all (if it is, there are libraries out there that can cope with huge numbers and great precision). The common IEEE 32 bit floating point datatype is not able to represent several finite rational numbers, like "0.2". This leads to unintuitive behavior. For example, the C function fmod calculates the remainder of a division. What would the remainder of fmod(2.0, 0.2) be? The answer is, strikingly, 0.2. And floating points are generally slow. RA uses fast integer math in most locations, that is addition, subtraction and multiplication. Division is rarely used, most of the time it is substituted by other bit shifting operations. RA uses 16bit rational numbers, which can take any number from 0 to 255.998 with a maximum error of 1/512 (=0.001953). Close enough for almost everything in the game. Additional tags for this would be of no help. Almost everything is rounded and two tags to fix it would be like putting fancy curtains in a condemned building. Chad1233: Possibly the cameo clock overlay is to blame. I'm not sure yet whether it's the only cause, but it can slow down the game. Maybe I could make it cache the darkened cameo somehow, but this is something to be investigated later. Share this post Link to post
Bullet 0 Posted February 18, 2012 Hi AlexB, my suggestion is only to not change the calculation for the variable, rather change the variable itself from Damage to Armor and the same for ROF of course. But if it is better your way and we do not have to inclucde a new rules.ini and if we can set Armor and ROF to 1.1 for a 10% Bonus and also 1.2 for a 20% Bonus and so on, then everything is okay Share this post Link to post
AlexB 8 Posted February 18, 2012 Hi Bullet, I almost thought I scared you away. I don't see another way to change the ROF. It is a reloading time multiplier, because that is what needs to be changed to fire faster. Converting "Damage * ArmorBonus" to something like "Strength * ArmorBonus" is not possible for many reasons, and I guess it's the same reason WW didn't use that approach. A UnitType has a Strength= value. If a unit has a health of "Strength * ArmorBonus", it would have 110% health. The green health bar would overflow. Mechanics and Service Depots would only restore up to "Strength" health and the unit would not count as damaged if it had a health of not less than Strength=. The engine counts on the fact the unit health is never higher than Strength=. This assumption is made in so many places it would not be possible to fix it reliably. The damage modifier is (afaik) in only one spot, when an object takes damage. Share this post Link to post
Bullet 0 Posted February 18, 2012 I have a Question: How can i configure Buildingfoundations like this with and without the Bib: XXX XXX XXX and XX XX XX How to configure the foundation tags then? And what about the X in the tags? The description is not detailed enough Share this post Link to post
AlexB 8 Posted February 18, 2012 (edited) The foundation feature is quite complex and there is no easy way to define something like this in an INI-style way. X can be a number from 0 to 25. No gaps allowed. 2x3 (add Bib=yes if needed): Foundation=2,3 Foundation.Cell0=0,0 Foundation.Cell1=0,1 Foundation.Cell2=0,2 Foundation.Cell3=1,0 Foundation.Cell4=1,1 Foundation.Cell5=1,2 3x3 (add Bib=yes if needed): Foundation=3,3 Foundation.Cell0=0,0 Foundation.Cell1=0,1 Foundation.Cell2=0,2 Foundation.Cell3=1,0 Foundation.Cell4=1,1 Foundation.Cell5=1,2 Foundation.Cell6=2,0 Foundation.Cell7=2,1 Foundation.Cell8=2,2 The bib makes the building one additional cell "higher". I hope this is what you wanted it, the 2x3 foundation does not exist in the original game, 3x3 is like the Construction Yard. If you included the Bibs already (which would make the building foundation like the barracks or the weapons factory), this code will not do what you want. Edited February 18, 2012 by AlexB Share this post Link to post
KevinLancaster 1 Posted February 19, 2012 Wait, 2x3 foundation didn't exist? Aren't the barracks and power plant 2X3? Anyway, I wanted to ask if it was possible to fix the "shroud bug". I haven't experienced it myself, but I've heard that if "Shroud re-grows" is turned on, if you both are Allied, if you have Gap Generators and if a GPS Satellite is launched, the shroud will re-grow from the Gap Gen and make the Satellite rather pointless. Share this post Link to post
Sonarpulse 1 Posted February 19, 2012 @AlexB, I think we both agree, floating point sucks, and precision, while it makes everybody feel a bit better, is pointless given the rest of the game design. Share this post Link to post
AlexB 8 Posted February 19, 2012 @KevinLancaster: Power Plants and barracks are 2x2 plus bib, which makes it 2x3. I never heard of that kind of bug. Will test. @Sonarpulse: Yes. Actually I think it was a good choice not to use floats in a game. Share this post Link to post
Iran 12 Posted February 19, 2012 It was, back when Red Alert 1 was released people were still running Intel CPU's without a math co-processor builtin. Share this post Link to post
AlexB 8 Posted February 26, 2012 Hi all, more than a week without news. I'm still working on the next release. It will take one or two more days and there won't be many new toys. Until then, here's a new picture. The new feature is not "more UnitTypes", sorry. These are just original units with new Image=, and one tank's weapon is changed to SCUD. But still, there are some new features in this picture. Share this post Link to post
dodgevipergts 0 Posted February 27, 2012 god i can't keep up with all these updates looking forward to next release Share this post Link to post
r34ch 1 Posted February 27, 2012 Sounds dumb but I cannot get this to work with the ISOs. I tried the RA installer on hifi's site but again something similar. What is the best installer to use this with, preferably with the CS + AM missions? Does FullRA+ work with this? Share this post Link to post
PurpleGaga27 39 Posted February 27, 2012 Say, AlexB. The next time you release a new update for RA1, please post the download links in the very first post, because then otherwise people have to search through several pages of this thread just to find a download link in a post. Share this post Link to post
AlexB 8 Posted February 27, 2012 Hi r34ch, you'll need to install the game from english ISOs, then install the 3.03 patch (I recommend Nyerguds' 3.03 patch), then Arda. In the Arda launcher, deactivate the No-CD mode. Because the original installers do not copy all the files to the harddisk, No-CD will not work. I haven't tested with RA+ or any other packages except for the CnCNet ones. If you installed it that way and it still does not work (i.e. the Arda version number does not show below the main menu), can you send syringe.log? @zocom7: For the next release I'll try to squeeze the download link into the first post, if there's enough free space. Share this post Link to post
Sonarpulse 1 Posted February 28, 2012 I think FullRA+ should have the right executable version, but if you have the ISOs, I would just use those plus the 3.03 patch as AlexB suggested. FullRA+ probably contains some hackish fixes outmodded by Arda. Share this post Link to post