It's gonna require 15MHz mode like I am for E:SoR if you're thinking about smoothscrolling, but at 8 level, it's just going to be a blur on the screen anyway. Without smoothscrolling, you can certainly achieve that 8 level goodness. I think. Gonna have to get up with Calc84maniac with respect how he does 8 level, should I choose to take on this project as well.

I probably didn't word it well.

What it does is allows you to store pic files into a file so you can recall them later.
Benefits: No fear of users overwriting pic files in case they want to use them, keep all your pic files in one place, and also supports a simple method of compression so if you don't use all the screen space, you can reclaim some of it in the form of a smaller size.
Disadvantages: You need the PicArc program to add/extract images, it takes time to get images out of the file, and one might mistake a database program for something else and really mess it up.
Two of those disadvantages are removed when you use Celtic III, but the first one becomes really exaggerated.

I found this archive on my computer and someone on IRC wants it. So, here it is.

You MUST understand that the archives that are generated by this program are *not* compatible with Celtic III's version of PicArc, though a few modifications to the database can be made to make it compatible. Not sure how well that would work, but it might be something for someone to try.

We discussed masking a while back but I don't think I ever got these masks. What the masks would be used for would be to invert the sprite's colors sort of like how they did it in FF6 when an enemy was about to attack. In E:SoR, we wouldn't need enemy-specific masks if we just blinked the enemy sprite on and off.

On another note, I finished moving the magic names to page 4 and added in a few ... others ... just in case the Full Metal Mode ever made it off the ground. Yes Zera, I'm entertaining the idea of equipping to a robot the "Accelerator" and having it use the program "Nuclear Array". Sounds epic

At the moment, I'm constructing the stuff needed for obtaining the items, especially in case there's a full inventory condition. I'm thinking about how to go about doing that. One thought would be to automatically add in a 33rd slot so you can see what it was you're getting *and* be able to use it if need be (if the item you got is a consumable item) so you stand less of a chance of wasting something. At the moment, the item you're getting would remain unusable until it actually made it to your inventory and just tell players to suck it up if their inventory got too full to make something they wanted usable. (HINT: Keep your inventory open and sell off equipment you're not using)

I have a ton of more flags in mine, but it's a whole different kind of engine. (tactical RPG) There also has to be flags that define the type of movement enemies have. (such as whether or not they can move across objects that obstruct the paths of normal units) Battle sequences are just short action scenes where one or two attacks are exchanged, and the units are brought back to the map screen.

[...]

That kinda reminds me of this old SNES game that I've played a while back. "Bahamut Lagoon" I'm thinking of. I think other games did it that way, too. Except you could choose to either directly engage the enemy or throw attacks on the map itself. It would be interesting if E:PoD supported this feature if, say, there was some dragon on the field and you didn't want to go face-to-face with it at that very moment and bombard it with whatever you've got from afar. Of course, enemies could do the exact same stunt and I guess it wouldn't work over very well if there was a zillion enemies on the field and ...

Nevermind. That kind of thing would work better with parties where you could do things like healing while still being able to attack or something.

Just throwing something out.

Wait so is it a joke or is it real? I hope it's the former. I kinda expected a joke but yeah

And if you change the topic title or a post subject, it will be posted in this topic fine. Posts locations are based on topic IDs, not titles

To make it clear, yeah. It was a joke. I wanted to keep playing with the code nomming because it *really* does taste of cherries!

Also, that's good to know about the whole post topic thingie. Now I won't be afraid to use it more often.

EDIT: Biscuit, rawr.

I believe there may be a big problem with the project.

Since I've put the lobster in the game, it seems to have grown a mind of its own and started pinching away at some of the sprite data. Jealous, I guess. On another note, additional cherry-flavoured dragons has been nomming so much on the code that the backups are ravaged, and the project cannot continue. SubaruZX has not been keeping them in the closet as of late.

I'm sorry. I need some time to boil a few lobsters, reign in the cherry-flavoured dragons and keep them from nomming the cherry-flavoured code. Only then can I rebuild the project, but it won't be pretty. It'll be like it was half a year ago, if I'm lucky.
Poor April Fool's day post! (shows up in IE. lol)

There is _WriteFlashUnsafe...


There is _WriteFlash and WriteFlashUnsafe, and, funnily enough, _WriteAByte and _WriteAByteSafe. Both use fallthrough to prevent writing to the cert. page. (and maybe also the 7x pages in OS space? Iambian?)

The last time I looked at the code, the only restriction (if they have them) that the routines have is the inability to write to the certificate page. Didn't look too hard at the code, tho.

Quote from: Iambian on March 31, 2010, 09:09:03 am

Still wouldn't try it. Wouldn't risk it.

that's unless you got your calculator for like $5, though

That's cruelty to calculators! Bad DJ! Bad bad!

Anyway. There should be no point in manually fixing the groups if they're on-calculator and in Flash. You should try to extract what you can (by reading off memory addresses if you have to) and then rebuild the group later on. Editing Flash is a messy business anyway.