At 9/3/16 07:01 AM, Gimmick wrote: -pls_quote_this_part_only_if_replying_to_above-

Shit, this looks like something I should read and reply to..
..
..
Later. Soon-ish.

At 9/3/16 12:18 AM, egg82 wrote:

Why don't you just download one? I'm sure there are dozens of russian hackers just waiting to help you :P

I'm sure they would, as they'd be just as happy to give that same program to AV companies for inclusion in their lists ;)

Found this little gem in my logs today:

301 is because the request was http, not https. Checked myself, I neither have that plugin installed nor if I did would it work on various different levels for various different reasons.

Question, though: Is it REALLY that common for the www-data user to have read access outside of the web root & config directories? Mine doesn't, but I mean.. Jesus. Allowing www-data read access to /etc/passwd is just asking for trouble.

Edit: /etc/shadow, not /etc/passwd
.. Dunno why /etc/passwd is useful, exactly, aside from username enumeration.

At 9/4/16 01:30 PM, egg82 wrote: Question, though: Is it REALLY that common for the www-data user to have read access outside of the web root & config directories?

I wouldn't put it passed someone to run Apache, or whatever server, as root. Wouldn't be the dumbest thing I've seen.

WordPress also has a long history of massive security flaws due to its own poorly written core code, and more often, its poorly written plugins. I recently had to fix a site for a client because they were using a very, very out-dated version of Slider Revolution (we didn't set it up, their own web developer did) which allowed people to download the wp-config.php file as well as write other files, and they used the latter to inject a hacked version of jQuery which used goofy unicode characters and the .split("").reverse().join("") trick to conceal the hack, which was used to have the mail server send spam.

At 9/4/16 01:30 PM, egg82 wrote: Dunno why /etc/passwd is useful, exactly, aside from username enumeration

Probably that and hoping the passwords are insecure, which more often than not they would be, and are susceptible to a rainbow table attack.

Hey guys,

We're live with fundraising so I can actually spend time making games again :)

Would appreciate a small pledge and/or a greenlight yes vote if any of you want to help.

Cheers!

Kickstarter:
https://www.kickstarter.com/projects/1056755819/arrival-in-hell-remaking-a-classic-point-and-click

Greenlight:
http://steamcommunity.com/sharedfiles/filedetails/?id=712658508

At 9/8/16 05:46 AM, Rustygames wrote: Would appreciate a small pledge and/or a greenlight yes vote if any of you want to help.

Pledged! Always happy to support a fellow reg lounger. The game looks pretty sweet so far.

At 9/8/16 02:28 PM, PrettyMuchBryce wrote:

At 9/8/16 05:46 AM, Rustygames wrote: Would appreciate a small pledge and/or a greenlight yes vote if any of you want to help.

Pledged! Always happy to support a fellow reg lounger. The game looks pretty sweet so far.

Cheers mate!

At 9/8/16 05:46 AM, Rustygames wrote: Hey guys,

Kickstarter:
https://www.kickstarter.com/projects/1056755819/arrival-in-hell-remaking-a-classic-point-and-click

Damn you and your non USD prices, and currency that is stronger than our dollar! I completely missed that £ symbol when pledging. oh well, money well spent. Good luck!

At 9/4/16 01:30 PM, egg82 wrote: Question, though: Is it REALLY that common for the www-data user to have read access outside of the web root & config directories? Mine doesn't, but I mean.. Jesus. Allowing www-data read access to /etc/passwd is just asking for trouble.

https://github.com/search?utf8=%E2%9C%93&q=+%22user+root+worker_processes%22+in%3Afile+filename%3Anginx.conf&type=Code&ref=searchresults

At 9/9/16 01:45 PM, PrettyMuchBryce wrote: https://github.com/search?utf8=%E2%9C%93&q=+%22user+root+worker_processes%22+in%3Afile+filename%3Anginx.conf&type=Code&ref=searchresults

That link gives me an error :(

Thought I'd share this because I think it pretty much encapsulates how Janna works, turning a fight around 180. (Slowed by W ability, chased down and slaughtered after GIF ends)

Also my APM was slightly higher than community average that game. Shaking off that rust!

I'e been sick recently and since my games HDD failed I have to wait until payday (Friday) for my direct-deposit to hit before I can grab an SSD for games.

So, I installed League of Legends and a few random Steam games onto a temporary SSD until then. Also, to keep myself entertained, I've been writing blog posts.

So, yeah. How's everyone else's week been?

At 9/13/16 09:10 PM, egg82 wrote: So, yeah. How's everyone else's week been?

Sick. Lots of work and applying for jobs, little gamedev time. The usual.

Just watched the Snowden movie. Interesting stuff, worth a watch. I already knew most of it, but you still learn some things.

Also, cool.

Edit: Just saw this. Whoa.

I made a thing. WASD to control, extremely glitchy.

At 9/19/16 05:12 PM, SkyFire2008 wrote: I made a thing. WASD to control, extremely glitchy.

That's not bad.

I'd recommend looking into a keyboard library/API for detecting when a key is down rather than listening for the KeyDown event as that will remove that short delay in movement after pressing a movement key. @MSGHero wrote a class for that here which will do the trick; just call the init function in your main class, passing the stage as an argument, before your EnterFrame event fires, then use the isDown() function to detect key presses without that delay and isReleased() to detect a key being released (which will only return true once for each release). A few years ago I also wrote this tutorial on how to achieve that, albeit it doesn't contain working code you can use, but it will explain how code like MSGHero's works (if you're interested in that).

edit:

Just read through that old tutorial I wrote and I was actually kind of a dick in my replies (I don't post like that anymore). So maybe don't read passed the tutorial. :)

At 9/19/16 06:01 PM, Diki wrote: Just read through that old tutorial I wrote and I was actually kind of a dick in my replies (I don't post like that anymore). So maybe don't read passed the tutorial. :)

I think we all were at some point.

At 9/28/06 11:10 AM, Rustygames wrote: get a life

Oh wait 10 year anniversary of the reg lounge and this post is coming up.

At 9/19/16 06:01 PM, Diki wrote: I'd recommend looking into a keyboard library/API for detecting when a key is down rather than listening for the KeyDown event as that will remove that short delay in movement after pressing a movement key.

Yeah, I know, I once wrote a class, that does just that, but I can't find it at the moment. Anyway, that's not a problem, I'm more concerned about the collision resolution: sometimes you can glitch through the ceiling, even though the speed is not high enough to pass through it completely.

I updated it with proper keyboard controls, and now you can see the buggy collision resolution in all its glory.

New version, still kinda shit.

At 9/20/16 11:12 AM, SkyFire2008 wrote: New version, still kinda shit.

doesn't seem buggy, but the speed seems awfully high and clunky, at least compared to the level layout.

At 9/20/16 01:40 PM, GeoKureli wrote: doesn't seem buggy

Try jumping, when standing like this, it will move you to the right.

At 9/20/16 02:37 PM, SkyFire2008 wrote:

At 9/20/16 01:40 PM, GeoKureli wrote: doesn't seem buggy

Try jumping, when standing like this, it will move you to the right.

FIrst off, it's really hard to get up there, whenever I make it up there I end up falling off the right side.

As for the issue, it seems like it's happening because when you jump you're embedded in the left tile, and you're overlapping in the Y axis more than the X, and the code resolves the smaller one. it's also doing collision detection/resolution per tile, meaning it resolves 1 collision before moving onto the next one.

Your current flow is to move the player according to its velocity, check overlap, resolve. I recommend checking collision of where it's going to be, before moving it, determine which tile collision happens first (where the frame start time is t=0 and the next frame is t=1) then move the players position based on the time of that collision. pos += velocity * t. that way the position the collision resolves to is always the original direction they were traveling

EDIT: for instance: if the wall is 5 pixels above your starting point, and your velocity is 10, t=0.5. so pos += velocity * 0.5. and you check all tiles for the lowest t (earliest collision) and use that t value

Random idea: create a public github repo, and make some super simple topdown WASD controls for a square block. then go on forums and link the repo.

The idea is, we hot potato the game from dev to dev, where everyone has a short amount of time to add 1 small feature to it.

At 9/21/16 12:26 AM, GeoKureli wrote: Random idea: create a public github repo, and make some super simple topdown WASD controls for a square block. then go on forums and link the repo.

The idea is, we hot potato the game from dev to dev, where everyone has a short amount of time to add 1 small feature to it.

Yes!

I wanted to run something like this on campus, but it was just an idea in passing and I never pursued it. I did think of some rules, like maybe the game would always be live somewhere, anyone can commit something automatically (as long as it doesn't break/syntax error), you can't do two commits in a row from the same account, maybe each commit can only be so many changes.

And you just watch it evolve over time (and play the different versions over time?)

At 9/21/16 01:02 AM, OmarShehata wrote: Yes!

I did think of some rules, like maybe the game would always be live somewhere, anyone can commit something automatically (as long as it doesn't break/syntax error), you can't do two commits in a row from the same account, maybe each commit can only be so many changes.

I just had the idea maybe 30 minutes prior to posting it, so I haven't thought too heavily about it. I'm extremely open to suggestions. I'm not too keen on commit restrictions, since they can cram a ton into a single commit.

And you just watch it evolve over time (and play the different versions over time?)

Bingo!

At 9/20/16 06:36 PM, GeoKureli wrote: As for the issue, it seems like it's happening because when you jump you're embedded in the left tile, and you're overlapping in the Y axis more than the X, and the code resolves the smaller one. it's also doing collision detection/resolution per tile, meaning it resolves 1 collision before moving onto the next one.

Exactly, I followed the metanet tutorial.

I recommend checking collision of where it's going to be, before moving it, determine which tile collision happens first (where the frame start time is t=0 and the next frame is t=1) then move the players position based on the time of that collision. pos += velocity * t. that way the position the collision resolves to is always the original direction they were traveling

Thanks, I'll try that. I tried resolving the collision using the velocity, previously, but I just realized, that it was bugged. I corrected it, and it is now much better.

I'll also gladly participate in the top-down collab, if you do it in haxe or JS, cause I'm using Linux and I have no idea how to compile AS3 under Linux.

At 9/3/16 06:55 PM, Diki wrote: I don't know how this could possibly work without a server-side database that is storing this information to ensure there are no collisions, which are inevitable with psuedo-random generation. It's certainly not probable, but it is 100% possible and 100% inevitable on a long enough timescale.

Agreed, but since it's long enough and random, it's improbable enough to be discounted...for now. fingers crossed

That is not how passwords should be used. It sounds like you're using their password as a key, which means you need to store that password in a reversible way to ensure its validity—lest you not have any way to confirm a successful decryption—which is something you should never, ever, ever do with passwords. Passwords should only ever be stored using an irreversible hashing algorithm and nothing else, no exceptions.

I don't understand. Isn't verifying that the file contents (after decryption) proof that the password's correct?
Hm. Zip files seem to be insecure regarding the file contents; is this a problem, though? (Supposing the files within are replaced with unencrypted ones; won't trying to decrypt it result in garbage?). If so, are there any alternative solutions, in that case?

I'd also recommend learning i) ii) iii) and iv) before trying to make something that requires the knowledge of all four.

OK.

At 9/3/16 07:01 AM, Gimmick wrote: Is this feasible?

If you have a server then, yes, this is feasible, but I don't recommend doing what you're describing; it's both insecure and inefficient.

True, true. However, in my requirements I specified "minimizing load on servers" (yes I know it was rather stupid of me) and my hands may* be tied regarding this. Is there any other method that's a bit better? (Security is a concern, but seeing as it's a "demo" may not be as big an issue - for the moment, at least.)

(* maybe, maybe not. Depends on whether I'm nailed to the post regarding the requirements or not)

At 9/21/16 01:27 AM, GeoKureli wrote: I just had the idea maybe 30 minutes prior to posting it, so I haven't thought too heavily about it. I'm extremely open to suggestions. I'm not too keen on commit restrictions, since they can cram a ton into a single commit.

Ideally it would be people doing small incremental changes to other's code, right? I mainly want to avoid the scenario of one person doing a ton of work in one go and having too much influence on the game's design. You could maybe limit the number of statements (not lines) committed. Or no technical limitation but just explain the rule of small increments and common sense?

At 9/21/16 04:40 AM, SkyFire2008 wrote: I'll also gladly participate in the top-down collab, if you do it in haxe or JS, cause I'm using Linux and I have no idea how to compile AS3 under Linux.

I'd vote for Javascript so that there's a low barrier to entry and the latest version can always be running live!

At 9/21/16 01:44 PM, OmarShehata wrote:

At 9/21/16 01:27 AM, GeoKureli wrote: I just had the idea maybe 30 minutes prior to posting it, so I haven't thought too heavily about it. I'm extremely open to suggestions. I'm not too keen on commit restrictions, since they can cram a ton into a single commit.

Ideally it would be people doing small incremental changes to other's code, right? I mainly want to avoid the scenario of one person doing a ton of work in one go and having too much influence on the game's design. You could maybe limit the number of statements (not lines) committed. Or no technical limitation but just explain the rule of small increments and common sense?

A good way to think of it is that it can be a short break from the project you've been grinding on for months/years.

At 9/21/16 04:40 AM, SkyFire2008 wrote: I'll also gladly participate in the top-down collab, if you do it in haxe or JS, cause I'm using Linux and I have no idea how to compile AS3 under Linux.

I'd vote for Javascript so that there's a low barrier to entry and the latest version can always be running live!

Good point. I was thinking Haxe, but JS seems like a better idea. There can always be more than 1 going on at any time, with different languages/starting points.

At 9/21/16 10:33 AM, Gimmick wrote: I don't understand. Isn't verifying that the file contents (after decryption) proof that the password's correct?

It's not a matter of being able to confirm the validity of the password. The problem is that it would make it easy to figure out what the password is. One significant problem is that the encryption key (i.e. the password) cannot be salted when used that way and is therefore susceptible to rainbow table attacks. Encryption/decryption is also designed to be fast, whereas hashing algorithms intended for passwords and other secure data are comparatively slow; them being faster means the password can be brute forced faster.

At 9/21/16 10:33 AM, Gimmick wrote: Hm. Zip files seem to be insecure regarding the file contents; is this a problem, though? (Supposing the files within are replaced with unencrypted ones; won't trying to decrypt it result in garbage?).

Probably.

But if the password were figured out using one of the methods I described above, an attacker could replace the files with malicious software (e.g. adware, trojan horses, viruses, keyloggers) that was encrypted with the password and will then be successfully decrypted.

At 9/21/16 10:33 AM, Gimmick wrote: If so, are there any alternative solutions, in that case?
[...]
(* maybe, maybe not. Depends on whether I'm nailed to the post regarding the requirements or not)

What exactly is the reason you're looking to create this? Are you doing this for fun or is this work for a client who is setting bizarre requirements?