-
Posts
171 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Events
Everything posted by Marioman
-
http://www.twitch.tv/weasalss/b/445595740
-
I agree with what 7th said. If the council comes to an agreement on what should be done, great. As a fairly active player I think most of you know that i'm entirely benign, I did not mean to provoke Caer. However, given his actions, don't say he doesn't deserve the criticism. Apparently he's decided to start a personal vendetta against me... a sort of response which is definitely not ok for being league OP. From my experience as an ER in DSB, using your powers to personally hold a grudge against a player is exactly the type of action that would get you sacked.
-
The game that you saw me show up to and not play last sunday only had 2 other people present... (Nude for Satan and Pryde). I am tired of playing 3v4 or 2v4, this would have been the 3rd or 4th time I did something like that. Lastly, thanks for making a personal attack. I won't push this any further.
-
I've been bothering Caer about this for weeks, and as the league manager I consider his actions to be somewhat questionable. This week is sort of an opportune moment to complain on the forum as a lot of squads had to play with less than 4. My squad, Alpha Reunion has been struggling with this problem for more than a month, mostly having 1 or 2 other pilots aside from me show to the matches. Having told Caer about this trend in week 11, I requested an exception should be made to the roster lock and players on AR should be allowed to change squads. He said no, because the official rules required 2 no-shows. I cited 2 consecutive matches which should've be enough to satisfy the official rule: Week 9: April 28th AR vs Requiem - AR showed 2 (Weasal and Badlamb) Week 10: May 5th AR vs Assassins - AR showed 1 (Mighty Sven) He refused. Now, It's clear to me that AR's activity will stagnate or decline, but despite this Caer has remained stubborn and held to his decision to refuse any players on AR from changing squads. Please weigh in on this issue so it can be resolved. Personally, it's not fun to play on an inactive squad and I think it would benefit the league if some of the pilots on squads with less activity could be consolidated to active squads. Thanks, Weasal
-
Let's not get too butthurt over anything guys, it's just 2d spaceships.
-
Hey Bak, I haven't tried this or searched the forum much, but is there a feature list or site for discretion? Thanks for the update, I'm interested in using Discretion instead of the official client.
-
<ASSS: C> Fake Player Platform: Official Public Release
Marioman replied to Cheese's topic in Development
Cool project cheese. I suggest BitBucket, if you ever want to have private backups of repos then that's free. Github/Bitbucket are comparable when it comes to free public repository hosting, but Github has a much higher user base (don't think that's relevant here) and doesn't do mercurial natively (which doesn't matter if you use git). numpf: hi. -
Groundwork The actual reason I developed Continuum Resizer was to overlay graphics over Continuum. This is straight-forward when playing windowed (overlaying over windows is easy) but things change when you're trying to draw over a fullscreen directx/draw application. I tried a different ways of getting graphics to appear over a directx/draw app but was unsuccessful so in the end I changed strategies to just making continuum a window (when in fullscreen mode). Getting fullscreen windowed was not at all necessary for overlaying graphics (since continuum already has a windowed mode) but I wanted any add-on I developed to be seemless. Once I developed resizer, I did some probing of Continuum's memory. It should be noted that Continuum has an encrypted executable, prevents debugging, and also encrypts its network data. However once in game, Continuum does store some useful game-related objects in heap memory. I found ship data (position/velocity) and powerball data. A value essential to the add-on I had in mind but was missing was a reliable ship rotation value. (I found something which was indirectly related to rotation - it could be converted to rotation most of the time - however it would start going wonky when energy levels were low). After some time I decided switch methods to trying to get the ship rotation from when continuum draws the ship graphic to the screen. This worked. So, to recap, with these foundations in place i can now read all ship position data and powerball data whenever from continuum. By whenever i actually mean whenever (which is spectacular): before the frame is drawn, after the frame is drawn, essentially any arbitrary time. This is everything I need for the add-on in mind. The Addon The goal is a multifunction add-on running silently along Continuum for use in the Powerball zone. This is the feature-list detect ports and warp to them when the ball was within catching distant of them (port-steals/port-goals) (implemented) overlay loose ball trajectories (including geometry of the lvl) overlay where the ball comes to rest (onscreen) have a mode that searches for any possible scoring shots and automatically shoots those shots (an aim-bot) display how much time left on the ball timer for any player carrying the ball (implemented) and have context-sensitive hotkey combos for: ballkilling (an enemy passes you the ball while you were goalie & shooting bullets - the add-on would immediately shoot back the ball, which prevents anyone from ballkilling you in goal) passing (ctrl/tab passes always use insert) I have ceased working on it as it's too much effort to glean geometry data from the lvl and use that to compute ball trajectories/possible shots. Also, it's undetectable in the current version of continuum and likely to be so forever since continuum isn't developed anymore lol. I'll leave anyone interested with a link to the source: https://bitbucket.org/weasal/powerballshot/src Anyone competent should be able to compile it with a bit of effort, idiots/skiddies probably will have trouble since I haven't included any of the project files. This was intended to be mostly academic, but it is cheating, so mods, please do net-ban me.
-
I think for a new client to be successful it needs to be able to show that it can exactly duplicate subspace's classic gameplay. That should ensure old players should migrate. Updates/upgrades should be made to everything aside from the core gameplay - like performance, graphics, UI, etc to get up to par with modern games. Look at starcraft 2's UI, diablo 3's UI, etc, whatever is lacking in Continuum today should be added. Also he designer should make it possible for the gameplay to be extended with new features. Maybe the ability to add completely new weapons/new ships/new physics/new items/new level objects to interact with would be a good start. For example, If someone wants to add a new weapon, as long as they have the knowledge, they should have all the tools necessary for that. If someone wants to make an animated base or landscape, they should be able to do that. If someone wants to add diagonal tiles for bullets, they should be able to do that. If someone wants to limit the ship direction to the 4 cardinal ones (90 degree turning), let em, or smooth turning (360 degree float vals) let em, or classic discrete turning (increment by 9 degrees), let em. Accomplishing that would be ideal, though it's a huge task and only my opinion =D.
-
-
Try pressing F1 a couple of times in game to go through the zone's help text. Shows up in the top left. Usually covers all the basic concepts for each zone.
-
Actually I think the quadtree might be able to be used as a suitable navmesh. Do an A* search, if entering region with the number of tiles greater than or equal to (region width) - (width of ship) in the search i'd have to make sure there are paths north/west/east/south of this tile (inefficient). Of course i can make the cost value of each region in the search weighted based on how gray it is (what % of it is tiles). Currently in the quadtree i split up a region and create child regions when one exceeds a max amount of tiles (16 in picture). Instead, to ensure i don't have a lot of medium sized regions with tiles numbering region width, I can decompose until their grayness is at a certain percentage (e.g. 25x25 region with one vertical blocking segment of 25 pixels has grayness 1/25 while a 10x10 segment with one vertical block of 10 pixels has grayness 1/10).
-
Yeah it hadn't occurred to me that there isn't a type the holds a single bit haha so you're right a byte array is probably more practical. For path finding over large regions i wanted to decompose the map into a set of regions that were connected and had adjacency information so there would first be a global path finder then a local path found through the global path's regions. Giving that idea a bit of thought though, i think it's a different problem irrelevant to how i'm storing the tiles.
-
oh yeah and it looks like ASSS uses sparse arrays, however i'm not sure since i don't understand the #include "sparse.inc" in mapdata.c. There's no sparse.inc file in the ASSS source, and in the makefile it has this # generated file for mapdata $(call tobuild, sparse.inc): $(builddir) $(SCRIPTS)/gensparse.py $(SCRIPTS)/sparse_params.py $(PYTHON) $(SCRIPTS)/gensparse.py $@ $(SCRIPTS)/sparse_params.py but i don't know where any of the sparse python files are located.
-
@Dr Brain yeah i didn't think of doing that. If i did go that route i could just encode whether the tile is traversable in a single bit and have a 1024x1024 single bit array... would only be 128kB! However i still think i would need nice way to group the tiles on the map so i might be able to create a connection graph for macro-path-finding. @Cheese a live demonstration would be super cool. Also i'm curious, and i had asked this a while ago on your other thread cheese: in what way are you making your bot fly the path? (or are you sending position packets in a way to make it look like the bot follows the path)
-
i just connected, it's still up i believe.
-
I'm curious what data type you guys think would be best for indexing tiles. Could the devs for existing projects (like DCME, Discretion, jab jab jab's java client) maybe share a bit on how they do it? Some options i found on wikipedia Why i'm asking is because i'm trying to make a bot that can navigate a map so it would be good if i could get all tiles within a certain distance away. Also performance is critical. I started out with a quadtree since that's the only thing i'm familiar with and it's easy to implement. http://i.imgur.com/VCHyB.png
-
this is awesome
-
Opened up paint and gave making a little spaceship a go, didn't turn out too bad. http://i.imgur.com/Cm2jS.png Also uploaded v1.0 of continuum resizer, check it out.
-
I need something nice to use as a tray icon for continuum resizer. Suggestions? I attempted to use the emblem but it doesn't shrink well http://i.imgur.com/gZ8IL.png
-
yeah the no speed limit thing is cool, i guess i thought if you're far away from a repel source it doesn't repel as hard, but that's not true is it.
-
i'm not sure but from playing it seems that wormholes might do: force = constant / (distance between ship and wormhole)2, and repels change the direction of the ship to the ray pointing away from the center of the repel, and set set the ships speed proportional to the distance away from the repel or maybe the inverse of that. another thing you could try is install a packet sniffer (like wireshark) and monitor the outgoing ship position packets continuum sends. then have another player trigger a repel. put these values into excel and analyse. same goes for the wormhole.
-
Make sure you downloaded the continuum installer from a trusted site like getcontinuum.com.
-
have you considered using a library for physics (like box2d or chipmunk)? you can find lots on rigid body collisions on google. i'm not sure if your collisions take into account the shapes of the colliding objects or just treat everything as squares (which continuum does). i'd definitely recommend using a tried and true library for physics instead of rolling your own if it's the former (it may take a bit of work to integrate with whatever you had previously).