Wyrdysm Games

I have a question. How do i scale (mkae it bigger, smaller, taller etc) sections and weapons? And how do i change the explosion after the ship is destroyed?

Read the instructions. F1 in the shipmaker brings up aforementioned instructions.

You can't change the explosion.

Thanks

I just started playin ... but i hate askin noob questions, but ive looked in the Instructions in F1 and is there a way to undo something? What exactly is dept? and how do it control what is on top or not?

I don't know about undoing things, but depth can be changed by right-clicking on the piece in the shipmaker and then clicking set depth.

You can only undo one action at a time (unlike for example, Microsoft Word, where you can press undo many times and thus undo numerous actions). You do this by holding control and pressing "z", just like you do in many programs.

But be careful, for some reason it sometimes undoes several actions all at once, which can hurt a lot.

mtheminja wrote:But be careful, for some reason it sometimes undoes several actions all at once, which can hurt a lot.

I have already mentioned that as a bug. Hope they will fix that, and maybe introduce multilayer undos. Even MS paint support 3 undos.

AnnihilatorX wrote:

mtheminja wrote:But be careful, for some reason it sometimes undoes several actions all at once, which can hurt a lot.

I have already mentioned that as a bug. Hope they will fix that, and maybe introduce multilayer undos. Even MS paint support 3 undos.

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.

Anna wrote:

AnnihilatorX wrote:

mtheminja wrote:But be careful, for some reason it sometimes undoes several actions all at once, which can hurt a lot.

I have already mentioned that as a bug. Hope they will fix that, and maybe introduce multilayer undos. Even MS paint support 3 undos.

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.

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.

Without incurring much performance issues in form of undo lag? Have you even tried saving/loading ships that have more than 500 parts?

in that case, would it be at all logical to add in an autosave feature that deactivates when the ships is > size (or section count, or w/e)... ____ ? Perhaps personally set? Not to use for undo features, but simply to automatically save your ship every ____ minutes

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.

AnnihilatorX wrote:I am sure saving process can be performed in background at a low priority.

This would need threading. GM is not threaded.

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.

If i were to implement a proper undo/redo system, thats how i would do it in regards to object parameters.

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.

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.

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.

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.