When I do that it doesn't do anything. I right-click inside Gimp, then I select "copy" to copy the image. Then I open the Construct Picture editor, select the paste icon, and it does nothing.

Is it possible to copy an image from another image program like Gimp or Photoshop and then paste it into Construct somehow? I've tried this but it has never worked and I've just assumed it's not possible, but I want to make sure.

I'm using Construct Classic 1.2, by the way.

Hmm, maybe make seperate parts for the car and then hinge them together. On collisions, remove hinges until the parts completely fall off the chasis.

The physics object would go nicely with that.

Construct is better designed than MMF2 in so many ways. Subevents, for each loops, changing display resolution at runtime, better zooming, better bilinear support, better alpha channel support, event sheets can be included within another sheet, you can "read" events you're not just looking at check boxes, that's just some off the top of my head.

Yeah, MMF2's clunky old event system is the one reason I just can't stick with it. I understand it, I just hate it, and I'd bet that this alone is the biggest roadblock to new users getting into and sticking with it.

When Construct was built, the devs here had the right idea; create an event system that can be read and interpreted at-a-glance. It just makes perfect practical sense and should be--in my opinion--the standard for this type of dev tool. The other approaches (checkboxes, building blocks, pull-down menus) all look good visually, but in practice they lack that conversational-style translation that gives your events a smooth, organized flow.

I agree that going to a competitor's site to do missionary work is not a good idea (not saying you were doing that bobwaite1, as I didn't see your post on the ClickTeam forum, I'm just speaking generally), at the same time you have to wonder what's behind Jeff's response with "Due to some issues with the developers behind construct". I just find a company saying that sort of thing outside of their offices as unprofessional. That part wasn't necessary and he should've kept that to himself.

Just curious, but couldn't a similar thing be done in Construct by using blank sprites for the limbs in Constructs bones animator, and then importing the filled sprites for each limb at runtime using Loop Index?

Although I agree that it would be helpful to have some book, it is complicated, as soon as it comes to details.

Construct never was a finished product nor is. There are many plugins that come with Construct, although they have issues. And I don't mean smaller bugs, but missing or wrong functionality. Just take the binary object as an example.

A book would need to ignore those plugins, but the purpose of such a book would be to have a complete guide/help.

This is very true. I was telling some people about the difficulty of expressing the details in a book in regards to doing certain things in Construct, and how some things aren't functional or properly functional with it being a beta. I don't think they were listening to me as they weren't very courteous, but it's inevitable that they'll come to see it for themselves.

Unlike blender Construct is ridiculously easy to pick up , so it'd be absolutely pointless to make DVDs / Books , especially for 30 dollars.

I don't think a Construct book or DVD would be pointless at all since the goal would be to teach someone a new skill in a fundamental way that they wouldn't have gotten otherwise. Since people tend to learn and understand in different ways and at different paces, even Construct would benefit from these types of resources, and certainly other programs of its type have had them. I'd also like to point out that this style of event-based game development is not for everyone, and even the most experienced and/or talented programmers versed in other programming methods may and do find these types of programs frustrating at times. So difficulty or ease of use really is a matter of personal comfortability and expectation.

Aside from the HobbyPress book on Construct which I haven't read (and can't vouch for whether the book is good or bad), So far there haven't been any other worthwhile companies of any professional stature pushing towards a good, deep, Construct resource, but I'm sure someone will step up in the future.

Using different files per group will also help increasing stability. With some efford when trying to read in the data you can manage for your engine to be able to work even if 1 or more of the files are corrupted.

With only one file all is gone if the file is corrupted.

Excellent point! I didn't even consider corruption, lol.

This is also a statement for multi-file-management. I think the users of your engine will have more fun editing if they don't have to look through one huge file and saving the content of it, everytime they just work on one tiny change.

This too is a good point. At first there weren't going to be many groups, but now that I'm possibly looking at over 100 it would definitely get to be a chore to look through.

Ini is just text, so there is a possibility of some lag created by a text to number conversion if the file is rather large. That is to say if it will be parsing a lot of data each tick.

Then again you could expect similar results for lots of little files under the same conditions.

Thanks newt, really good info there. Based on that insight, I'm going to have to be conservative with how much/how often I'm accessing. So far it looks like it's mostly at the selection screen so if I were to keep it just there it wouldn't be a problem, but I've also been leaning towards a real-time system where certain actions during battle overwrites data and saves to the .ini, so that would definitely call for an efficient route.

I don't know about the technical side (it will take more ram, more cpu, or not, bla bla) but I see 2 other points there.

Yeah, I'm wondering if there is any technical downside. If there is, I doubt it would be major since it's only text and not even text that needs to be triggered in like a split second or anything.

First grouping or separating will depend on your engine (like having an ini file in each folder containing the images of the group or something like that or rather a single data.ini in the root folder).

It is somehow a matter of taste.

The sprites inside the layout are blank, meaning that you'd have two groups of fighters and based on which groups you select, the loop index--based on a global variable--will bring in the correct groups and populate the blank sprite positions at runtime (this I already know how to do). Also, based on the group, Construct will recognize the attributes in the .ini file and change each sprite's private variable attributes to match those in the .ini file. This will only need to take place once per game in the opening fighter group selection screen, so it won't affect actual gameplay.

What I'm not sure about it, is whether keeping all of these things in one file is a good or bad idea, or if separating each fighter group into its own file is a better idea.

The other point I see is that through .ini files, ppl will be able to modify the values of the fighters and groups in the notepad. Once again, depending on your engine it might be an issue.

If you want to prevent people from accessing those datas, you may create a simple editor, place all your datas in a hashtable and export it. Than in your game, load the hashtable and there are your datas.

You could still edit those through your editor, but simple notepad edit would be discarded.

I want them to be able to edit the file. My goal is to make an engine that can be fully edited by the end user even if they don't have Construct or any desire to learn it, so as far as I can tell using .ini's seems to be the path of least resistance to that goal.

SIDENOTE: The post preview function is not working. Please forgive me if this is already a known issue. Thanks

I'm working on a test project with .ini files. I'm trying to get another perspective on whether or not there are any cons to having a single .ini that contains all of the game management data versus a number of .ini files each containing parts of the game management data. Here is an example:

Single File with all data... The file would contain 100 fighter groups, each fighter group consisting of about 60 fighters, each of the 60 fighters would have their own number/text attributes that interact with private variables for each corresponding character sprite.

VS.

100 separate files... meaning 1 file for each fighter group with 60 fighters per group with each of the 60 fighters having their own number/text attributes that interact with private variables for each corresponding character sprite.