This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Trovaner
Pages: 1 ... 41 42 43 44 45 46 47 [48] 49 50 51 52 53 54 55 ... 64
941
« on: January 22, 2011, 09:37:09 PM »
The first messaging method would be extremely helpful for adding more unofficial weight classes. Although we would still be limited to four icons (LW, MW, HW, None)...
The second messaging method seems like it would be much more adaptable/helpful. Too bad it isn't working yet... You're probably experiencing the same error as when a bot is destroyed inside of the garage (after hitting okay on the stats window). If this is the case, you would need to find the coding that is redirecting you to something that doesn't exist.
Would it be possible to make a new button ingame that could be read by the python? My thought is that we could have something like the practice garage inside of a standard arena. In the past, I've tried adding buttons but without the EXE listening, they didn't do anything. I know that the button registers when I click it but just doesn't have anything assigned to it within the EXE.
*Edit after rereading the first post* So I would be in favor of event binding and control creation.
942
« on: January 22, 2011, 07:32:15 PM »
The sergepatcher is available to everyone. Its one of the files that you added to the Arenas folder when installing the unlimited mass mod.
943
« on: January 22, 2011, 07:29:47 PM »
sergepatcher = awesome. Period.
Would it be possible to make the mbox function close-able? I was testing your sergepatcher using the FPS window and the new window kept getting reloaded every time I hit OK/close (it required me to manually close RA2 before it would going away).
944
« on: January 22, 2011, 01:55:34 PM »
You may find some music that you like here. Its free to use/modify/whatever as long as you give credit to the artist.
945
« on: January 21, 2011, 11:46:00 PM »
He has already updated El Diablo for DSL3... All the previous updates have been building up to something, and now that the round tank treads and the axle extenders are done, I've finished the new El Diablo!
(Image removed from quote.)
It's now a MW like the real bot, and it's also much more dangerous. The drum is low enough to hit any wedge that tries to get under it, and unlike a lot of replicas, it actually has a decent number of weapon components.
In case you're wondering why the drum looks different, it's based off of this version of El Diablo:
http://www.robotcombat.com/images/bbsf02/large/el_diablo.jpg
Next up: Firestorm. It's about time I started AI'ing these new replicas, and I decided the first team is going to be fire-themed and include Bob, El Diablo, Firestorm, and an as-yet-undetermined SHW (Alcoholic Stepfather?)
946
« on: January 21, 2011, 12:03:22 PM »
Cool tunes, FB. Its also good to hear that you're still thinking about us. Unless something has changed... Anvil Studio. It's a free MIDI program. He uses a bunch of custom sound fonts, though, so it doesn't sound like typical MIDI music.
947
« on: January 20, 2011, 11:37:24 PM »
A while back, I wanted to figure out the relationship that the material values had with Click's damage formula. What I did instead was find discrepancies riddled throughout what we believed to be the damage formula. Although I had planned to release a more complete study in the Mythbusters thread, this sorta took root early. Since most of you now know that the formula was a little inaccurate, I decided to just to release what I have and let you guys use it as you will... Arena Settings: -Elasticity = 0 -Friction = 1 -Gravity = 9.809980 -self.SetSubMaterial('arena_collision','metal',0) -plus.magicMobility(False) Component Settings -type = extras -base = Component -hitpoints = 10000 -fracture = 10000 -mass = 10 -concussion = x (if variable; otherwise not listed in TXT) -pierce = x (if variable; otherwise not listed in TXT) -material = metal(x) (if variable; otherwise not listed in TXT) hitpoints - I set it high so that I would see a difference when all other values are low
fracture - I set it high so that I would see a difference when all other values are low
frequency - N/A (problems testing with current setup)
mass - N/A (problems testing with current setup)
normals - Does not impact the damage formula (tested separately)
model (pointy or not) - Does not impact the damage formula (tested separately)
Bot Settings: -ChassisHP = 628 -Botlab Weight = 56.7 (includes 10kg sheet) -plus.getWeight(BotID) = 56.7087936401 (this is sometimes very different from that of the Botlab) (includes 10kg sheet) Misc: -I used the pause button throughout the countdown to prevent any lurches after completion (after the bots are loaded of course so that I'm not the reason for the lurch) -I press the pause button as soon as I see the chassis bounce (certain combinations continue to deliver damage after settling onto the other bot)  Basically I modified the Ant Arena to drop one bot on top of the other (green arrow). It also was programmed to print the BotID and HP (chassis and sheet) when I ended the game. ========= Testing ========= Additional Conditions/Stats: -DropDistance = 6.19933 (measured by the bottom of upper bot's component to top of lower bot after settling into ground (I used plus.rayTest(XYZ-StartingLocation, XYZ-EndingLocation))) -DropVelocity = 11.02675 (if calculated the same way as in reality) Variable
ChassisHP, CompHP (of Lower Bot)
ChassisHP, CompHP (of Upper Bot)
Summary
No Variables Assigned
628, 10000
628, 10000
0, 0
1 Concussion
628, 10000
628, 10000
0, 0
1 Pierce
628, 10000
628, 10000
0, 0
Metal(1)
542.7, 10000
628, 10000
85.3, 0
1 Concussion + 1 Pierce
628, 10000
628, 10000
0, 0
1 Concussion + Metal(1)
542.66, 10000
628, 10000
85.34, 0
1 Pierce + Metal(1)
542.64, 10000
628, 10000
85.36, 0
10 Concussion
542.62, 10000
628, 10000
85.38, 0
10 Pierce
628, 10000
628, 10000
0, 0
Metal(10)
-226.39, 10000
854, 628, 10000
854.39, 0
10 Concussion + 10 Pierce
542.7, 10000
628, 10000
85.3, 0
10 Concussion + Metal(10)
-7905.07, 10000
628, 10000
8533.07, 0
10 Pierce + Metal(10)
-225.72, 10000
628, 10000
853.72, 0
100 Concussion
-226.39, 10000
628, 10000
854.39, 0
100 Pierce
628, 10000
628, 10000
0, 0
Metal(100)
-7910.17, 10000
628, 10000
8538.17, 0
100 Concussion + 100 Pierce
-225.61, 10000
628, 10000
853.61, 0
100 Concussion + Metal(100)
-852996.25, 10000
628, 10000
853624.25, 0
100 Pierce + Metal(100)
-7893.31, 10000
628, 10000
8521.31, 0
Concussion(100)/100 = 8.5439
Concussion(10)/10 = 8.538
Concussion(1)/1 = 0 (this is right)
Pierce(100)/100 = 0
Pierce(10)/10 = 0
Pierce(1)/1 = 0
Metal(100)/100 = 85.3817
Metal(10)/10 = 85.438
Metal(1)/1 = 85.3
Strangely, it doesn't look like piercing is doing anything. I made sure that it wasn't a variable that I took out (such as wheel traction, base, type, etc.) but there was no change. This could explain why the EXE converts the chassis' concussion value into HP (although settable, the puncture value and heat value of chassis armor don't seem to do anything). A odd little factoid is that they used the image labelled "icon_puncture.tga" for the concussion value.
You may have also noticed that the concussion and metal values have very similar values. With the only exception being concussion(1), this leads us to believe that the damage was rounded down or there is a minimum value that must be reached. This uncanny relationship between concussion and metal suggests the following provable relationship:
Concussion(10) = Metal(1)
Concussion(100) = Metal(10)
With that in mind, we are able to deduce that the default value for metal is 1/10 of concussion's default.
Concussion(1) and Metal(1) = Metal(1)
Concussion(1) = 0
This tells us that concussion defaults to 1 and if our previous observation is correct, metal's default is 0.1. By increasing the altitude of my starting location, I was able to prove the accuracy of the defaults mentioned previously. By leaving out the defaults in one TXT and including what I believed to be the defaults in another, I could compare the damage.
There must also be a floor/minimum value for damage because concussion(1) didn't deliver any damage. Further testing showed this assumption to be true and that damage had to be greater than 10HP. This floor value prevents us from making weapons that heal the opponent.
On a side note, there also was no change in the amount of damage delivered when I changed the types and bases of the components (meaning that the values were the same). Theoretically, this means that a wheel could be used as a weapon (the HP is gonna kill you though...). This could also explain why the chassis is capable of delivering damage but I wouldn't recommend using it as a weapon :P.
While testing, I noticed that although the velocity was a constant (at each height), the damage still varied slightly. With little else to explain it, I concluded that the game was using a random number generator.
So some of you must already be wondering about the other materials besides metal (rubber and arenium). Believe it or not, they are exactly the same in a component against chassis situation (the value is all that matters and they all default to 0.1). Additionally, GMFs with damaging materials don't appear to take into account the material type or value for that matter (rubber seemed to receive the same amount of damage as metal and arenium). Component to component situations on the other hand are quite a bit different and I don't have enough information on them to say anything for certain (they seem to be using a different formula than component to chassis situations).
I understand that momentum would be better than velocity in terms of determining damage (momentum=velocity*mass) but mass couldn't possibly be used with my current formula being so accurate. I have the mass at the top if anyone want to try to disprove this.
Everything was retested at least 3 times each and I did many more tests that didn't make it into this post (it was WAY to much especially when I know that most people just want to hear the conclusions). Even with all my testing, there may be some mistakes in these notes due to the fact that I was deleting like crazy in an attempt to simply/shorten things.
These are the defaults that I was able to derive:
concussion = 1 (for all types and bases)
pierce = 0 (as far as I know, this is the default but it doesn't impact the comp vs chassis scenarios so I didn't bother doing more testing on this)
material = ???(0.1) (the value is the same for all types and bases but the material type doesn't matter except in comp vs comp scenarios)
In component against chassis situations, this formula gives a rough estimate of damage delivered:
Damage = Concussion*MaterialValue*7.75*Velocity
when the damage is greater than 20 (this means no weak/healing weapons)
Edit: Added the picture that I forgot...
948
« on: January 18, 2011, 11:04:18 PM »
I remember posting something like this somewhere. Click posted everything that I didn't have notes on (and I think my notes came from a post he made on the old forums)
949
« on: January 18, 2011, 06:15:56 PM »
Do you have anything on how metal works relative to piercing and concussion?
I have a pretty good idea of how they correlate but telling you now would spoil the surprise. All my notes on the subject will be in the Mythbuster's thread after I'm finished testing.
950
« on: January 17, 2011, 02:00:51 PM »
Although similar, the formulas for points and damage are different. You may be delivering damage even when there are no points being earned.
One way of testing this would be by using plus.damage(BotID, CompID, Amount, (XYZ-Location)).
Another way of testing this would be by attaching a super powerful spike to the bottom of your chassis and letting the bot drop onto the opponent.
I've successfully done many variations of the above tests without a single 1HKO and I can safely say that the HP, mass, piece, concussion, material, normals, and collision mesh are not the underlying factors for this. The only time that I even came close to a 1HKO was by setting the frequency high enough that the bot received 3 indistinguishable hits upon making contact. I was actually debunking the damage formula in my tests (which after coming up with another test will be showcased in the Mythbusters thread)
When most people get a 1HKO, their weapons are actually hitting the chassis more than once as their weapons are rounding their arc. While completing the arc, there are two possible things that may be happening: (although, I can't say for sure whether both or just one of them is the culprit)
1. The weapons are bouncing off the chassis in the same way that wedges bounce off the arena floor.
2. The weapons knock the chassis and hit it again before it goes out of reach.
Edit: I haven't tested the effect of having two weapons hit at once but I'm pretty sure they get a group sum (not individual sum). The AI actually has a code to see how much damage it last received but IIRC it treats stacked weapons as a single hit, too.
951
« on: January 17, 2011, 12:37:47 PM »
It is possible to guide an AI bot using solely SZs but you would want to have at least one on the left and one on the right (there is no need to have it in front of ore behind the bot but having them could potentially simplify the coding). Madiaba once posted this idea for guiding SOW bots but I think they concluded that it was easier just to look at the servo's angle instead... I use a variation of this for guiding my GMF housebots (the biggest difference would be how I handled being inverted).
952
« on: January 17, 2011, 12:00:34 PM »
I'm glad you defined #1 and #2 because it makes things much more scientific.
#3 is also known as the rock-paper-scissors effect. It was briefly mentioned in Korium9's tutorial. The examples for this are pretty cool and I will undoubtedly test them for myself.
#4 is especially interesting when looking at chassis armor. Like normal components, the HP needs to be depleted first before fracture comes into play. Unlike normal components, the fracture defaults to 40 and 3 critial hits to be destroyed. A powerful blow to a component (including the chassis) that exceeds the remaining HP + fracture results in the component breaking (or in the case of a chassis, a critical hit). If a blow to the chassis exceeds the remaining HP+80 (double the fracture) it will still count as one critical hit to the chassis regardless of whether it is the first or second hit. Using this proven logic, it can also be said that a "one-hit KO" is impossible in RA2. What is really happens is the chassis is getting hit more than once with damage greater than 40 (and with enough force to take out all the HP). With this in mind, a popup that swings three offensive brackets is more likely to destroy its opponent in the first go (as opposed to a popup with 2 offensive brackets).
953
« on: January 17, 2011, 11:15:16 AM »
Best way to do housebots (really the ONLY way as far as I know) is to put them in the .gmf like the rover in the Mars Base and Mad's housebots in the Pittsfield arena.
However, that method is problematic in its own way.
Such as an inability to receive damage, lose components, or get tracked effectively by the AI. If you want to use AI housebots, you can add a line in the Arena.py to restrict their movement to certain sections of the arena until some criteria is met. Doing it this way, you can make all the other AI bots avoid/target the housebots. You could also make it so that only AI bots with certain names become housebots and/or certain BotIDs become housebots. I was actually in the process of making an arena that would use GMF housebots and also have the above AI housebots when the hazards were turned off...
954
« on: January 13, 2011, 12:53:53 PM »
I took a different approach to 123STW's problem. I tried modifying the AI so that the nose switched directions every time the bot flipped. The first problem that I ran into was that the "self.fNoseOffset" was never reloaded by the EXE after the initialization. I then tried sending the NoseOffset directly to the EXE (using "self.__setattr__fNoseOffset__(Radians)") but that didn't seem to work either. My last attempt at changing the nose involved replacing the bindings value and completely reloading the AI (by deleting it before loading it again). Unfortunately, this didn't appear to work either (the bot moved but it was still using the previous nose setting).
I thought about Click's suggestion a few times while I was testing other things but I have no idea if it would work... To test it, just copy and paste the Throttle and Turn sections from __init__.py into a custom PY. Then after commenting out the lines that Click suggested, see if it works ingame (making all the appropriate changes to the bindings (including setting invertibility to True)).
If Click's idea doesn't work, I can make a custom tactic (which was next on my list of things to try).
955
« on: January 11, 2011, 12:07:32 PM »
Usually when the game does that, it means that one or both of the computers are blocking the game via a firewall. I would try turning off the firewall temporarily or adding an exception for RA2.
956
« on: January 10, 2011, 03:54:31 PM »
I agree that there should be a new stock AI pack but I'm not sure about having it be mediocre.
The last successful stock AI was PYS AI (unless you include the upgrades that went into StarcoreV4 Beta (which was never officially released and didn't include any new teams)).
BBEANS AI?
Opps, I suppose you're right. BBEANS AI came out nearly half a year after StarcoreV4 stopped. Inf AI wasn't officially released to the public IIRC and the link doesn't appear to be floating around (unlike StarcoreV4).
957
« on: January 10, 2011, 03:35:35 PM »
I agree that there should be a new stock AI pack but I'm not sure about having it be mediocre.
The last successful stock AI was PYS AI (unless you include the upgrades that went into StarcoreV4 Beta (which was never officially released and didn't include any new teams)).
958
« on: January 06, 2011, 05:55:52 PM »
That actually wouldn't be too difficult without 3DS Max... 1. Open up the decompiled GMF. 2. Find the object entitled "ball" and select the vertexes (lines 637 to 662 (inclusive)). 3. Copy and paste the data into excel. 4. At this point, the data should be separated by the tabs of the original code. Therefore, add a multiplier for one of the X, Y, or Z columns (that will make a nice even egg shape of the spherical cannonball). 5. Then just copy and paste that new data back into the GMF. You may need to code the excel so that everything is next to each other. I have an excel file that does this for me but its not at my fingertips at the moment (if I remember, I'll add it to this post later...) Edit: Here's what I use...
959
« on: January 05, 2011, 10:08:20 PM »
First you need to make sure that the GMF file has a separate object for the floor. Then you can either reuse a GMF object with a hole in the center (like Click's bladewall from the BBEANS Arena) or make a hole using an object for each side (4 objects total). It tends to be a bit more challenging than most assume...
Edit: Mad beat me too it.... but I'm happy to see him around....
960
« on: January 04, 2011, 02:03:53 PM »
You need battery power for the magnet to work.
Pages: 1 ... 41 42 43 44 45 46 47 [48] 49 50 51 52 53 54 55 ... 64
|
Show Posts