Show Posts

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 - UberPyro

Pages: [1] 2 3 4 5 6 7 8 ... 11
1

2
Ironforge TC Showcases / Re: Kelimpels Ironforge Showcase
« on: May 08, 2020, 06:56:21 PM »
A hybrid, oui oui.

The design is... pretty creative. I don't think it's very efficient though if you're goal is to win a tournament. I have some ideas that will help you lose weight.

Firstly, Having both front wedges and back wedges is nice if you're into bilateral symmetry but it won't help the bot much in battle. It would be better to remove the back wedges since they won't see much use. On top of that, you're spending a huge amount of surface area on the back chassis wedge - it would be better to squish up the back of the chassis to the components as tight as possible (move up the components too if possible) so that the treads are actually hanging further back than the chassis. This should save a ton of weight, and you can use some of that to armor up the bottom/back/top of your robot.

Having a burst motor with spinning ninja stars on the end is ... interesting. Clamp bots (somewhat a gimmick) usually have a servo motor, not a burst motor, bring down their weapon. Alternatively, hammer bots normally do use ninja stars, but not spinning ones. I would take out the spin motor and just put in a huge array of stars - you want to spam in order to maximize your damage, without overloading your beta.

Also, servos are better than bursts for the side clamps too, though I'm thinking this bot would be really hard to AI. The most efficient setup would probably just be to have static arms and use a few rows of the scythes to corral opponents / protect the bot.

3
Are there any banned components within ironforge itself?

Ironforge is very different from DSL - it was designed to be balanced for the DSL-S format. Unlike DSL, there are relatively few options to choose from as far as weapons and armor as concerned as to create a tight metagame among bots, and all of these components were meticulously balanced. DSL is nice for the gazillion replica parts and all the options to design robots exactly the way you want them, but IF is going to be more competitive.

4
IF DSL-S? I guess I have to come back from the dead for this one...

Edit: a JD for a DLS-S battle is a bit unusual though

5

There are two parts to designing a competitive robot in RA2. One part is the actual theory and engineering that goes into designing an effective competitive robot. The other part is using highly convoluted and arcane glitches to construct said robot, allowing you to make designs that would otherwise be impossible. Snapper loading is one of those glitches.

Here's a pretty well-sited 2008 boomer video of Sage (the boomer up above) using snapper loading to place objects:

The tl;dr of this is that snapper loading (particularly snapper loading + eFFe) allows you to create robots with intersecting parts, e.g. cram lots of weapons together or have weapons going through a plow, etc. Afaik RR2 allows everything to intersect, so none of this matters and there is no problem.

Thank you for this!

Just for the record, we do intend to start creating restrictions on part placement at some point.  For example, you shouldn’t be able to place a motor inside another motor.

The sloading question was actually a great question at its core.  Although the word “sloading” is specific to RA2, I foresee a similar issue arising with RR2.  It all comes down to how we handle it though.  Maybe an option in settings to allow components to intersect that is off by default?

I've spent a lot of time thinking about this stuff (you know, dreaming about my ideal robot game), and here's my idea.

Clearly motors / batteries / control boards and such cannot intersect with each other in any case. Weapons and extenders / plates / armors should be able to intersect, but only if they are on the same axis as each other. This means that weapons coming off of two different motors should not intersect, neither can they with a weapon coming off the chassis, but 2+ weapons on the same motor can and weapons coming off the chassis can.

Though this seems to make a lot of sense, there are still a lot of more complicated issues from here to solve. For example, suppose a weapon intersects the path of a spinning bar. One way to handle this is to sweep the hitboxes of all items attached to spinners into disks, this way the hitbox is the entire path or where the component could be at any time. This applies both when trying to attach the bar and when trying to place components in the path of the bar, and this way no parts ever intersect. An alternative solution would be to allow things to intersect paths, but allow the robot to have internal physics with itself so that the weapons collide with each other like in real life.

Another thing to consider is that in RA2, we actually allow weapons to cut through armor as long as the plate / chassis is not completely bisected by the path, because theoretically you could cut holes in the parts. I'm thinking this is less of an issue in RR2 though, because we have enough control to mold things to whatever shape we want (e.g. its realistic now).

Edit: Having the ability in-game to allow all intersections would definitely be nice though. The equivalent in RA2 is using the sergepatcher hack. An even more advanced idea would be to make it so that you select the build mode when first creating the robot, and then this sticks with the bot as a certificate for legality in tournaments, or validation could be handled separately by checking for collisions.

6
ya but can you sload in this game

Pardon my ignorance, but what does it mean to “sload”?

Boomer ra2 term that is obsolete and not useful


bruh rude

I am curious what it meant though.  I assume from the context that it was something people did to improve the game. 

Even though the act of "sloading" might not be relevant to RR2, it is helpful for me to understand what the original problem was that people were trying to solve.

There are two parts to designing a competitive robot in RA2. One part is the actual theory and engineering that goes into designing an effective competitive robot. The other part is using highly convoluted and arcane glitches to construct said robot, allowing you to make designs that would otherwise be impossible. Snapper loading is one of those glitches.

Here's a pretty well-sited 2008 boomer video of Sage (the boomer up above) using snapper loading to place objects:

The tl;dr of this is that snapper loading (particularly snapper loading + eFFe) allows you to create robots with intersecting parts, e.g. cram lots of weapons together or have weapons going through a plow, etc. Afaik RR2 allows everything to intersect, so none of this matters and there is no problem.

7
Now that hotkeys are a thing, how about giving me ideas on what features you want to have available on keyboard and with what key to activate it.
They can be stuff that already has a button assigned to it but would benefit from a keyboard shortcut for experienced players, but also stuff that is only usable through keyboard as they would be impractical in the UI or needs to work together with the mouse.

The hotkeys for functions that are on different sections of the botlab can have the same key, for example snap to grid in the shape creator can have the same key as the snap function when adding components to the robot.

Question:  Is there a way to make it so two motors spin one weapon?  For an example, I have a design that has two motors driving the same bar spinner, each with a separate belt drive going from the motor to the spinner.

As cjbruce said, the robot is saved as a tree structure and that makes this specific feature pretty tricky to implement as I have to rework quite a bit the system to allow for this.
I have had this feature in mind however, and I would be interested in implementing this, but I still haven't found a satisfactory way of doing that.

x, y, z to focus the x, y, z box for editing position
arrow keys / wasd + shift + space for quickly adjusting positions, preferably with a way to control step size
almost every single button on the interface should have something bound to it just to speed things up
an undue button
toggle table / room existence
a way to select components very far away since I remember it being easy to necro robots that way (a tree view of the components would be the best way to do this though)
toggle zoom-in blur
toggle coordinate system to be based off parent component or just normal xyz coordinates
align center of current component with center of another in a particular dimension, e.g. hold x or y or z while clicking on a different component or something
some of these just need options settings rather than a hotkey

8
I haven't looked at this in a long time but something that allows for very precise movement with wasdqz or wasd-shift-space in amounts of ~0.01 a la movepixel was one of the things I remember wanting.
You can edit the coordinates of components to like 3 decimal places
I'm well aware of this, it's just that in very precise builds like my Nightmare build it's too difficult to math out where everything should be, and the build time would go down rapidly if there were movepixel-esque controls rather than having to edit the coordinate, see if its close enough, edit it again, etc.

I'm going to quote the old post I made in here, because it outlines some stuff that really ought to have hotkeys.

Is there anyway I can see what features are planned for future versions? Anyway, I have some suggestions after building in the botlab for some time. A lot of suggestions and a lot of them are complex, so I don't expect you to agree with all of them or try to implement much of what's here in the near future, I know you guys are busy.
I know you guys are not nearly done with the botlab and that given time you guys will make it great, but talking about the botlab right now as it is, it's still pretty clunky in the sense that it takes a very long time to use the controls and the tools given to you to make the botlab do what you want it to do. First of all, I think keyboard shortcuts would improve the building experience 1000%. Things like pressing x to focus the x coordinate, delete for deleting components, arrow keys/wasd + shift + space for moving things around/rotating, basically all the buttons and fields in the interface should have some keyboard mapping because clicking on everything takes forever. Remapping keys would also be great, i.e. i much prefer RMB to MMB for panning. As it is, it's very easy to make mistakes by putting the wrong numbers into the coordinates or into the wrong coordinates, and it's also way too easy to get yourself into a situation where you move something too far away and can only fix it through editing the bot file. An undue button would be a great help for this, and additionally some way to control the max distance from origin of all the components and toggle the room that you are in would all be huge helps. It's also really easy to get objects stuck inside of others, and there's currently a glitch where some small objects won't be able to be selected unless you exit and join the workshop. A lot of these issues could also be helped by having an expandable tree view of all the components like in the bot file and being able to select components like that. Being able to turn off blur from being too close would also be great. When using the moving sliders, they go in increments of .025, and if the component isn't currently at a multiple of .025 then it snaps to a multiple: there should be some way to turn the snapping to a multiple off, because a lot of the more complex builds will not use those multiples very often. This also applies to the rotation and size sliders. There should be a way to control what interval the moving axes move by, either through a field or through several hotkeys which are each set to common values, i.e. .01 and .005 with .025 as the default. It would be great if there was some way to change the directions of the coordinate system so that it doesn't have to be determined by what the object is sitting on, a lot of the times I just want the normal xyz directions. It would be fantastic if there was a way to copy the x, y, or z coordinate of one object and then set the coordinate to another in a streamlined fashion, e.g. hold x while clicking on another object. It would also be great if there was some way to clone mirrors of objects and flip each of the components. It would be nice if we could smooth components along a certain rotational axis. For the chassis and custom object builder it would be great if we could change the numerical values of the xy coordinates via text field of each of the vertices like we can for objects in the rest of the builder.

9
I haven't looked at this in a long time but something that allows for very precise movement with wasdqz or wasd-shift-space in amounts of ~0.01 a la movepixel was one of the things I remember wanting.

10
Aneurysm is cool though i have no idea why are you using tribars for drive lmao, is this an ironforge thing ? is it because tribars have high hp and wheels don't ?

If it wasn't clear, the tribars don't have motors on them, the motor is for the drum. I'm not Reier but the tribars are used as casters in much the same way as old DSL VSes that use long DSL bar as stabilizers or partially static wedges like Mako. It's just the tribars are shaped well for leaving the weapon open to be hit, while having areas that can sit on the ground on both the top and bottom that allows for easy invertible drum designs.

Obviously Reier is carrying not just IF but most of DSL-S on his shoulders, one look at Reier AI and the amount of detail in the robots is painful. There are a few other good builders but not many people post DSL-S style bots nowadays at all really.

11
Where does the ai fail? Does the battle start? Can the robot drive around fine?

If the robot can drive around but the weapon doesn't fire then its probably a StartAngle issue, i.e. try all of the different start angles from -2pi to 2pi in increments of 0.5pi (if you've been reading other threads though I'm guessing you've already tried that). I would investigate it myself but I don't know how weapon skins work. I don't see anything else wrong in the binding. Anyway, good luck.

12
Challenge Board / Re: Badger vs Code Red [IF HW]
« on: September 26, 2019, 01:09:29 AM »
Turn speed infinity much?

Anyway, that battle was actually pretty fun to watch.

13
Off-Topic Discussion / Re: Seagulls, the villains.
« on: August 21, 2019, 07:19:03 PM »
When I read this title I thought it was a Wen tournament or something.

14
How do you make your own PY file? I was looking into making one for my Wandering Spinner bot type...
Philetbabe's AI Chart
but without a decent working understanding of python programming there's no point

15
DSL TC Showcases / Re: Diablo reinstalls RA2
« on: May 02, 2019, 10:49:59 PM »
Would an NPC work for this weight class?

NPC fast is the ideal motor for a fast middleweight. Hazardous Contraption is a good example that uses them and it also makes use of the hypno wheels that provide ultra low ground clearance along with the npcs. Though I'm not sure how much weight you have to play with considering that the bursts and batteries probably take up a good amount of weight.

16
DSL TC Showcases / Re: Diablo reinstalls RA2
« on: May 01, 2019, 08:49:48 PM »
Yeah this is clearly not an irl build or intended to be so lets talk dsl standard

Nice flipper, though those motors are definitely slow for a middleweight and there are a number of improvements that could be made to improve the build. Mainly, flippers tend to do better when the flippers are large, i.e. 80 or 120cm angled sheets, and most robots use a more wedged chassis style to accommodate that (though it isn't necessary). The razors are going to hurt the effectiveness of the bot because it reduces the amount of area has for the flip zone and makes flips harder to pull off, I would recommend moving them more towards the top to prevent robots from going over but be careful that it doesn't affect the bot's ability to self-right. Lastly skirt hinges that sit on a metal hinge make for much wedgier wedges and that should help a lot with getting under other robots.

17
from the very top of clickbeetle's flipper2.py

Quote
# Flipper2.py last updated 7/24/12 by Clickbeetle
# Update 7/24/12: Renamed this file to Flipper2.py so Flipper.py is not overwritten.  Added customizable srimech firing interval.

# This AI will act normally as long as the opponent is moving.  If the opponent stops moving, this AI will also stop and wait for the opponent to be counted out.  If the opponent starts moving again, so will this AI.  In a rumble, this AI will ignore any bots that aren't moving and will only stop if all opponents stop.
# Has support for two smart zone-based weapons and one analog-controlled spinner.  Name the smart zones "flip" and "weapon" and the controls "Flip", "Fire", and "Spin".  "Srimech" control for self-righting.  Note you must put 'UseSrimech':1 in Bindings.py to self-right with the Srimech control; otherwise it will use Flip.
# CUSTOMIZABLE SETTINGS:
# 'EnemyMoveRadius' sets how far the enemy must move in order to be considered mobile.  Default is 1.
# 'EnemyMoveTime' sets how long (in seconds) the enemy has to move the required distance before being considered immobile.  Default is 3.
# 'PrioritizeFlipper' if set to 1, the AI won't fire the other weapon until the flipper fires.  Useful for bots that use the flipper to get under opponents.  When all of self.weapons are lost, the flipper will stop firing and the other weapon will fire even when the flipper doesn't.  The flipper component id's should therefore be set in self.weapons and no other id's for this to work.  Default is 0.
# 'NoChassisTime' sets how long (in half-seconds) the AI will wait to find the chassis before giving up and firing, when there are components in the smart zone.  ONLY WORKS FOR SECONDARY WEAPON, NOT FLIPPER so wire the bot and name the controls like you are using Omni or Popup.py if you use this.  Default is 1.
# 'SrimechInterval' sets how often the AI fires the srimech when attempting to self-right.  Srimech will fire once every X seconds.  Default is 1.
it tries to be smart by not flipping things that are immobilized
the stock flipper.py is mostly the same thing except without the extra controls to fire, spin, and srimech. I'm not sure how well it works though and at the end of the day I don't think the ai is that important.

Good point. I guess the omni is better for the most part, but when it comes to fighting a non-invertible bot, then flipper is better.
flipper checks if its opponent has set invertible to true in its AI

18
from the very top of clickbeetle's flipper2.py

Quote
# Flipper2.py last updated 7/24/12 by Clickbeetle
# Update 7/24/12: Renamed this file to Flipper2.py so Flipper.py is not overwritten.  Added customizable srimech firing interval.

# This AI will act normally as long as the opponent is moving.  If the opponent stops moving, this AI will also stop and wait for the opponent to be counted out.  If the opponent starts moving again, so will this AI.  In a rumble, this AI will ignore any bots that aren't moving and will only stop if all opponents stop.
# Has support for two smart zone-based weapons and one analog-controlled spinner.  Name the smart zones "flip" and "weapon" and the controls "Flip", "Fire", and "Spin".  "Srimech" control for self-righting.  Note you must put 'UseSrimech':1 in Bindings.py to self-right with the Srimech control; otherwise it will use Flip.
# CUSTOMIZABLE SETTINGS:
# 'EnemyMoveRadius' sets how far the enemy must move in order to be considered mobile.  Default is 1.
# 'EnemyMoveTime' sets how long (in seconds) the enemy has to move the required distance before being considered immobile.  Default is 3.
# 'PrioritizeFlipper' if set to 1, the AI won't fire the other weapon until the flipper fires.  Useful for bots that use the flipper to get under opponents.  When all of self.weapons are lost, the flipper will stop firing and the other weapon will fire even when the flipper doesn't.  The flipper component id's should therefore be set in self.weapons and no other id's for this to work.  Default is 0.
# 'NoChassisTime' sets how long (in half-seconds) the AI will wait to find the chassis before giving up and firing, when there are components in the smart zone.  ONLY WORKS FOR SECONDARY WEAPON, NOT FLIPPER so wire the bot and name the controls like you are using Omni or Popup.py if you use this.  Default is 1.
# 'SrimechInterval' sets how often the AI fires the srimech when attempting to self-right.  Srimech will fire once every X seconds.  Default is 1.
it tries to be smart by not flipping things that are immobilized
the stock flipper.py is mostly the same thing except without the extra controls to fire, spin, and srimech. I'm not sure how well it works though and at the end of the day I don't think the ai is that important.

19
Tournament Archives / Re: 100% robots
« on: April 29, 2019, 06:01:22 AM »
If you're running a tournament its a very good idea to learn how to AI, especially because you'll have to deal with that stuff somewhat just when adding and removing robots from the game. It's not that hard. There's plenty of resources in the tutorial index.

20
Showcases / Re: Post Your RR2 Bots
« on: April 28, 2019, 04:58:11 PM »
That level of detail is absurd, I seriously don't know how you're so good at this

Pages: [1] 2 3 4 5 6 7 8 ... 11