Whoa....time out folks - My proposal
igmo, to remove the randoms:
1. Open Fear.
2. Open the bowman in monster tags.
3. Double click on "bowman arrow". in the big white attacks window in the lower left.
4. Change the initial velocity range so that both values are the same - .250 for example.
5. Change the initial velocity error setting to 0.000 from 0.008.
6. Hit okay.
7. Hit okay.
Now, to speed up your tests without a script:
1. Open the mesh tag you're using in Fear.
2. In the lower left, check "Is Single Player Map".
3. Hit okay and Close Fear.
4. Open your mesh in Loathing and make sure the target units you're using are on Team 1.
5. Save and have at it.
Let me know if that does it.
1. Open Fear.
2. Open the bowman in monster tags.
3. Double click on "bowman arrow". in the big white attacks window in the lower left.
4. Change the initial velocity range so that both values are the same - .250 for example.
5. Change the initial velocity error setting to 0.000 from 0.008.
6. Hit okay.
7. Hit okay.
Now, to speed up your tests without a script:
1. Open the mesh tag you're using in Fear.
2. In the lower left, check "Is Single Player Map".
3. Hit okay and Close Fear.
4. Open your mesh in Loathing and make sure the target units you're using are on Team 1.
5. Save and have at it.
Let me know if that does it.
thks chris
i did actually figure out the de-randomizing thing (all by myself -- look at me ma!)
i made a new map with the unrandom units (arch, soul, dorf and mort). then i ran them through v1.3 and 1.5. you are correct - they have the same range when random is set to the middle value. i've marked the colormap to have the up, level, and down "base" ranges (red, yellow and green dots respectively)
that map is available at: http://home.austin.rr.com/aoffice/rangeTest_v2.zip
if anyone is interested. the unrandom units are available only on legendary.
good suggestion on making the map solo - i'd just need to spread out the units more so they don't kill eachother. (or just limit the availability of the lock and fetch - which seem unnaffected by this perceived range difference)
i did actually figure out the de-randomizing thing (all by myself -- look at me ma!)
i made a new map with the unrandom units (arch, soul, dorf and mort). then i ran them through v1.3 and 1.5. you are correct - they have the same range when random is set to the middle value. i've marked the colormap to have the up, level, and down "base" ranges (red, yellow and green dots respectively)
that map is available at: http://home.austin.rr.com/aoffice/rangeTest_v2.zip
if anyone is interested. the unrandom units are available only on legendary.
good suggestion on making the map solo - i'd just need to spread out the units more so they don't kill eachother. (or just limit the availability of the lock and fetch - which seem unnaffected by this perceived range difference)
well i cant seem to get the map as solo thing to work.
i made the changes you noted, as well as unclicking the body count option in fear.
in the multiplayer setup, the map did not show in the list after clicking "use s.p. levels" (and wont show in the m.p. list since it has no gametypes.) i thought it was off the s.p. list since it had no description string... so i added one, but not change.
cant see the map to get that auto attack rolling.
on a different issue - the arch and soul ranges and modifiers are the same in their unit tags. what makes the soul range so much shorter? javalin weight?
i made the changes you noted, as well as unclicking the body count option in fear.
in the multiplayer setup, the map did not show in the list after clicking "use s.p. levels" (and wont show in the m.p. list since it has no gametypes.) i thought it was off the s.p. list since it had no description string... so i added one, but not change.
cant see the map to get that auto attack rolling.
on a different issue - the arch and soul ranges and modifiers are the same in their unit tags. what makes the soul range so much shorter? javalin weight?
Hey igmo, I don't have Fear or Myth handy where I am right now, but I'll try to answer your questions.
To see your test map, you need to hold shift down when hitting whatever button it is that brings you that selection screen.
As for the Soulless range, I'd have to look at the tags. Gravity does play a part in range, but I'm almost certain both the bowman arrow and soulless spear use a standard setting of -.004 (found in the respective object tags designated in the arrow and javalin projectile tags).
If the maximum range setting is the same (20?), then my guess is that it has to be in the initial velocity settings. Are you sure the javalin attack is set at 0.240 to 0.260, just like the bowman arrow? If either of the two values are lower, that would certainly shorten the range a bit.
To see your test map, you need to hold shift down when hitting whatever button it is that brings you that selection screen.
As for the Soulless range, I'd have to look at the tags. Gravity does play a part in range, but I'm almost certain both the bowman arrow and soulless spear use a standard setting of -.004 (found in the respective object tags designated in the arrow and javalin projectile tags).
If the maximum range setting is the same (20?), then my guess is that it has to be in the initial velocity settings. Are you sure the javalin attack is set at 0.240 to 0.260, just like the bowman arrow? If either of the two values are lower, that would certainly shorten the range a bit.
that is likely the case. since the numbers i used were fixed and that lead to the same result - then everything the numbers multiply with (physics mostly i guess) must be the same. that would leave some sort of bias in the random generator as a culprit for any range variation.ChrisP wrote:Cool. So are we at the point where the only question now is has the random generation been modified in some way by 1.5?
the only other possiblility is that the initial velocity error is handled differently. that was put to zero, so we cannot be sure it runs through physics the same.
i should point out that the archer seemed to have mb some _tiny_ variation. small enough that the random selection of handedness and stance made it hard to be sure (it is a very assymetric unit.)
btw i gave up on the solo level idea. the units need to basically be in range to be motivated to attack - which is no good for this test. they wont walk up to a stationary target. short of making a new target unit that had a very long range, large, nearly painless attack that would inspire counter attack, then scripting that attack, then scripting the units to stop after their first attack.... well, u get my point.
Hey igmo, to respond to your points:
Without the benefit to look the tags over in Fear, I'm mystified by the Soulless. I always thought the spears traveled slower than arrows (by my perception at least). I will investigate and let you know what I discover.
Combined power is the setting which dictates how enticing a target the unit is when the AI has to choose between enemies to attack. I think this mostly comes into play in solo games when the AI is scripted to attack the entire player's force. At any rate, it should have no bearing on range whatsoever.
If the way initial velocity error works was altered I think we'd see far more drastic results than small range fluctuations. This setting controls how accurate attacks are, and so far I don't think there have been any reports of missile units hitting or missing more often.
As for the solo idea, there may be a way to fix the issue you described in tags rather than having to script anything. I could look into it if you're still motivated to give it a try.
And thanks for your calm, logical and persistent approach to this. If you ever want a job as one of Project Magma's internal beta testers....
Without the benefit to look the tags over in Fear, I'm mystified by the Soulless. I always thought the spears traveled slower than arrows (by my perception at least). I will investigate and let you know what I discover.
Combined power is the setting which dictates how enticing a target the unit is when the AI has to choose between enemies to attack. I think this mostly comes into play in solo games when the AI is scripted to attack the entire player's force. At any rate, it should have no bearing on range whatsoever.
If the way initial velocity error works was altered I think we'd see far more drastic results than small range fluctuations. This setting controls how accurate attacks are, and so far I don't think there have been any reports of missile units hitting or missing more often.
As for the solo idea, there may be a way to fix the issue you described in tags rather than having to script anything. I could look into it if you're still motivated to give it a try.
And thanks for your calm, logical and persistent approach to this. If you ever want a job as one of Project Magma's internal beta testers....
well, if the tag solution to solo play would be really easy to work out, it would be useful. i will likely run any tests in solo mode, as it is quicker to to esc/restart level than to cancel a net game and click thru to restart... having the units automatically attack would be a minor convinience over zooming out, selecting all, and clicking target.
looking at the souless/archer deal again... the attack values are the same for range, but the unit "longest range" values are different. 26 for arch, 20 for soul. that must come into play, although both shoot shorter than that in all tests.
as for saddling up with project magma... does that mean everyone will start yelling at me?
looking at the souless/archer deal again... the attack values are the same for range, but the unit "longest range" values are different. 26 for arch, 20 for soul. that must come into play, although both shoot shorter than that in all tests.
as for saddling up with project magma... does that mean everyone will start yelling at me?
igmo wrote:as for saddling up with project magma... does that mean everyone will start yelling at me?
That's the whole point of inviting you; we'd just refer people to igmo, "the guy with all the tests".
If the "longest range" setting is coming in to play, it occurs to me that I don't know exactly what or how you're testing. I really should dl your map and films; perhaps right after I register for the PoOp board.
Far as I understand it, here's how "longest range" works: the bowman, for example, has an attack range of 20 (and this is in Myth world units, btw, which is different from the datum you basically invented) but has a longest range setting of 26. If an enemy is in between 20 and 26 (on level ground), it is out of range for the bowman and he won't try to fire an arrow. HOWEVER, if you click and tell the bowman to attack that enemy that is between 20 and 26 range AND that enemy is moving towards the bowman (probably even just facing the bowman, but I'm not sure) the bowman will just stand there and wait for the enemy to come into range - as opposed to moving up to get within range.
In the same case with the soulless, which has both a real range and longest range of 20, the soulless won't waste any time waiting for the enemy to move up. It will instead move forward till it is within range and then fire.
What impact this has on your tests, I can't be sure without watching what you were doing. But it sure does get complicated, don't it? But hey, at least you're learning a little something about why certain Myth units behave the way they do.
Looking in Fear, I can't see any other reason why soulless would have a shorter range in your tests, but then again, I'm not really that great a Fear expert. Maybe Iron or SiliconDream could shed more light.
Edited By ChrisP on 1082954258
Ok - I've posted the results of my two "double dud" tests - one for 1.4.3 and one for 1.5 Beta 1 - you can find them both at the following links (I made them so you can toggle the browser windows between them to compare more easily):
Double Dud Test Results - Myth II 1.4.3
Double Dud Test Results - Myth II 1.5 Beta 1
I was amazed that the second test had exactly the same number of throws! 156 in each! Also, the unit was set up to just keep tossing automatically - so the shots are extremely "regular" (i.e. perfect intervals) - sweet!
I'm no expert with stats, but you can clearly see from this test that the 1.5b1 results show a lot of "bunching" - no idea if this is statistically significant.
Woden: My understanding (from observation only) is that the rebound (bounce) is the first thing that is checked. This is the "detonation" section of the projectile and there is a number for "normal frequency" which means how often it detonates (I believe). If you are outside this range (0.833 is the example so 0.167 is outside) then it "rebounds".
I believe that once it finally detonates (after zero to n rebounds), *then* it checks for whether it duds - in this case the "dud" is just the way the "promotes on detonation" projectile is set up. It could turn into a chicken for some other projectile.
To summarize: I believe at first it is just checking to see if it detonates - if not, it rebounds until detonation. Then it checks to see if it "promotes" (in this case the promotion is a dud).
[Anyone who knows this in detail: feel free to correct me]
With that in mind, it does appear that a rapid series of rebounds occurs fairly often - and actually I like this and perhaps it is part of the game. What I do notice in this test, however, is that it happened a lot in 1.5b1 for some reason. This could just be the test, but it is 156 samples for each. No idea if 156 is "statistically sufficient".
The funniest thing to me is that the main reason I wanted to run this test is because we seem to see a lot of "double duds" when playing, and there were zero of them in both tests! BUT, when playing you are constantly alternating shots with the other players - many more in the same period of time - so perhaps what is happening is that from a single player's perspective they are hitting the pattern of duds/rebounds that are alternating with other players' hits.
:: Brain takes a recess ::
Ok - back.
Hope these tests were useful and/or interesting.
Seeya!
Double Dud Test Results - Myth II 1.4.3
Double Dud Test Results - Myth II 1.5 Beta 1
I was amazed that the second test had exactly the same number of throws! 156 in each! Also, the unit was set up to just keep tossing automatically - so the shots are extremely "regular" (i.e. perfect intervals) - sweet!
I'm no expert with stats, but you can clearly see from this test that the 1.5b1 results show a lot of "bunching" - no idea if this is statistically significant.
Woden: My understanding (from observation only) is that the rebound (bounce) is the first thing that is checked. This is the "detonation" section of the projectile and there is a number for "normal frequency" which means how often it detonates (I believe). If you are outside this range (0.833 is the example so 0.167 is outside) then it "rebounds".
I believe that once it finally detonates (after zero to n rebounds), *then* it checks for whether it duds - in this case the "dud" is just the way the "promotes on detonation" projectile is set up. It could turn into a chicken for some other projectile.
To summarize: I believe at first it is just checking to see if it detonates - if not, it rebounds until detonation. Then it checks to see if it "promotes" (in this case the promotion is a dud).
[Anyone who knows this in detail: feel free to correct me]
With that in mind, it does appear that a rapid series of rebounds occurs fairly often - and actually I like this and perhaps it is part of the game. What I do notice in this test, however, is that it happened a lot in 1.5b1 for some reason. This could just be the test, but it is 156 samples for each. No idea if 156 is "statistically sufficient".
The funniest thing to me is that the main reason I wanted to run this test is because we seem to see a lot of "double duds" when playing, and there were zero of them in both tests! BUT, when playing you are constantly alternating shots with the other players - many more in the same period of time - so perhaps what is happening is that from a single player's perspective they are hitting the pattern of duds/rebounds that are alternating with other players' hits.
:: Brain takes a recess ::
Ok - back.
Hope these tests were useful and/or interesting.
Seeya!
- iron
- Site Admin
- Posts: 2006
- Joined: Thu Feb 26, 2004 1:21 am
- Location: diving out of the Sun at 10 o'clock high!
- Contact:
It really all comes down to the random number generation. Here is the relevant snippet of code from Myth 2. You'll note that it is from Numerical Recipes in C, a well-known source of high quality algorithms. This code is identical in TFL, Myth 2 and Myth 3...
static unsigned long random_seed= 0L;
// Our linear congruential random number generator is of the form
// x(n+1)= ((a * x(n)) + c) mod m
// We're using m= 2^32. If we multiply 2 32-bit numbers together, the result is the low 32
// bits of the 64-bit product. Thus, we get the "mod m" for free. Our choices for A and C,
// which are EXTREMELY important, come from Knuth.
//
// For more info, check out Numerical Recipes in C, pg. 284.
#define RANDOM_A (1664525L)
#define RANDOM_C (1013904223L)
word random(void)
{
random_seed= RANDOM_A*random_seed + RANDOM_C;
return (random_seed>>16);
}
If there's clumping there's clumping. When you throw a dice there's no law saying that just because you rolled a 6 last time you're less likely to roll another straight away. Its the same story here. By all means though keep testing - I'd be interested to see how that test runs in 1.3.
static unsigned long random_seed= 0L;
// Our linear congruential random number generator is of the form
// x(n+1)= ((a * x(n)) + c) mod m
// We're using m= 2^32. If we multiply 2 32-bit numbers together, the result is the low 32
// bits of the 64-bit product. Thus, we get the "mod m" for free. Our choices for A and C,
// which are EXTREMELY important, come from Knuth.
//
// For more info, check out Numerical Recipes in C, pg. 284.
#define RANDOM_A (1664525L)
#define RANDOM_C (1013904223L)
word random(void)
{
random_seed= RANDOM_A*random_seed + RANDOM_C;
return (random_seed>>16);
}
If there's clumping there's clumping. When you throw a dice there's no law saying that just because you rolled a 6 last time you're less likely to roll another straight away. Its the same story here. By all means though keep testing - I'd be interested to see how that test runs in 1.3.
Yes please add igmo to the private testers group.
igmo-> no one will know your a private tester unless you tell them. The private beta test group just means that you will have access to all the internal builds we make & publish internally and can give us feed back on issues before we release this thing to the world.
igmo-> no one will know your a private tester unless you tell them. The private beta test group just means that you will have access to all the internal builds we make & publish internally and can give us feed back on issues before we release this thing to the world.
ChrisP wrote:I really should dl your map and films; perhaps right after I register for the PoOp board.
....
this is in Myth world units, btw, which is different from the datum you basically invented.
um, yeah, it would be good to dl the sample of what you are discussing. to reiterate, there is a target out of range of all units. i select the units, click the target, and note the distance at which they first stop and shoot (based on the graphic of the color map.)
now as for my units not being mwu, that could certainly be the case. my assumption was that a 1-unit separated line (as made in formations) was a 1 mwu separation. i made my graphic fit that. it translated to 8 pixels on my 512x512 map, which was built on whatever default scaling fear/loathing use.
[edit] i poked around a bit on some myth map sites, and a very confident that 8 pixels on the color map = 1 mwu. which means my units would be mwu. i'd still appreciate confirmation from a "real" mapmaker [/edit]
anyone know what number of pixels would correctly translate to 1 mwu in my case? the results would be less confusing if my units were mwu.
iron, thks for the code bits on randoms.
i like all the input, but mb we need to take a pause and wait for 1.5b2 and the larger sample i'll make (perhaps with help of woden and others to make it even bigger.)
i suppose if i were to be a private beta tester, i could get at the current build now... but mb waiting til everthing is perceived as fixed is better.
i like all the input, but mb we need to take a pause and wait for 1.5b2 and the larger sample i'll make (perhaps with help of woden and others to make it even bigger.)
i suppose if i were to be a private beta tester, i could get at the current build now... but mb waiting til everthing is perceived as fixed is better.