Chrono Compendium

Kajar Laboratories - Fan Works and Submissions => Chrono Trigger Modification => Topic started by: Geiger on February 03, 2007, 10:43:42 pm

Title: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on February 03, 2007, 10:43:42 pm
If you have a specific problem or would like to see a particular feature implemented, post the specific details here.

For bugs, be as detailed as possible with version number and step-by-step instructions to recreate your bug (preferably from the unaltered ROM).  But please make sure your instructions do not have a bunch of extra steps that are not needed for your bug to show up.  For example, if your problem appears when editing events, please check on all those map editing steps as I doubt they are needed.  Spending a little of your time to help narrow down the problem saves me and my team a lot of debugging time.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on February 03, 2007, 11:56:23 pm
Here's the OW exit issue I described in this topic (http://www.chronocompendium.com/Forums/index.php?topic=3768.0).

In TF 2.55 & with a brand new ROM.

1. Open Window Menu>Overworlds
2. Change the Overworld number to 6 (Last Village)
3. Click the convenient exits button :) (under the map number) or go to Window Menu>Overworlds>Overworld>Exits.
4. Change the X destination of exit 0 (is 1AC North Cape in the default game) from 8 to 9 (for this example, just change it by one integer).
5. Save and load up the CT ROM.
6. In the Prehistoric, Last Village, and Future Overworlds you can't land the Epoch (the animations and game freeze while the music continues playing)

I hope this is specific enough and it helps! ;)

-------------
One other thing, would it be possible to have a timer display with a countdown? Like in FF6 where you must escape the floating continent. I know a countdown can be made with events, but it can't be displayed without using the textboxes. It could be some kind of command that passes an integer (seconds) to a timer function then have it display on the screen.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on February 05, 2007, 10:09:04 am
I hope this is specific enough and it helps!

Yes, it is and it does.

Found the problem.  Apparently, I changed the code for the NLZ data to use the full address, but did not change the address it was being compared against to match.  This means Flux will save NLZ data even when no patch is applied.  The reason this only kills certain Overworlds is because those are the OWs that normally have no NLZ.

I have fixed the problem in my code.  The short term workaround is to enable either of the NLZ patches.

One other thing, would it be possible to have a timer display with a countdown?

Not without an ASM hack of some sort.  Probably a fairly significant one also.  I had been thinking of something similar as of late, but I really do not have the time to make such a hack, ATM.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: DarknessSavior on February 15, 2007, 11:17:27 am
I've actually been working on a Chrono Trigger hack for quite some time now, but I was never able to use Temporal Flux.

I'm running Windows ME, is there a way to get the Microsoft .NET stuff installed on ME so I can use stuff like Temporal Flux?

~DS
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on February 16, 2007, 09:56:46 am
I'm running Windows ME, is there a way to get the Microsoft .NET stuff installed on ME so I can use stuff like Temporal Flux?

It should be available through Windows Update.  You can also try downloading it from here (http://www.microsoft.com/downloads/details.aspx?familyid=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en), though its better to get it from WU since it will be keyed specifically to your OS version and language.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: DarknessSavior on February 17, 2007, 01:46:47 pm
Unfortunately, I don't have the internet at home, so I can't use Windows Update.

I've tried downloading it before, but one more shot couldn't hurt, I guess. I don't think that Microsoft even has any updates for ME anymore, since they stopped supporting it. >.<

~DS
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on February 19, 2007, 12:03:25 am
I've tried downloading it before, but one more shot couldn't hurt, I guess. I don't think that Microsoft even has any updates for ME anymore, since they stopped supporting it.

The link I gave you says it supports ME.

Framework 3.0 does not though.  Nor does XNA.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: DarknessSavior on February 22, 2007, 09:18:10 am
Well, I wound up having to download a whole bunch of extra stuff too. The Framework requires IE 5.0 or higher (I downloaded an' installed 5.5 just fine), and Windows Installer 2.0.

The problem is, when I go to install Windows Installer 2.0, it says that feature is already installed. But, when I go to install the .net Framework, it says that I DON'T have it. O.o

Should I attempt to uninstall the current version of Windows Installer? I don't even think that's possible, at least from the Add/Remove Programs menu.

~DS
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on February 22, 2007, 09:46:46 am
Not really sure what to tell you at this point. Search for a file called MSI.DLL.  The file version will tell you which Windows Installer version is on your computer.  WinME comes with 1.2, if memory serves.

You might want to make sure you have the proper version also, as WI does not have a unified installer.  Here's the Win9x (http://www.microsoft.com/downloads/details.aspx?familyid=CEBBACD8-C094-4255-B702-DE3BB768148F&displaylang=en#filelist) version.

Beyond that, my only suggestion would be to spend some money and locate a copy of WinXP or Vista.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on March 08, 2007, 02:22:50 pm
Could you possibly code the music data (which song plays when in that loc.) to be saved with the location data?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on March 09, 2007, 03:27:22 pm
Could you possibly code the music data (which song plays when in that loc.) to be saved with the location data?

It should already do this.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on March 12, 2007, 11:24:24 pm
Could you possibly code the music data (which song plays when in that loc.) to be saved with the location data?

It should already do this.

---T.Geiger

Let me rephrase this. Is there any way you could code the music to be exported with the location export?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on March 28, 2007, 07:29:57 pm
Just to let you guys know, if you're upgrading to vista and you use Temporal Flux.....

It works!

so yes TF is Vista ready. :D
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on April 02, 2007, 11:13:57 am
so yes TF is Vista ready.

Since Flux is written to the .NET Framework, I would expect the program to work fine on any system that supports the framework version I use (which was 2.0 for the last release).  If I understand the documentation correctly, it should even run as native 64 bit code without me having to recompile or jump through hoops.

Never did hear from anyone if Flux now works on Macs since Mono started supporting the Forms library.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on April 03, 2007, 09:23:46 am
Vista does have .NET framework 3.0, when you install it, which can be downloaded for Windows XP as well. So no extra downloads for vista users. unless you get the cheepo starter version, but i dunno about home basic.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on April 04, 2007, 11:40:20 am
Bugs:
In the event editor:
Command, "Goto" cannot jump from say [9310] to [7326]. There seems to be some kind of bug where the Goto command cannot go up a certain hight.

When editing alot of map files, some of the maps would get overwritten. Also, when editing strings (especially when editing ones where a string index uses multiple locations) and sometimes the strings would get overwritten eleswhere. I know that I am nowhere near using the 2 megs that an expanded ROM has.


Suggestions:
Be able to change the instruments to a particular music track by using events? (I know they are not compressed values)

Operands: Be able to have multiply and divide operands for if statements and mem-val stuff? (this could be an "eventually" feature)

Interface/GUI:
Be able to have any extra tabs that you open automatically be opened for you when you load TF the next time.
Example; You load TF, open up the string editor, do whatever editing you are doing, then save and exit TF. The next time TF is run, it would automatically open the string editor. (this "state restoration" could be easily implemented using some kind of config file, and have some kind of Misc Options control panel that would be able to toggle state restoration on/off.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on April 04, 2007, 05:54:22 pm
In the event editor: Command, "Goto" cannot jump from say [9310] to [7326]. There seems to be some kind of bug where the Goto command cannot go up a certain hight.

This is a game limitation.  Goto uses 8 bit addressing, providing for a maximum range of 0x0100.  There should probably be a write-time warning that tells you this, like with bad labels.

When editing alot of map files, some of the maps would get overwritten. Also, when editing strings (especially when editing ones where a string index uses multiple locations) and sometimes the strings would get overwritten eleswhere. I know that I am nowhere near using the 2 megs that an expanded ROM has.

Examples please.

Be able to change the instruments to a particular music track by using events?

As much as I would like to be able to do this, my current understanding is that this is simply not possible without a significant hack, as all song data is uploaded to the Audio RAM at the same time and there are no event commands that can edit ARAM.

state restoration

This has been on the todo list since before v1.00 came out.  It always gets shifted for more significant features.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on April 04, 2007, 06:01:07 pm
OK. How about monster stats? Such as HP, attack, EXP and such?

Edit: Never mind. This has been answered.

Oh, as for maps. I edited many map files and then other map files would dissapear or become corrupted. Enhasa is completely gone after spending 2 hours doubling the size of it.


(http://img118.imageshack.us/img118/7373/enhasabadxb7.th.png) (http://img118.imageshack.us/my.php?image=enhasabadxb7.png)

The same goes with strings. I will expand the dialouge by adding alot of strings and strings in other locations will become corrupted.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on April 05, 2007, 09:00:43 am
Okay, that tells me nothing.  'Something goes wrong sometimes' does not even come close to helping me diagnose the problem.  What are you doing to reach this point?

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on April 05, 2007, 10:00:10 pm
OK. Seeing as I know this is going to happen again. I'll just take notes of everything I modify. Then post here.

Will the ability to dynamically change monster stats ever be considered a feature? And I don't mean have a seperate stat for each individual monster -- no, that would be ludicrous. Instead, just change the stat for the entire monster type, until that memory value is changed to something else. Sort of like a value to mem command.

Also, not be pushy in any way but you have never answered me on the possibility to expand/shrink dialouge boxes. Will this ever be considered?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on April 10, 2007, 09:32:25 am
Will the ability to dynamically change monster stats ever be considered a feature? And I don't mean have a seperate stat for each individual monster -- no, that would be ludicrous. Instead, just change the stat for the entire monster type, until that memory value is changed to something else.

If you mean just change the monster number, you can already do that with self-modifying code.  Its a bit tricky to maintain, but you just need to point a memory command into the event space.  You should be warned though that the game typically freezes around the eighth sprite load or so after it runs off the edge of VRAM.

expand/shrink dialouge boxes. Will this ever be considered?

Unlikely.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on April 10, 2007, 01:56:07 pm
So you're saying that with events I could say for examle, have Sir Krawlie's HP changed to some other value and this would change every Sir Krawlie monster's HP to that value?

Would this work for all of their stats including the item they drop/have charmed? That would be awesome to be able to combine with a random number generator, then we could have random item drops inside the battle. Just like FF6. It couldn't possibly be that hard to do.

If not, I already have events that randomly generate an item after the battle ends.

Also, what did you think of my idea to make a "*entire loc" exports catagory at the top of list when chosing to export/import TF export files? "*Entire Loc" being (map, event, treasure, music) all in one export file. That would be almost as good, if not better than batch import.... probably easier to implement too. What do you think of this?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on April 11, 2007, 12:24:41 pm
So you're saying that with events I could say for examle, have Sir Krawlie's HP changed to some other value and this would change every Sir Krawlie monster's HP to that value?

No, I was saying you could alter the sprite loaded while events are running without using if statements.

Also, what did you think of my idea to make a "*entire loc" exports catagory at the top of list when chosing to export/import TF export files?

It was something I considered for v2.00, but was scrapped for some reason that no longer comes to mind.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Chrono'99 on April 12, 2007, 05:43:33 am
Could there be an option to automatically back up the former ROM when you save the current ROM? i.e. when you save the changes made to a ROM, the former state of the ROM would be copied to a file suffixed with the date (for instance Chronotrigger-2007-04-12-10-40.smc).

This way there would be a backup for every saved modification; this would be useful to prevent corruption, or to investigate said corruption if there is a need to "go back" and see what modifications were made.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on April 14, 2007, 10:06:08 am
Could there be an option to automatically back up the former ROM when you save the current ROM? i.e. when you save the changes made to a ROM, the former state of the ROM would be copied to a file suffixed with the date (for instance Chronotrigger-2007-04-12-10-40.smc).

This way there would be a backup for every saved modification; this would be useful to prevent corruption, or to investigate said corruption if there is a need to "go back" and see what modifications were made.

If this is done, would it be possible for this to be toggle-able in some kind of options window or something? Nice, but I probably wouldn't use it -- I use exports to backup (One location is easier to watch for corruption than say a whole ROM)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Chrono'99 on April 15, 2007, 10:10:26 am
Yeah it would have to be an option, since it would get out of hand else if one saves changes a lot and a lot.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on May 27, 2007, 07:52:22 pm
Uh, how bout the ability to duplicate and repoint every bit of data in the game... I just found that CT works in SNES9X if you Lunar Expand the ROM to 8MEG 64mbit HiROM....

Twice as much everything would solve everyones' problem of running out of space and it could be cool....
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Vehek on May 27, 2007, 08:15:23 pm
How about bringing back the ability to use enemies FB-FF?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JLukas on May 28, 2007, 07:08:53 am
I believe $FF is the "enemy not used" flag and won't be able to be used.  $FB-FE should be possible, though.  I'm guessing some special routines used for Magus battles are causing the problem.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on May 29, 2007, 09:30:38 am
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
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JCE3000GT on May 29, 2007, 10:39:46 am
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. 
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Kyronea on May 29, 2007, 10:46:44 am
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.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JCE3000GT on May 29, 2007, 10:50:24 am
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. 
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Kyronea on May 29, 2007, 11:12:25 am
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.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on June 05, 2007, 01:55:09 am
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)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on August 17, 2007, 11:13:57 pm
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?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on August 17, 2007, 11:36:51 pm
I'll have to agree with that 8 MB+...They have no clue how much stuff people would put into a hack >_>
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on August 20, 2007, 12:23:44 pm
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 (http://www.chronocompendium.com/Forums/index.php/topic,3837.msg74345.html#msg74345), 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
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on August 21, 2007, 10:23:00 am
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.

Quote
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...

Quote
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.

(http://img504.imageshack.us/img504/6530/ctloc070vu4.th.png) (http://img504.imageshack.us/my.php?image=ctloc070vu4.png)

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.

Quote
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.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on August 22, 2007, 11:25:49 am
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
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Kyronea on August 23, 2007, 10:41:03 am
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?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on August 29, 2007, 12:02:35 am
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

(http://img187.imageshack.us/img187/1750/tf1db8.gif)

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

(http://img254.imageshack.us/img254/208/tf2ly5.gif)

as you see, putting it back kinda miss leads you, though when you have that if statement in there, that statement still works.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on August 29, 2007, 09:15:35 am
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
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Eythan on September 29, 2007, 07:49:41 pm
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.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: ZeaLitY on September 29, 2007, 07:54:48 pm
It's edited in individual location events now.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on October 11, 2007, 07:27:59 pm
Idk if this was said before but I just encountered an annoying bug in TF.

If you export events and then alter something, then save in TF, TF errors and closes.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JLukas on October 15, 2007, 04:54:18 pm
I have not been able to reproduce this.  What are you exporting?  What are you changing afterwards?  What error message are you receiving?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on October 15, 2007, 06:24:21 pm
I was exporting the events for Gato's Exhibit {6F}.  If I change ANYTHING after I do that, TF errors.  I can't recall the error.

PS: That's weird...It's not doing it anymore O_o.  I'll see if I can reproduce it.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on October 16, 2007, 03:33:35 pm
Mmk..I don't know whether it was my rom that was going psychotic or TF, but it seems I can't get the error to happen anymore.  Pretty strange.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on October 27, 2007, 10:42:35 pm
I got this error just now while opening a copy of my hack in TF... Justin3009 said he had this error 6 times already.

(http://img89.imageshack.us/img89/1731/wtf2wb6.png)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on October 28, 2007, 01:39:12 am
I really don't know what causes it.  I was graphics hacking Crono a bit, saved, loaded it up in CT, and BAM!  there it was.  SO i went back to my other rom, opened up gato and changed him to someone else and BAM it happened again.  It's a really random error for me, just simple things can set it off.  I think TF just hates certain people >_>
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on October 28, 2007, 01:40:44 am
Came to find out, as justin looked at my rom, My 1000 AD map was corrupted and killeded. ;) yes killeded
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on October 28, 2007, 11:33:35 am
But what doesn't make sense is, I copied and pasted all overworld data from a fresh rom into your rom and it still didn't work.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on October 29, 2007, 09:28:16 am
Can you mail me an IPS of your ROM please?

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on October 29, 2007, 11:33:49 am
I think he fixed it, but I htink I remember him saying something about it happening again after editing 1000 AD
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on October 29, 2007, 03:47:45 pm
Yeah, I'm already past the point where i was on the rom that got corrupted. Gonna back up the rom today, and work on it some more soon.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: glyth on November 01, 2007, 09:13:52 pm
chrono trigger has a few not used  chars  cant you add them so we can edit them ? maybie make one schala 
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: ZeaLitY on November 01, 2007, 11:35:30 pm
CT has no unused character slots.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: glyth on November 02, 2007, 12:46:54 am
it does to dude i u.g.ed it and gave my self two chronos then the one main one but there hp was permently 0

its funny cuz FF3 had ununsed ones to

http://img529.imageshack.us/my.php?image=3extrascw0.jpg

theres 3 of em

theres alot of extra chronos 0.0 and one robo
so if some one could make TF edit 128 char slots
we could add alot of extra chars to our edited roms 0.0
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on November 02, 2007, 08:51:35 am
Glyth, -sigh-...They are character slots not CHARACTERS.  Vehek, Chrono'99, and I tried getting the 8th character in, and we could not accomplish that.  It's ALOT harder then your little mind could believe.  Here, I'll find the link.

Edit: http://www.chronocompendium.com/Forums/index.php/topic,4100.0.html - If you don't understand the mechanics of the game, then I wouldn't post anything saying that you can do this and that.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: glyth on November 02, 2007, 06:55:29 pm
Glyth, -sigh-...They are character slots not CHARACTERS.  Vehek, Chrono'99, and I tried getting the 8th character in, and we could not accomplish that.  It's ALOT harder then your little mind could believe.  Here, I'll find the link.

Edit: http://www.chronocompendium.com/Forums/index.php/topic,4100.0.html - If you don't understand the mechanics of the game, then I wouldn't post anything saying that you can do this and that.

you tryed it how you tryed editig it  by a temp flux ? or companion? aslo is chrono trigger editor compainion open source  i tryed to edit it  becuz it looked like it had a source but i coulent edit char panel 0.0
wish tweaker was open source 0.0
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on November 03, 2007, 12:19:21 am
No, used Translhextion.  Hex Editing is basically the only way to get that working..
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on November 03, 2007, 02:08:31 am
It could be possible with ASM hacking. But since i know nothing about it yet. I can't tell.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on January 10, 2008, 04:46:26 pm
I think the last time I mentioned anything about Temporal Flux was back in September.

A major problem with text compression has been discovered where the Japanese Unicode values overlap the temporary values used during compression.  The affected characters will be multipli-compressed, changing their final value entirely.  This defect will require a complete re-engineering of the text compression code.  This will add several days onto our release schedule as the new code is implemented and bug-tested.

Wanted to let you guys know that we have been working on it feverishly and still hope to release the next version (2.75) soon.  We are deep in Beta (working on Beta 15 as I type), and trying to work out all the bugs.

---T.Geiger
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on January 10, 2008, 06:15:27 pm
^^  Good to know it's still being worked on.  Take your time, it's best to wait =]
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: jirbytaylor on January 29, 2008, 08:30:48 pm
A good feature would be being able to select and drag events/exits with the mouse. It's tricky to find the exit you're looking for by scrolling through a list.
Eh. I'm a newb when it comes to rom hacking. o.o;

Do I have to de-expand my rom to save in game? After expanding it to use a CT Shop editor, save games vanish after closing the menu.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on January 29, 2008, 09:40:31 pm
Do I have to de-expand my rom to save in game? After expanding it to use a CT Shop editor, save games vanish after closing the menu.

Expanding a ROM has nothing to do with using another editor.  I'd suggest posting another thread on this issue to ask other users for help.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Mauron on January 29, 2008, 09:59:33 pm
How difficult would it be to allow editing the special character names and values, or adding our own?

I may need to move the location of the helmet symbol for an edit I'm making, and there's some blank space that may be usable in that font location for other customization.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on January 30, 2008, 05:24:37 pm
Just so you know, there's a crapload of empty space if you delete the excess japanese symbols in the menu font.  That itself gives about 10-20 free spaces for w/e you want.  Plus the extra space below the actual symbols which is another 30 or so.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on February 22, 2008, 09:03:27 pm
Here's a few things for the next TemporalFlux:

Location "TBD" names

1A0 "Ocean Palace TBD" == "Ocean Palace Lift Gauntlet" - maybe...


Minor Issues:
In vers. 2.75
{instant full break} & {instant page break} now create a empty box after the break in which the user must press a button to continue.



Comments:
--------
Also, I REALLY like the new textbox formatting system. There have only been a few cases where I had to manually re-edit the string and move the {line break}. Thanks.  8)

Also, thanks a million for the "Swap Tiles" feature for editing tile maps!  :)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JLukas on February 23, 2008, 06:41:11 am
{instant full break} & {instant page break} now create a empty box after the break in which the user must press a button to continue.

Those commands are designed to display more text afterwards.  If your goal is to have the textbox close automatically once it is finished, use a Delay 00.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on February 23, 2008, 12:41:25 pm
{instant full break} & {instant page break} now create a empty box after the break in which the user must press a button to continue.

Those commands are designed to display more text afterwards.  If your goal is to have the textbox close automatically once it is finished, use a Delay 00.

Like this: {delay 00}?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JLukas on February 23, 2008, 05:46:01 pm
yes, although it's recommended you place a second delay command before that so the textbox doesn't close too quickly for the player to read.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on February 23, 2008, 05:51:08 pm
...it's recommended you place a second delay command before that so the textbox doesn't close too quickly for the player to read.

Ok, I kindof figured that part. Thanks.  :)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Vehek on March 30, 2008, 03:10:58 am
Major problem.
When I was trying to compress some graphics using Temporal Flux, it wrote data after the point it said the compressed data would end.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JLukas on March 30, 2008, 11:58:49 am
It looks like some extra(?) data is being written for packets where the compressed size > decompressed size.  I'll check if it's actually part of the packet, or TF reporting the wrong end range.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Vehek on April 04, 2008, 07:41:27 pm
Any idea what's going on yet? When I reported the problem, I had also gotten it with recompressing some packets originally in the game.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: JLukas on April 05, 2008, 07:04:30 am
You should be safe with the range TF reports, the extra data is just repeating junk from what I can determine.  Just add the packets one right after the other, but leave some extra room after the final one so it doesn't overwrite what's after that section of free space.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: ZeaLitY on April 07, 2008, 12:10:14 am
Copy pasting from GameFAQs:

Quote
I'm curious about this. I've started editing a rom of this game, and just for a trial, I renamed Cyclone(Crono's first tech) Aero Blade, nothing for keeps as of yet. Now, when I tested this, the "Blade" was cut out of the message "Crono learned Aero Blade!", making it just say "Crono learned Aero!"
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Anacalius on April 07, 2008, 02:02:49 am
Copy pasting from GameFAQs:

Quote
I'm curious about this. I've started editing a rom of this game, and just for a trial, I renamed Cyclone(Crono's first tech) Aero Blade, nothing for keeps as of yet. Now, when I tested this, the "Blade" was cut out of the message "Crono learned Aero Blade!", making it just say "Crono learned Aero!"

Really? What on earth could cause that?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on April 07, 2008, 08:55:33 am
O_o....I've never seen/had/heard of that error before...
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Anacalius on April 07, 2008, 12:19:10 pm
Perhaps it's in one of the older versions of Flux?

Actually, I'm going to try it tonight, when I get home from work, I gotta see what's up with it now.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Chrono'99 on June 21, 2008, 01:04:34 pm
Copy pasting from GameFAQs:

Quote
I'm curious about this. I've started editing a rom of this game, and just for a trial, I renamed Cyclone(Crono's first tech) Aero Blade, nothing for keeps as of yet. Now, when I tested this, the "Blade" was cut out of the message "Crono learned Aero Blade!", making it just say "Crono learned Aero!"

Really? What on earth could cause that?

There are two "space" characters. You can guess them by looking at the hexadecimal text column in the string menu in TF. One of the spaces causes this bug and the other is okay. I'm not sure but I think it was fixed in the most recent version of TF.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on July 02, 2008, 05:57:07 pm
You should be safe with the range TF reports, the extra data is just repeating junk from what I can determine.  Just add the packets one right after the other, but leave some extra room after the final one so it doesn't overwrite what's after that section of free space.

Just wanted to confirm this.  I finally got some time to look into the issue.  For reasons too technical to get into right now, the extra "data" is really just junk that you can freely ignore.  The reported range in Flux is correct.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Nerd42 on July 09, 2008, 12:32:50 pm
Hey how do I use temporal flux to edit what happens first, where the party begins and so forth?

and i guess a feature request would be a way to create a blank / template rom to use temporal flux on for new projects
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Shinrin on July 16, 2008, 06:57:57 pm
Just like to point out, while messing with a CT Pre-release song, that Instruments are not marked right in TF for the pre-release.

I was just checking to see if the Pre-Release battle 1 song had any extra instruments in it. but it doesn't but some are miss marked. Because I imported it into CT:R and wanted to make sure it played right.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Mauron on July 17, 2008, 11:20:57 am
Hey how do I use temporal flux to edit what happens first, where the party begins and so forth?
Either modify the location events for location {000} Load Screen, or go to File -> Patches -> Startup Location and then change the Startup Location under Window -> Misc Settings.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Azure on July 20, 2008, 02:20:31 pm
So...  I seem to have an issue >.>

I have TemporalFlux downloaded.  Also, I downloaded .net 3.0 and enabled it.  I really want to start helping CT+ with mapping, but I can't get TF working.  Please help.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on July 21, 2008, 09:15:06 am
Please help.

Individual tech support should be handled in a different thread.  This thread is specifically for reporting bugs and suggesting features.  Which is to say, stuff I need to write code for.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Azure on July 21, 2008, 11:16:30 am
I couldn't find another thread looking remotly like what I needed, sorry.  Where should I go for said help?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on July 23, 2008, 09:10:33 am
Just post a new thread here in Kajar.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on August 14, 2008, 05:15:53 pm
Could you add a display/text field in the treasure chest editor? One that it displays which memory address is used by the treasure being placed/edited. This may be useful for various purposes.

Edit:

I know I ask alot, could you add Layer mode(s) for the location map editor that shows only the "Sprite Over L1" & "Sprite Over L2" properties. (Simular to that of the Solidity, Battle Solidity, or Z-Plane layer modes) It's really irritating to have to right-click each individual tile to see those respective properties to make sure that they will layer over/under the Sprites accordingly. This feature shouldn't take too terribly long to code and it would save us mappers hours of annoyance.

Thanks a million.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on October 25, 2008, 06:50:15 pm
Not sure, but a suggestion I'd like to see in use is have the Dialogue in Temporal Flux have a different colored background if possible.  The dialogue blends in so well that it's sometimes incredibly hard to find what you're looking for.  Having a separate colored background would make it an easy find.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Chrono'99 on December 07, 2008, 05:43:39 am
In TF 3.0, if you put a Destination command in a location event and have "Onto Tile = False" and "Onto Object = False", it will still display "Destination(OnTile, OnObj)". And if you put the command and have one of the two values True (or both), TF will crash with this message:

Code: [Select]
System.OverflowException: Value was either too large or too small for an unsigned byte.
   at System.Decimal.ToByte(Decimal value)
   at System.Decimal.op_Explicit(Decimal value)
   at Temporal_Flux.LocEventEditorForm.OnUpdateCommand(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnClick(EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Chrono'99 on December 09, 2008, 04:18:37 am
If you click on a heading in the Strings window to sort the Location names by "String", "Length" or "Compressed", the order of the location names will also change in the OW Exit menu, but not their actual values, which makes OW Exit selection difficult.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Agent 12 on December 11, 2008, 10:25:22 pm
When Clicking on some DrawGeometry Command you get a LogAssert:

Repro:

Open Fresh CT Rom
Open Location Event packet 105
Go to Object 12 Startup/Idle
Click on the DrawGeometry

--JP

Actually this is worse than I thought I can't seem to do any draw geometry commands
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on December 12, 2008, 09:35:41 am
When Clicking on some DrawGeometry Command you get a LogAssert:

Please provide the error message next time.  I don't need the whole stack trace, just the first line will do.

"System.ArgumentOutOfRangeException: Value of '327' is not valid for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'."

Also, line numbers are more helpful than objects/functions.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Vehek on December 27, 2008, 03:08:25 am
Ever since TF 2.75, the Decode all events option doesn't seem to handle dialog correctly. Dialog is either blank or from the event packet Decode all was called from.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on January 06, 2009, 03:52:49 pm
TF 3.0:

File>Import:: Location Exits

Anything you try to import, exit value changes to "0"

~Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Chrono'99 on January 06, 2009, 07:16:06 pm
TF 3.0:

File>Import:: Location Exits

Anything you try to import, exit value changes to "0"

~Z

Doesn't it import ALL exits at once (same for export)?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on January 07, 2009, 09:26:59 am
Doesn't it import ALL exits at once (same for export)?

Yes.  Same for treasure, as they are both Sized By Address record types.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: justin3009 on January 09, 2009, 06:06:45 pm
There's a bug that if you try to do "Epoch (in Party)", it'll automatically make it a return command, but "always" works fine.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Mauron on March 12, 2009, 11:43:33 pm
Would it be possible to add the six letter names patch through the patches option? The reason I ask is because ZeaLitY mentioned elsewhere that the dialogue handler could potentially clip longer lines if the names get extended.

The patch uses the same memory addresses for names, and the relevant routines were all edited without relocating code.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: FaustWolf on March 13, 2009, 12:19:16 am
Speaking of the sixth letter name patch, what's the possibility of doing the same for the seventh letter name patch currently in production?
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on March 13, 2009, 09:19:16 am
Speaking of the sixth letter name patch, what's the possibility of doing the same for the seventh letter name patch currently in production?

While the patches are certainly impressive, its unlikely that I will add any patches that change memory addresses of vital data.  It requires far too much code juggling.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Mauron on March 13, 2009, 04:21:12 pm
Where does that leave the six letter one? Seven needed to relocate the data, but six just used a previously empty byte in the same location.

Edit: Just to be clear, that's an empty byte after each name. We're no longer terminating the strings with a null byte.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Agent 12 on March 18, 2009, 12:38:54 am
Random Number event seems to only work for 7F0200.  If this is by design then the GUI is misleading....or it could be a bug?

--JP
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Belaith on March 18, 2009, 03:16:24 am
I know this is asking way too much but is it possible to write all the features of 3.0 into TF that will successfully run with .NET framework 1.1? If not, that's ok with me.

If it's too much I don't want to have you do anything by special request because I know I'll be the only one using it. I have dial up which makes upgrading virtually impossible.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on March 18, 2009, 10:26:39 am
Where does that leave the six letter one?

Looking at your original concerns, the better way to support it would be to allow the spacing record to be saved without starting a translation project.

is it possible to write all the features of 3.0 into TF that will successfully run with .NET framework 1.1?

Probably not.  I am pretty sure my code uses 2.0 specific items and the docking library almost certainly does.  I also have plans to move to at least 3.0 later this year.

If you really can't upgrade over dialup, I suggest downloading the .NET redistributable at a friends house / school / work / library.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Belaith on March 18, 2009, 07:17:37 pm
Thanks. Luckily, there's a library up the road from my house.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: swolchok on April 11, 2009, 03:38:54 am
Very simple request:

In LocEventEditorForm.DecodeEvents, please call the LocEventTree.BeginUpdate() before you begin adding TreeNodes (probably right after numArray is allocated, before the big if statement (or right inside it)), and call LocEventTree.EndUpdate() after you are done (i.e., at the end of the function, and also right before the return when you check num5 against this.Rec.nDataSize). This should result in a MASSIVE speedup when editing events -- it won't sit there with the scrollbar hopping around while your code populates the event tree. More information is at http://msdn.microsoft.com/en-us/library/system.windows.forms.treeview.beginupdate.aspx . Thanks!

(If only the project was open-source, I would've done this myself and posted a new build...)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Geiger on April 13, 2009, 10:20:14 am
In LocEventEditorForm.DecodeEvents, please call the LocEventTree.BeginUpdate() before you begin adding TreeNodes

The event editors are currently the subject of a major rewrite.  The underpinnings no longer work the same.

Also, as you'll note in the page you linked, BeginUpdate / EndUpdate only provide a speedup when an object is being painted.  At the time an event record decodes to form, it is not even visible, let alone being painted.

But to be sure, I stuck a Begin/End into the archived 3.0x source.  It took a tenth of a second longer to decode to 0x80 forms.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: alfadorredux on April 17, 2009, 09:52:08 pm
Temporal Flux and Mono:

To put it very simply, this combination Does Not Work.  TF crashes on startup with the following error:

Code: [Select]
Unhandled Exception: System.EntryPointNotFoundException: GetCurrentThreadId
  at (wrapper managed-to-native) WeifenLuo.WinFormsUI.Docking.NativeMethods:GetCurrentThreadId ()
  at WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl+LocalWindowsHook.Install () [0x00000]
  at WeifenLuo.WinFormsUI.Docking.DockPanel+FocusManagerImpl..ctor (WeifenLuo.WinFormsUI.Docking.DockPanel dockPanel) [0x00000]
  at (wrapper remoting-invoke-with-check) WeifenLuo.WinFormsUI.Docking.DockPanel/FocusManagerImpl:.ctor (WeifenLuo.WinFormsUI.Docking.DockPanel)
  at WeifenLuo.WinFormsUI.Docking.DockPanel..ctor () [0x00000]
  at (wrapper remoting-invoke-with-check) WeifenLuo.WinFormsUI.Docking.DockPanel:.ctor ()
  at Temporal_Flux.MDIForm.InitializeComponent () [0x00000]
  at Temporal_Flux.MDIForm..ctor () [0x00000]
  at (wrapper remoting-invoke-with-check) Temporal_Flux.MDIForm:.ctor ()
  at Temporal_Flux.MDIForm.Main () [0x00000]

If I get some time over the next few days (which will only happen if the damned migraine goes away), I'll try siccing the Mono Migration Analyzer on TF and see if it can tell me a bit more about what's going on, since I don't need source for that.

I'm running on Linux with Mono 2.4 (latest release), but I wouldn't expect the results to be any better on a Mac.  Anyway, I'm hoping that this will be a simple fix, because I can't expect you to undertake a complicated one for the sake of <5% of the potential hacking population.  ;P

----------------------------------------------------

Okay, update.  I ran TF through the Migration Analyzer, and it looks like there are three separate issues.  The good news is that I think two of them are easy to resolve.  The bad news is that I don't know what to do with the third one.

1. WeifenLuo.WinFormsUI.Docking.dll generated most of the significant errors...but judging from the name of the library and the information that MoMA regurgitated, you're only using this for window docking, right?  And while docking may be a nice-to-have, it isn't a vital function of TF, so the easy fix for the problems here is to use runtime conditionals to deactivate the docking functionality when TF is running under Mono--see the relevant section of http://www.mono-project.com/Guide:_Porting_Winforms_Applications .

2. The main TF executable generates a number of warnings about "void InitializeComponent ()  void Form.set_AutoScaleBaseSize (Size)  Setting this is probably unintentional and can cause Forms to be improperly sized. See http://www.mono-project.com/FAQ:_Winforms#My_forms_are_sized_improperly for details." The information at the end of the link indicates that it's 90% probable that these calls are unnecessary boilerplate added by your IDE and can be safely deleted.

3. And now we get to the one I don't know how to deal with, mostly because I don't have enough information.  What's being flagged are two P/Invoke calls inside GGRLib.dll.  They're both identical--calls to SendMessage(IntPtr, int, int, int) in user32.dll from void EditCell(int, int).  I can't tell from the information available what these calls are doing--actually, I don't even know whether this library is your own, or if you have the source.  If you do, and whatever these calls are doing isn't 100% vital, runtime conditionals are probably the way to go again, since there does not appear to be a managed-code replacement for SendMessage.

Caveat:  I am not a C#/.NET programmer, nor do I play one on TV.  I prefer Java as a general-purpose GUI-coding language, since it runs equally crappily on all platforms. (http://img179.imageshack.us/img179/369/iconalfador.gif)
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on July 23, 2019, 06:11:48 pm
Can we have the extra enemies from this link:
https://www.chronocompendium.com/Forums/index.php?topic=13057.msg230574#msg230574

and the Shops (in Events::SpecialDialog Shops) to go up to 3F from selectable?

EVENT EDITOR:
This *might* require a new Command Type, but can we have one which we can Zero a Memory Address, for example.
ZeroMem(7E299E, TwoBytes)

...or is there a Command(Assignment) that does this with a Variant?

Speaking of which, can we have an expansion that allows the integration of new commands with some CustomData(data would have to be User Defined)?

Thanks.
~Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Mauron on July 27, 2019, 04:36:56 pm
You could definitely assign 0 to an address. Unless you're going to zero more than two bytes at a time, there's not much of a difference between that and assigning zero.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on July 27, 2019, 05:08:20 pm
You could definitely assign 0 to an address. Unless you're going to zero more than two bytes at a time, there's not much of a difference between that and assigning zero.

Ok, right. I put some thought in this and that's two Commands...so...
would it be possible to update the interface to have Custom Command sets, such as
Zero Memory, and it'll quick drop in 2 Commands:: a ByteMath, and Assignment Command in the Event Editor.

The User would have to manually set the parameters and variables of course, However, this would be convenient. ...and yes, this can be done with copy&paste, but it would add another level of User Interactivity to the design.

~Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Mauron on July 27, 2019, 05:58:38 pm
Category: Assignment
Command: Value-to-Mem
Value: 0
Store To: Whatever you want
Width: Whatever you want.

There's no need to use ByteMath to store 0.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on July 27, 2019, 06:57:33 pm
Category: Assignment
Command: Value-to-Mem
Value: 0
Store To: Whatever you want
Width: Whatever you want.

There's no need to use ByteMath to store 0.

Ohhhh.....I could've sworn that it was required to have it from another variable.
I think this is due to the fact that I was learning it off of how SilverPoints worked(which uses a temporary variable).

~Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Mauron on July 27, 2019, 07:18:31 pm
7F0200-7F03FF is used as a temporary working space for most commands, and most (like ByteMath) only have variants that address this space. Assignment needs to work with any part of RAM, so it doesn't have this limitation.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on September 19, 2019, 12:59:37 pm
Feature suggestion: be able to know the hexadecimal address of command in the event editor after hitting the update button.

By the way I know most of us hardly ever hear from  t.Gieger but is there any word on if/when there's going to be any update?

-Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: adjustupvc on February 13, 2020, 10:48:55 am
Great post - thank you!
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on March 14, 2022, 11:49:22 pm
With Strings in the string Editor...

Would be possible to get an update so we can change the String Text via the Compressed String Catagory?

Eg. Change Flame Toss which is A5C5BAC6BEFFB3C8CCCCEF (Compressed) to
*Flame Toss by renaming the Compressed to 2FA5C5BAC6BEFFB3C8CCCC ...?

I know it's almost moot, but some useful for some of us making items with icons ALOT EASIER like {Blade} ...or say, CUSTOM ITEM: CompuParts(97A2C8C6C9CEAFBACBCDCC). 97 being some arbitrary placeholder for a 'computer circuit icon'.


Thank you.

~Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on March 15, 2022, 02:50:51 am
Batch Import of all files in a folder.

Could be useful for lessons in less hair-tearing-out. :)

~Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: Zakyrus on March 29, 2022, 11:48:18 am
TemporalFlux:
Highlights (In TileSelector same for Subtiles, WHICH tile is selected) eg. Tile (0 - 255)


{note}{heart}{infinity} * , etc.  Can we have {Sword}{Blade}, etc.

Example: Found x(number) {itemIconType}(ItemName)!


Exits:
When making a new Exit, have it pull from the list where Previous Exit location was set with a Checkbox.
Example: Exit 2 is 1AC North Cape, making Exit 3 (brand new exit could be set to 1AC automatically)


Be able to TYPE in location list to quick-warp down to selected location.
Example typing in 1AC would auto-scroll list down to 1AC North Cape.


(right-click JUMPTO) point of GOTO, ARBITRARY or OBJECT_FUNCTION -- warps to [XXXX] value of JUMPTO.


~Z
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: PowerPanda on November 07, 2022, 06:52:26 pm
I recently put out a patch called CTSE (Chrono Trigger Soundtrack Expansion) that allows for up to 101 pieces of music (Hex: $65) to be called within Chrono Trigger on an expanded rom. This patch comes with 10 additional pieces of music pre-loaded.
* 5 are SNES recreations of the PSX/DS music (the 4 extra tracks, plus Frog's theme with Intro)
* 4 are unused songs from the JP and JP Pre-release roms, extracted, corrected, and assigned instruments.

Anyway, there are 2 problems we're running into with Temporal Flux:
1. You cannot assign any music above $52 in the editor.
2. If you load a rom with a music track above $52, Temporal Flux will change the value to FF when you save.

So, my request for a feature would be to simply allow the option to assign more music tracks. Either let the list go up to $65, or, if you want to make it dynamic, read the value from C7/0AE9 to show how many track options Temporal Flux should list. The song descriptions can be {blank}, or you could use the following:
$53: CTSE 01 - A Meeting With Destiny
$54: CTSE 02 - One Sunny Day When We Met
$55: CTSE 03 - Scattering Blossoms
$56: CTSE 04 - A Time To Rest -After the Battle-
$57: CTSE 05 - Frog's Theme (With Intro)
$58: CTSE 06 - Keeper's Dome
$59: CTSE 07 - Ascend to the Light
$5A: CTSE 08 - Boss Battle 3
$5B: CTSE 09 - Alarming Crisis

EDIT: I have also coded ASM that allows you to set the random battle music on a map-by-map basis. If edits are already being made, this might be worth adding in too. There is a $200 byte table with 1 byte corresponding to each map.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: ZeaLitY on November 20, 2022, 01:14:44 am
Man, that's kind of a show-stopper. Has anyone reached out to Geiger, recently? I used to communicate via his Gmail. It's worth a shot in case he can output a hotfix.
Title: Re: Perpetual Temporal Flux Bug Report / Feature Suggestion Thread
Post by: trig on November 20, 2022, 04:37:25 pm
He got back to me by email about a year ago, in August; I had asked about a TF 3.x manual. So I should think he is reachable by email.