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 - Josh @ Dreamland

Issues Help Desk / Re: Josh is an idiot.
« on: October 22, 2012, 11:16:00 AM »
Cool. Now, try calling init_joysticks().

Issues Help Desk / Re: Josh is an idiot.
« on: October 22, 2012, 11:11:37 AM »
Try filing a report which contains more about how to reproduce your problem and less about the objects of your dissatisfaction.

Proposals / Re: Collision shape options
« on: October 20, 2012, 04:58:36 PM »
I'll happily pull the patch so long as it doesn't break any existing functions.

Announcements / Re: Das Newspost
« on: October 17, 2012, 02:56:29 PM »
Very little. I'm stuck with my college workload, and no one else is doing much. Actually, forthevin committed a pixel-perfect patch for the bbox collision system. I still have no idea what nbeer's issue is (haven't gotten around to it), and I have had essentially no time to work on integrating JDI into the EDL parser. So no movement there, really.

Proposals / Re: Collision shape options
« on: October 12, 2012, 06:01:36 PM »
Quite right. We'll need to pass that as a second parameter, then; your correction is accepted. Though I might switch the last two parameters because I'm anal-retentive and I like the types to be of descending size.

The system needs refactored, anyway, I believe; we currently do not query the collision system for any kind of sprite data (which I believe is okay for now because, as I recall, the bbox_ values only change when the sprite_index changes, not the image_index).

Moreover, the sprite editor doesn't support editing anything on a per-subimage basis, meaning polygon masks created by the user cannot currently be animated. And to top it all off, the mask system is very poorly integrated. So, some more planning is required at this phase.

That said, anything else you want to add to that function, speak now.

I might also point out that ENIGMA has had pixel-perfect collisions in the past, so it's not that difficult; I just don't want another clusterfuck.

Issues Help Desk / Re: Unable to load library 'compileEGMf'
« on: October 09, 2012, 11:13:14 AM »
And that same "<Java path>\java.exe" -version says that it is 32-bit?

Does the library compileEGMf.dll exist in the ENIGMA directory?

Maybe it would help if you paste the scrollback from running LGM in the terminal (or from ENIGMA.exe) either here or on Pastebin, so we can see what is happening.

Issues Help Desk / Re: Unable to load library 'compileEGMf'
« on: October 08, 2012, 09:00:23 PM »
I should probably modify ENIGMA.exe to attempt to launch Java from Program Files (x86) before it tries to launch from Program Files. In the meantime, you can launch LGM explicitly from a command prompt by calling the correct Java install.

The command should be something like "C:\Program Files (x86)\Java\java.exe" lgm16b4.jar. Not sure of the name of the Java folder.

Issues Help Desk / Re: New to enigma, most of the examples won't work
« on: October 08, 2012, 08:37:03 AM »
Fixed in 15b7ff4.

Issues Help Desk / Re: Help me run ENIGMA on Ubuntu
« on: October 07, 2012, 08:07:46 PM »
Fascinating. Thanks for the report, forthevin. When I have some free time I will download Squeeze and try to reproduce this myself (The code you pasted alone does not give enough information). I will need to narrow a test case to figure out why this is happening. It is clear now that it is a problem with the preprocessor, which explains why the preprocessed engine files those two sent me did not exhibit the error.

From the location information you sent me, it seems that the map of macro names becomes corrupt, or the macro itself is read improperly. The position in the line, given by pos - lcpp->lpos, is 68, which is past the end of the line. You may have noticed that. That should not technically be a problem, as that value is only used for the purpose of error reporting, but...

Anyway, like I said, on this end, I can't seem to agitate it. It would help if I knew the value of macro. For that matter, it might also help if lcpp->macros.find(macro)==lcpp->macros.end()? zero : one were on a separate line, as I can only assume that it's that lookup which is fucking up.

Anyway, I'll get on that soon (can't until after midterms and homework are over this week). Thanks again for the information, forthevin.

Proposals / Re: Collision shape options
« on: October 07, 2012, 07:40:18 PM »
Since it returns void*, get_collision_mask would only be for one subimage (the actual array is void**).

The other function, free_collision_mask, would only be for use on game termination for the purposes of cleaning up. It should actually return void, not void*. It would just cast the (void*) to the appropriate collision-system-specific structure and delete it. For example,

Code: (C++) [Select]
void free_collision_mask(void* mask) {
  delete (polygon_mesh*)mask;

Note that it might not necessarily be a single class type, but the point is that the collision_data is a black box that only the selected collision system need understand. So it must handle allocation and freeing in addition to the actual checking.

Issues Help Desk / Re: Unable to load library 'compileEGMf'
« on: October 07, 2012, 07:37:24 PM »
Assuming that the DLL was successfully built:  It is very likely that you are using a 64bit JRE, but ENIGMA has been compiled 32bit. It'd be easier just to install the 32-bit JRE from Oracle's website and use it when running ENIGMA.

Running java -version will print that information.

Instead, I can instruct you on building a 64-bit ENIGMA DLL (It will require MinGW64, but you will want to configure ENIGMA to use MinGW32 instead). It'd be more work, but you wouldn't need the 32-bit Java.

Maybe I can coax HaRRi or polygone into writing up a how-to on the Wiki...

Announcements / Re: Break In
« on: October 07, 2012, 07:34:10 PM »
The pages were removed by the host. They all belonged to the root user; none of them really had a nonprivileged ID attached.

By all means, feel free to change your passwords; I'm not going to because I seriously doubt it will be compromised (especially by anyone that would actually care to do so).

Proposals / Re: Collision shape options
« on: October 06, 2012, 12:04:16 PM »
In principle, I'm fine with that. My concern is keeping the IDs straight. As such, I think it best to define the above as enum constants in collisions_mandatory.h.
Code: (C++) [Select]
enum collision_type {

This way, if a collision system offers some other, more obscure shape, it can be added without confusing other systems.

We'll also need to define void *get_collision_mask(sprite* spr, collision_type ct) to fetch a collision mask from the system, and void *free_collision_mask(void* mask) to set the colldata values in spritestruct.h.

Issues Help Desk / Re: Help me run ENIGMA on Ubuntu
« on: October 06, 2012, 09:52:42 AM »
I would think the link errors would be reported along with the segfault notification if that were the case, but it may be. Usually GlibC is good about reporting runtime link problems.

Announcements / Break In
« on: October 02, 2012, 11:07:10 AM »
I believe it is my legal obligation to inform everyone we've had a break-in. Presumably by a bot.

At 2PM yesterday I received a report that malware was being hosted on our server and that it was likely we had been compromised. In fact, it appears that some entity had gained root access to our server and loaded a phishing page up on it. The files all belonged to the root account, which means that the entity had full access to our system; this includes databases.

I don't think anyone should be overly concerned, as all passwords are handled by SMF and are therefore salted and hashed.

We are unsure how the break-in occurred, but we believe it may have been related to an old wordpress install hosted elsewhere on this server. From this point forward, no one say "Wordpress" to me.

So, in an effort to uphold due dilligence, etc, this is your warning that it is possible (but unlikely) that someone has a copy of all salted password hashes. It is also possible they have a large list of email addresses. It is also possible (if extremely unlikely) that they can retrieve your password by allocating their presumably large network of bots to brute forcing the hashes. I wouldn't worry about that happening.

Most people don't use very powerful passwords over http, anyway.

So, this is your heads up. Sorry about the shitty news. We're wiping old shit we don't maintain and putting more security in place to prevent this from happening again.