Battleships Forever FAQ
Moderators: th15, Moderators
-
- Ensign
- Posts: 1
- Joined: Mon Mar 31, 2008 4:43 am
-
- Commander
- Posts: 116
- Joined: Sat Mar 01, 2008 3:49 am
- Anna
- The artist formerly known as SilverWingedSeraph
- Posts: 3447
- Joined: Wed Sep 26, 2007 8:51 pm
- Location: Elsewhere
That one's been there for ages. Near as I can tell, it can't be fixed. And GameMaker is retarded. It just can't have multiple undos without stupid complexity.AnnihilatorX wrote:I have already mentioned that as a bug. Hope they will fix that, and maybe introduce multilayer undos. Even MS paint support 3 undos.mtheminja wrote:But be careful, for some reason it sometimes undoes several actions all at once, which can hurt a lot.
Founder and Event Coordinator for the BSF Beauty Pageant. Founder of the Pseudo-Chainship Project. Admin. Games Master.
Quality Control Enforcer
Gay cute girl and fucking proud of it.
Quality Control Enforcer
Gay cute girl and fucking proud of it.
-
- Commander
- Posts: 116
- Joined: Sat Mar 01, 2008 3:49 am
Maybe work around such as using temp files? Sb4 files are unencrypted and automated saving of multiple temporary files may be a workaround without incurring much performance issues in form of undo lag.Anna wrote:That one's been there for ages. Near as I can tell, it can't be fixed. And GameMaker is retarded. It just can't have multiple undos without stupid complexity.AnnihilatorX wrote:I have already mentioned that as a bug. Hope they will fix that, and maybe introduce multilayer undos. Even MS paint support 3 undos.mtheminja wrote:But be careful, for some reason it sometimes undoes several actions all at once, which can hurt a lot.
-
- Commodore
- Posts: 721
- Joined: Mon Jun 30, 2008 7:49 am
- Location: "not here" would probably be accurate
-
- Commander
- Posts: 116
- Joined: Sat Mar 01, 2008 3:49 am
I am sure saving process can be performed in background at a low priority.
How much CPU power does it take to output text files without encryption? I wouldn't think it's going to be a lot.
Coming from another angle, now I don't know the capability of the GM engine. But the following should be doable to any programming language. Before updating the data of a specific section or weapon etc, store the original data as a variable stack of say height of 3. Then you can recall the original data through the stack if needs undoing. The number of undos is limited by the stack height. The only requirement is that each section and weapon has a unique reference ID in the ship maker.
How much CPU power does it take to output text files without encryption? I wouldn't think it's going to be a lot.
Coming from another angle, now I don't know the capability of the GM engine. But the following should be doable to any programming language. Before updating the data of a specific section or weapon etc, store the original data as a variable stack of say height of 3. Then you can recall the original data through the stack if needs undoing. The number of undos is limited by the stack height. The only requirement is that each section and weapon has a unique reference ID in the ship maker.
This would need threading. GM is not threaded.AnnihilatorX wrote:I am sure saving process can be performed in background at a low priority.
If i were to implement a proper undo/redo system, thats how i would do it in regards to object parameters.AnnihilatorX wrote:Before updating the data of a specific section or weapon etc, store the original data as a variable stack of say height of 3. Then you can recall the original data through the stack if needs undoing. The number of undos is limited by the stack height. The only requirement is that each section and weapon has a unique reference ID in the ship maker.
But its not that simple. Sections are not just a collection of parameters - there are pointers, data structures, references... And then you have to handle object deletion and insertion (parameters of some objects depend on other objects, for example), parents, links, drivers, etc. Its not just a matter of writing some variables into a stack; if it was, we already would have done it.
Im afraid that without actually knowing ShipMaker source, trying to make a useful suggestion how to implement something is just shooting in the dark.
-
- Commander
- Posts: 116
- Joined: Sat Mar 01, 2008 3:49 am
I understands it's a elaborate system but I fail to see proper implementation will make it too complex. I am not trying to be annoying, if I still fail to see the point just tell me to shut up.Kaelis wrote: But its not that simple. Sections are not just a collection of parameters - there are pointers, data structures, references... And then you have to handle object deletion and insertion (parameters of some objects depend on other objects, for example), parents, links, drivers, etc. Its not just a matter of writing some variables into a stack; if it was, we already would have done it.
Im afraid that without actually knowing ShipMaker source, trying to make a useful suggestion how to implement something is just shooting in the dark.
In terms of sb4 file, all parenting, linking, etc are different entities to object parameter but are still numerical parameters. It depends if you use object ID in terms of references for linking, parenting etc. Say if section1 is linked to section3, the ID number 3 will appears in section 1's parameters. If section 3 is deleted, SM has to change 2 set of parameters, i.e. deleting section3's data and updating section1's linking parameter. To store that undo info, you just need to store the 2 object's parameter sets, no? Deleting a series of children objects will mean storing parameters for all the children, but still doable. Basically what need storing is a series of changes, and multiple undo steps. Each undo step then gets is own mega string variable, similar in format to the sb4 lines. To undo, just reapply the object parameters in reverse sequence.
Since each sections should be uniquely IDed, and unknown ID are added as new blocks with same ID, SM should have no problem handling deletion, changes to existing sections, and even a whole chain of parent child relationships.
It takes much less resources than keeping full sb4 as temporary files because you always know what is being changed by the user actions. Although this mean that you'd need to make program handle events for all user actions and this may be where the complexity is.