Perpetual Temporal Flux Bug Report / Feature Suggestion Thread

[JCE3000GT]

Twice as much everything would solve everyones' problem of running out of space and it could be cool....

You get diminishing returns when expanding to 64 Mb.  48 Mb gives you roughly 148% of original size.  64 Mb gives you about 173% of original size.  You only get to use about half of the extra space.  Furthermore, since its so cut up with (necessary) mirror data, some packets will not fit in it at all.

To summarize, if you've run out of room with 48 Mb and still have tons of stuff planned, 64 Mbit will not help you at all.  If you can almost fit in 48 Mb and only have a location or two to finish, you would probably be better served by going back over what you have completed and trimming some fat.

I am not saying I will never support 64 Mb, I am just pointing out why its not a priority.

---T.Geiger

Or maybe a better solution for them is to make the one large "64MB" hack into 2 smaller 48MB sizes and just use two ROMs--thus actually increasing the size of their story/game/hack/thing.  I dunno, just thinking outloud--and I just woke up so pardon my reply if it is stupid. 

[Kyronea]

The only problem would be providing a smooth transition, as well as determing a proper cut-off point. While using two ROMs might sound like a good idea at first, it could quickly blossom into a huge mess.

[JCE3000GT]

The only problem would be providing a smooth transition, as well as determing a proper cut-off point. While using two ROMs might sound like a good idea at first, it could quickly blossom into a huge mess.

Actually if you approach it right I think it could be a fantastic idea.  Could you imagine the size of the areas and dungeons just in "Chapter 1"?  Of course, if you've already created more than half of your game it probably would be a nightmare importing part of it, or, if your story at that point doesn't have a cutoff point.  I guess the only way it would realistically work is if you PLAN on using 2 ROMs.  Which for my hack I just might--if I get enough content lol. 

[Kyronea]

Aye, but that's the problem...you'd have to go into it planning to use two ROMs. Frankly, apart from some really huge game attempt, like making a Chrono Trigger style Chrono Cross, I'm not seeing why anyone would need that much space unless they're just adding loads of unnecessary stuff.

[Zakyrus]

Actually if you approach it right I think it could be a fantastic idea.  Could you imagine the size of the areas and dungeons just in "Chapter 1"?  Of course, if you've already created more than half of your game it probably would be a nightmare importing part of it, or, if your story at that point doesn't have a cutoff point.  I guess the only way it would realistically work is if you PLAN on using 2 ROMs.  Which for my hack I just might--if I get enough content lol. 

I thought of this once, good idea, but that depends on what you are doing...

2 ROMs really scews with alot though....

1. you can't make new items for the second ROM (if you go NewGame+ or from the prev ROM you are really screwed here)

2. The second and most important reason I wouldnt go with 2 ROMS is EVERY single memory address would have to be changed... ok not really, but what if you took the Bromide from the Manoria Cathedral in ROM 1, but re-did all the memory values for ROM 2.. you are really screwed here unless you want to remember every single mem-val and keep them in both ROMS...


The ability to 'duplicate' everything wouldn't be used by everyone, it would ensure enough space for new materials.... though this isn't a "please-add-this-feature-or-I'm-gonna die" thing, it's just a suggestion for a VERY later version (since 8MEG ROM support is now finally becoming available - I think it would be nice to consider eventually)

[Zakyrus]

Temporal Flux Manual Update:
Treasure chests *CAN* be on X or Y value of 0, however, if they are on 0, the dialoug box that says "You got X" will not appear, chest will not display "empty!" either. However, you will still receive the item and the sound of a treasure chest opening plays. This could be used for 'hidden items' where most player's wouldn't look!

Oh yes, this is probably already know and obvious, but in the next TF release could we have Temporal Flux open whatever Manual.chm is in the current Dir as TF. That way we can just overwrite any new copies and the program will just load whatever is there. Thanks.


Suggestions for next TF:
Treasure Chests and Exits-
Would it be possible to be able to simply "click" on a treasure chest or exit and automatically select it rather than having to go through the invidiual "Chest/Exit" numbers to select them? This would probably be simple to implement and would collectively save alot of editing time.
Being able to "Drag" Chests or Exits wouldn't be a bad idea either.


"Swap layers" could be cool and save many hours for modders. This would be like Explicit Paste but be able to switch layers in the pasting process. Basically select tiles (to copy them) then hit Swap Layers. The Swap Layers would switch which tiles are layer1 and which is layer2 for the copied tiles. When you paste them, whichever tiles were drawn on layer1 would now be drawn on layer2 and vice versa. (this would be *VERY* useful for Explicit Pasting maps into other ones where the layers are switched.)

 - properties would remain the same of course


8 MEG ROM findings...
I have expanded the Chrono Trigger ROM to 64 Mbit ExHiRom (8 MB).
Here are my current findings:

Temporal Flux appears to work perfectly with this. I have edited various locations and have found no problems whatsoever with normal TF functions such as editing, saving, etc.

SNES9X plays the ROM perfectly, no flaws so far!

However, the only problem with this equation is that ZSNES does not support 8 MB ROMs yet. I asked about this once and they laughed me out of the board saying that 8 MB is way more than anyone would ever need. (I beg to differ - they haven't heard of CT+)

I have yet to go back and spite them that SNES9X has support and they don't. I predict that soon after they find THAT out they'll add 8 MB support rather quick.


So... would it be possible to add a function in Temporal Flux that will expand to 8 MB's? Think of how much could be done/added! There is no reason not to other than ZSNES. (which will hopefully change soon)



Another question... To my understanding Temporal Flux uses the extra space for new strings(and what else, map space?). The question is, if I expand from 6 MB to 8 MB will TF keep adding new data to the space or is it 'hardcoded' to only see 6 MBs?
(yes 2 more MB is ALOT of space for a ROM, but I assure you it will ALL be used)

One more thing on a simular note, I know expanding "more" location pointers/events is an insane request, HOWEVER, would it be possible to say; instead be able to expand EVERY map to 40x40 tiles? I can hack around limited loc. pointers by using "event" conditions (e.g. Check previous location and setup events from there (and use "event object" exits rather than loc. exits) and I can get around "Screen scroll" commands by modding their memory addresses through events. ...but is 2MB enough to increase all the maps to this size?

[justin3009]

I'll have to agree with that 8 MB+...They have no clue how much stuff people would put into a hack >_>

[Geiger]

Would it be possible to be able to simply "click" on a treasure chest or exit and automatically select it rather than having to go through the invidiual "Chest/Exit" numbers to select them?

I have wanted to do this for awhile myself, largely because I use exit chaining to traverse Locations.  It has not happened yet though because there is no "selection" interface in Flux.  Its all copy and paste.  It may happen eventually, but I will have to figure out how I want to add the behavior into the GUI.

Being able to "Drag" Chests or Exits wouldn't be a bad idea either.

This probably won't happen soon, if ever.  Once again, this would require a selection interface.  But beyond that, it would also create an inconsistent GUI behavior since nothing else can be logically dragged so long as I have no layering capability.  Map layers are not really layered, and all the stuff that draws on top of the map is only pseudo-layered.

On a sidenote, I was hoping XNA would finally allow me to get into a layered GUI, but its really been no help at all.  While Microsoft has made some things easier, most stuff is harder if you are approaching it from a pure code standpoint, like one would commonly do with manipulating window elements.  XNA is designed for modern game making and all the tools that would go along with it, which sticks me right back to GDIPlus.  Unfortunately, it took me several frustrating months to reach that conclusion.  The XNA version of Flux is dead in the water.  I will try to get an update to the regular version of Flux out sometime before the end of the year.

Really, I was hoping to get back to the quarterly update scheme I had originally planned.  Stupid outside forces, distracting me and ruining my plans.  :shakes fist:

this would be *VERY* useful for Explicit Pasting maps into other ones where the layers are switched.

I am having a hard time thinking of an example for this.

8 MEG ROM.  Temporal Flux appears to work perfectly with this.

With the first six megs of it, sure. 

Flux is not coded to use any free space past the first six megs, though it will still open and save the rest of the ROM properly.

they laughed me out of the board saying that 8 MB is way more than anyone would ever need.

While I would never make this statement, I have pointed out before that a 64 megabit ROM is not really all that and a bag of chips.  In this very thread, even.

I predict that soon after they find THAT out they'll add 8 MB support rather quick.

I doubt it.  ZSNES and Snes9x share a lot of the same developers, and Snes9x has supported 64 megabit ROMs since antiquity, so its not much of a secret.  Then there's also the fact that none of the developers really seem to bother communicating with one another enough to get stuff done.

Little known fact, I was the official Snes9x Windows developer for about a year.  The same year I got laid off and had to commute 300 miles to my new job.  Yeah, not much got done.  The guy that wound up coding the new official version made a number of questionable design changes (as in, I questioned them, and no one else seemed to care).  If I can even compile the new version (last I checked, I couldn't), I'm not sure I want to update GSD to use the new GUI, despite the emulation improvements.

would it be possible to add a function in Temporal Flux that will expand to 8 MB's?

I have expounded on this before.  Its not a priority.  In theory, though, the SNES could support up to 128 megabit.  Why don't you get the two major emulators to support that if you are going to bother to bug them about it?

would it be possible to expand EVERY map to 40x40 tiles? is 2MB enough to increase all the maps to this size?

If you fill the game with empty 40x40 maps, yes, it is possible.  Once you start putting stuff in them, not so much.  JLukas stress-tested a 48 Mb ROM and ran out of room well before hitting the top.  64 Mb would have a similar, if not identical result (since the packets may not fit into the expanded space at all).

---T.Geiger

[Zakyrus]

On a sidenote, I was hoping XNA would finally allow me to get into a layered GUI, but its really been no help at all.  While Microsoft has made some things easier, most stuff is harder if you are approaching it from a pure code standpoint, like one would commonly do with manipulating window elements.  XNA is designed for modern game making and all the tools that would go along with it, which sticks me right back to GDIPlus.  Unfortunately, it took me several frustrating months to reach that conclusion.  The XNA version of Flux is dead in the water.  I will try to get an update to the regular version of Flux out sometime before the end of the year.

Take your time.

Really, I was hoping to get back to the quarterly update scheme I had originally planned.  Stupid outside forces, distracting me and ruining my plans.  :shakes fist:

I understand only too well...

this would be *VERY* useful for Explicit Pasting maps into other ones where the layers are switched.

I am having a hard time thinking of an example for this.

See how I Explicit pasted part of another map into the lower part Truce Canyon? Is there any way you could add an option so that the tiles in a selected area could be swaped so they change between L1 and L2? Or would hand re tiling the whole space be my only option? I'm trying to have all tiles on the same layers.

If you fill the game with empty 40x40 maps, yes, it is possible.  Once you start putting stuff in them, not so much.  JLukas stress-tested a 48 Mb ROM and ran out of room well before hitting the top.  64 Mb would have a similar, if not identical result (since the packets may not fit into the expanded space at all).

---T.Geiger

That sucks. I'll just see what I have to work with I guess. No matter what we can add to the CT+ hack, I guarentee it'll be fantastic. It's a stress test in it's own way, seeing as most people using TF are going to make a hack from scratch rather than expand.

[Geiger]

Is there any way you could add an option so that the tiles in a selected area could be swaped so they change between L1 and L2? Or would hand re tiling the whole space be my only option?

I have added the capability to swap L1 and L2 to the WIP, but I am still not sure I see where this is useful beyond fringe cases.  You should also be aware that not all maps will 'flatten' nicely.

---T.Geiger

[Kyronea]

Would it be possible for the textbox input box to be set to the exact textual limit of the dialog box so you don't have to "feel it out" when setting up line breaks, page breaks, and so on?

[Shinrin]

Now here's a funny glitch in the editor, If you do a Mem to Mem assignment using 7f01** it will put it in 7f03** (where ** equals the last two digits) example 7f0166 will be 7f0366 and 7f0168 will be 7f0368



the above picture shows it to work right, but now when i try to put it back into that memory location.



as you see, putting it back kinda miss leads you, though when you have that if statement in there, that statement still works.

[Geiger]

Now here's a funny glitch in the editor

Not a glitch.

The assignment you are trying to do here does not have a corresponding event command.  Flux is trying a "best fit" here, and shifting your store address into the 200 range.  There are several commands that work this way.

To accomplish what you are trying there, you will need to do two separate assignment statements.  One from the 7FXXXX range to 7F02XX, and then another from 7F02XX to 7FXXXX.  Check "Event Commands.txt" in the Offsets Guide for more information.

---T.Geiger

[Eythan]

Is it still possible to edit dialogue in the most recent release of Flux? I can't seem to switch to it in the Strings window, it's not one my group options.

[ZeaLitY]

It's edited in individual location events now.