MrMiller's Forum Posts

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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

  • I can't seem to set my password to a new one... It doesn't recognise it, or the old one, when I try to log in again.

    Do you get the "Username and password incorrect" message? Or, does it just send you back to the front page with no message? I get the latter unless I check the box that says "Remember me". When I check that box, it lets me in. Give that a try and see what happens.

  • Does it help if you clear your cookies & cache? Just wondering if it's something left over from the old site.

    Nope. Still does it.

  • I just went through a bizarre chain of login problems where I had to submit for a new password several times, but none of the new passwords worked, and then when I reset it to my own unique password it still didn't work. That is, until I realized that if I checked "remember me" the system would let me in. But it should let me in without doing that, so this could be a bug... or something wrong with my browser settings, but I wasn't having this problem prior to the site change.

  • You do know if you save as a project everything's already in separate files, in C2? So would it be enough to just be able to manage when those textures are loaded in to memory?

    I hadn't checked C2 out since the first build I think, and I didn't do much with it at the time, so you'll have to forgive my ignorance on that.

    I see that images are being saved to the "texture" folder. So, say I wanted to call up image files and I wanted seperate folders for seperate batches of images, like "Texture Folder 1" has images 1 through 25, and then I create "Texture Folder 2" and it has images 26 through 51. Would I be able in events to write a Loop-String that searches a specified folder and calls the images in that folder up into the game at runtime? Right now in CC, I can replace images at runtime with other images from folders using a Loop, and I can specify which folder(s) to call the images up from. I'm really hoping that functionality carries over to C2.

  • 1. I'd like to see something that addresses how animation frames sequence themselves after you drag, drop, and rearrange them inside the animator. Like, if I move frame 12 to frame 1, I'd like the frames to still be able to keep their original visual number (the number they had before I moved them) somehow--perhaps by putting its original number next to it in parentheses?) because when I have a 150 frame animation that I'm chopping up, I'm not going to be able to remember that I moved frame 137 to frame 33's position. I mean really, this would come in so handy for those like myself who have animations with lots of frames and chopping and rearranging is necessary (as is often the case with animations with lots of frames).

    2. Gotta be able to import at run-time based on an event action. Using Loop Index to call up assets in CC is a Godsend. I realize that there are other priorities, but to me this is one of those things that just shouldn't be an afterthought. Being able to call up and manage assets from folders rather than bogging the game file down with them is just beautiful and useful.

  • I'm wondering if there is some tweaking needed with the volume setting in the plugin. In my cap, the difference between Volume 100 and Volume 10 isn't much at all, but it should be. If 100 is the loudest, then I should barely be able to hear 10 at all, if at all. On Volume 1 I can still hear it at the same level you'd image it to be at like 20 or so, but I shouldn't be able to. I also tried 0.1 and it's the same.

  • Oh, I see. I got it. Thanks, Shinkan.

  • Yeah, that part I get, but I don't understand the overall structure of how it's all supposed to be put together. It's probably so simple that I'm just missing the obvious, but with Xaudio all I had to do was either put in the file name and location, or if it was to all be in the same folder I'd just input the AppPath and file name.

  • Xaudio was/is a major pain, but I don't understand the "alias" part with the Audiere plugin. What is this "alias" supposed to be written like? Can someone post some lines of working events that make a sound file play with the Audiere plugin?