Perpetual Temporal Flux Bug Report / Feature Suggestion Thread

[Mauron]

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.

[Agent 12]

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

[Belaith]

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.

[Geiger]

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.

[Belaith]

Thanks. Luckily, there's a library up the road from my house.

[swolchok]

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

[Geiger]

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.

[alfadorredux]

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.

[Zakyrus]

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

[Mauron]

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.

[Zakyrus]

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

[Mauron]

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.

[Zakyrus]

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

[Mauron]

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.

[Zakyrus]

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