Dr Lancer-X's Profile
Reputation: 175
Godly
- Group:
- DigiStaff
- Active Posts:
- 9,176 (1.12 per day)
- Most Active In:
- The Junkyard (2594 posts)
- Joined:
- 20-March 02
- Profile Views:
- 392,203
- Last Active:
- May 31 2024 11:29 AM
- Currently:
- Offline
My Information
- Member Title:
- 電波、届いた?
- Age:
- 36 years old
- Birthday:
- May 16, 1988
- Gender:
- Location:
- ur mom nmiaow
- Interests:
-
i like eggs
also i like taking dumps and stuff
Contact Information
- E-mail:
- Private
- AIM:
- Exophase
- MSN:
- shotgun steven
- Yahoo!:
- violent hippo
- ICQ:
- 2147483647
- Website URL:
- http://
Previous Fields
Posts I've Made
-
In Topic: shot detection
25 February 2024 - 05:11 AM
There's nothing direct. How feasible this is depends on what else is going on on the board at the same time.
For example, if there's no other source of player-hurting bullets on the board, just use the :playerhit label
However, once a robot has fired a bullet, there is nothing unique about that bullet tying it to the robot in question - it just becomes a plain, neutral bullet with a given direction. There's some nasty shit you could do to try and make a guess - for example, use code to follow the bullet's path, make sure it's still there. If the bullet disappears and the player is in the right location to be hit by it and the player's health is reduced in that same cycle, chances are very good your bullet hurt the player - but nothing is certain.
Another alternative is that you could simulate a bullet, using a sprite or overlay to draw it, and just reproduce in robotic all the usual bullet handling (what happens when it hits various creatures etc.), except for a special case when hitting the player. However other code potentially on the board, such as code checking for the presence of a bullet in a given location, or if any bullet etc. will not work. -
In Topic: Slow down player movment
20 January 2024 - 07:14 AM
Unfortunately there's not. The reason the lockplayer/unlockplayer loop is bad is because the player is controlled with cursor keys and autorepeat, which means the player only moves one tile when a key is pressed, but if you hold it, the player moves multiple tiles. This means the player can be finely controlled with individual keystrokes, but that you can move longer distances in one direction by holding down a key. This is what you want, but in the context of a robot locking and unlocking the player every cycle, these fine motions are lost because around 50% of the time they won't be registered. Ideally, what you would have with a slowed down player is the same precise individual movement, but the hold down movement is slowed.
Here's something hacky that may be more along the lines of the kind of thing you want:
: "l" set "local2" to "('playerx'x'playery')" wait for 1 if "('playerx'x'playery')" != "local2" then "mov" goto "l" : "mov" lockplayer wait for 1 unlockplayer goto "l"
Upon detecting a player movement, we lock the player for a cycle. This means that the player will remain responsive but won't be able to move more than 1 tile in 2 cycles.
Comments
Bramble
05 Dec 2023 - 17:23Dr Lancer-X
21 Nov 2015 - 02:40asgromo
21 Nov 2015 - 00:59Kuddy
12 Apr 2012 - 01:38nooodl
29 Feb 2012 - 21:49Dr Lancer-X
27 Feb 2012 - 23:46Val
27 Feb 2012 - 23:34Dr Lancer-X
26 Feb 2012 - 03:03Val
26 Feb 2012 - 02:43Val
26 Feb 2012 - 02:43xinexix
26 Feb 2011 - 02:51Dr Lancer-X
24 Jul 2010 - 10:19CJA
23 Jul 2010 - 22:43