View source for Talk:Main Page
For old discussion, see Archived talk:Main Page 20110903.
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Virtual bullet doesn't line up with real bullets | 14 | 08:33, 11 October 2011 |
Saving data between rounds | 2 | 21:56, 6 October 2011 |
while true loop | 3 | 08:12, 29 September 2011 |
LiquidThreads | 10 | 14:56, 6 September 2011 |
Simplify recent change details from thread | 0 | 06:27, 6 September 2011 |
Talk from old wiki | 1 | 17:05, 5 September 2011 |
First page |
Previous page |
Next page |
Last page |
I would guess this is the result of the Robocode idiosyncrasy where a bullet is fired before the gun is turned (so if you do setTurnGunRightDegrees(10), setFire(3), execute(), the bullet is fired before the gun is turned right 10 degrees). So your actual aim is probably the aim from the previous turn, while your predicted is from the current turn.
Well... can't really tell without more information what's wrong, but my first guess about what's wrong, is that perhaps you're not accounting for how within a tick, firing happens before gun turning does. The angle you fire at when you call setFire() is the angle resulting from the prior tick's setTurnGun() type call.
Yeah that's correct, the setFire is from the last tick.
What's a typical pattern for robocode as to code placement? I'm currently placing the gun turning code in the while true loop and the firing code in onScannedRobot
and it's wrapped with if (getGunHeat() == 0.0)
Should I change that layout? (also add && getGunTurnRemaining() == 0.0 to the fire wrap?)
Using onScannedRobot or run is totally just a matter of preference - for 1v1 it won't make any difference, really. It could also be an off-by-1 error in the bullet source location - it should be your location on the tick you called setFire. Or your target angle was farther than your gun could move during that tick, in which case the getGunTurnRemaining == 0 check would solve it.
I know if i combined the 2 logics in 1 function, the code would fail (for me at least) Nevermind i figured it out.
(Also Voidious: I'm testing my bot against yours now because it has pretty debugging graphics and I can see my weaknesses :P Also I perform better against your bot (diamond) if i don't fire :P)
Also, am I suppose to, with my virtual guns, determine the fire direction using last tick's information, since gun turns after bullet fires...
Right now this would f with my simulated hit rate, as sometimes a bullet might hit but not a virtual bullet, or vice versa.
Hm. Even last turn's angle doesn't match with the actual fired one. Idk what's going on, also I think the virtual bullets also hits better..
Anyway to compensate the gun turn after the bullet fire?
My bullets were not lined up either, until in March this year, I finally solved the problem with GresSuffurd 0.2.28. It turned out that when using the estimated bearing of the next tick (firing tick) position iso the bearing this tick (aiming tick), my real bullets indeed lined up with my (correct) virtual bullets. It gained me 0.2 APS, but I reached spot #11 with slightly misaligned bullets, so it is really not that important. Also keep in mind you have to aim at the opponents next tick position.
Wait i'm not sure if i understand what you mean by the next tick's position. How do I accomplish that?
Here's what I roughly have:
while (true){ if (getGunHeat() == 0.0){ fireVirtualBullet(enemyCurrentAbsoluteBearing); // Just use Head on targeting as an example because it's simple fire(2); } turnGunRightRadians(enemyRelativeGunHeading); }
I know this would be wrong. I just don't know how to fix it =S
He means something like:
Point2D.Double myNextLocation = project(myLocation,getVelocity(),getHeadingRadians()); Point2D.Double enemyNextLocation = project(enemyLocation,e.getVelocity(),e.getHeadingRadians()); double nextAbsBearing = absoluteBearing(myNextLocation,enemyNextLocation);
I've tried this, and using it to predict the enemy location didn't help me, although it did help for my own location. I think it depends on the way you define wave hits and starting locations in your gun. In DrussGT I wait until my gun-turn remaining at the beginning of the tick is 0, then fire. I put my bullet on the wave from last tick. As long as you make the same assumptions everywhere it should be ok.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:Main Page/Virtual bullet doesn't line up with real bullets/reply (12).
Yes, that is how bullet collisions work. Maybe take your last aim and align the bullet to that? What I do is mark my previous wave as having a bullet the moment setFireBullet() returns a non-null result.
Can I save data between rounds in the static variables of other classes other than my main robot class?
How is the while (true) loop actually broken down? Does robocode executes the code there 1 iteration per turn? Or..?
Generally, yes - when you call execute(), the Robocode engine processes one tick, including firing all the events on your bot, and then your run() method continues executing. So most of us have an infinite loop that calls execute() at the end, and each iteration is one tick.
But there's no magic to it - you could have a run method that goes:
public void run() {
turnRight(20);
ahead(100);
fire(3);
}
And that would be perfectly valid. Or you could call execute() every third iteration of your loop. In Dookious, my run method used to have a loop that was while (notWonYet) ...
, then a victory dance.
The timing thing for me is very confusing...
For example, if i want to fire at a certain angle, i have to rotate to it.. by the time i do.. i have another angle... which requires more rotation.. etc..
Same thing for turning the robot and going ahead.. I never know how to correctly time them. (Effectively stuck)
For gun aiming, see Robocode/Game_Physics#Firing_Pitfall. This can cause your aim to be a tick behind. I think most robots don't worry about it. But if you do worry about it, what I do is predict robot positions 1 tick into the future and use that for aiming. It's not exact, but works well enough for me.
Just installed LiquidThreads... Hope we all dig it. =)
Liquid threads are kind of better, but still not ideal. My main concern is that this still requires you to go to different pages, some are difficult to get to (have to know it specifically or get refered). For example, if someone were to ask a question/start a discussion on certain type of targeting etc.
Personally I think a forum works the best, as it can break things down into different categories and list everything out in a manageable fashion.
The Facebook group is good, but it lacks the community involvement, in my opinion.
Google+ seems cool, but I can't sign up for it with my Google Apps account..
... and who uses yahoo? :P
That's what the Special:RecentChanges is for - you can see modifications made anywhere on the wiki. Questions can be asked on the person's homepage and moved later, if necessary.
It will take a while to get used to. But there is no need to diff the discussion pages anymore. Neither convert local times to UCT every time I write something. Nice work.
Ultimatebuster: With regards to a forum, personally the problem I would have with a traditional one, is that conversations are often with regards to a specific concept that either has or should have it's own wiki page anyway. The tight linkage between pages and talk pages encourages cross-pollination between the two sides, with discussion inspiring wiki pages and wiki pages inspiring discussion. Plus, I feel that the categories that would be created in a normal forum would be too broad for robocode and cronological sorting within such large groups too limiting.
A forum would be much more open for beginners to ask questions though. you shouldn't try to put everything into categories but just leave it to different threads in topics. --Peltco 06:15, 5 September 2011 (UTC)
Maybe it would make sense to have a page using liquidthreads which is specifically for asking questions when a specific page is not known? Perhaps do something like prominently link it from the main page, or even embed it?
Well, although beginners may not know, but I believe with our not-so-large community you can ask questions on almost any talk page, and if it seems inappropriate, someone will move the conversation to the right place. I really think we should have a bot that post welcome message to user, since IIRC it tells that you can ask question on your talk page.
Personally, I think with the LiquidThread installed, every talk from old wiki should be put into the Archived talk namespace, or discussion header. My main reason is that discussion from old wiki would be uing old-style link, and I don't know how to programme a wikibot to edit a LiquidThread (plus my old converting code would work with the discussion header without modification)
I don't like leaving conversations in the discussion header, since it pushes the LiquidThreads stuff way down the page and I don't think that's what he header is for. I think moving to Archived talk is appropriate in most places, and you can just link to it in the header (like I did in Talk:Main Page).
I'm not sure how to deal with current conversations on the new wiki. I don't want them in the header. Archiving them is OK in most places, and maybe we could do it with a bot, but it feels pretty drastic to do it across the whole wiki. I wish I could just convert them to LiquidThreads conversations...
First page |
Previous page |
Next page |
Last page |