Gamma Ray's Forum Posts

  • 14 posts

  • Well, the fix was indeed simple. I hadn't had the opportunity to work on it for a few days, but when I got to it this morning it took all of about five minutes to put it in. It could actually probably be trimmed down at this point, as I think it may have gotten slightly redundant. Ultimately, it works now, though. Everything else is gravy.

    Here's the properly working color picker boxes for anyone interested. Thanks again to Newt, Tulamide, Tokinsom, Scidave, and Sully for help in this little endeavor. The solution in the colorpicker CAP can now be implemented into the profiler.

    The profiler's not worth posting yet, but if it develops into a more generally useful tool, it may get posted in the future. :]

    http://largeangryrobot.webs.com/colorpickerfix2.cap

    Construct Classic r1

  • Thank you very much, Newt. That has entirely solved both the "Cancel" problem and the single cycle delay when using the "OK" condition.

    It has, however, created a different issue, wherein picking the color in the second box will also change the color in the first box. I can see exactly why. The condition of the Toggle private variable from the other is still true when the second box is also color picked, so it recolors both.

    That one I can probably smash my head into until the solution clicks. It's always facepalmingly simple when I figure it out. Makes me feel like such a dunce sometimes.

    Again, thank you for introducing me to the function there. It's got things on the right track! For now, it's late, so I'll putter with it tomorrow.

  • I feel like I've committed some kind of sin for quadruple posting, but I still haven't figured out the color box matter.

    I tried using the "On Colour Dialog OK" event condition, but it produces another strange result. Particularly that it has a full one event cycle delay before applying the color to the box. So, the first time you hit OK it applies a blackish color to the box, even if you selected red. If you repeat the action, it would apply red to the box, even if you picked orange.

    With the help of the other posters, the search function, and the wiki, and some thoughtful workarounds most problems thusfar have been conquered. I just can't seem to trample the Colour Dialog problem, though. :[

  • Hello again!

    After many days, things are looking good. The profiler is in a functional condition, although it still lacks things like failsafes against common user errors and has a few quirks left to iron out. Still, it does the most basic things that will allow us to start using it and storing character data. I'm having a friend put it through the ringer, since another pair of eyes always finds something I've overlooked.

    One such case was brought to my attention. I'm using the Box Object to allow the display of a particular color, selected by the user. The color is set by means of the Windows Color Picker via the Common Dialog Object.

    The problem is that if you cancel out of picking a color, instead of leaving the color in the Box in question alone, it will set it to the previously selected color.

    Rather than include the entire profiler (which is still a mess and needs intense optimization and reworking in many areas), I have distilled the problem down to a tiny .CAP with just a few events. It allows accurate reproduction of the error. If anyone can figure this one out, I'd be much obliged. As it stands, a simple misclick could cause loss of your selected color, and that's no good.

    CAP File:

    http://largeangryrobot.webs.com/ColorBoxes.cap

  • That is very unfortunate. I hope you find something that works for you in short order!

    It's a tricky time to buy a new laptop with a decent IGP, though. AMD's Llano is fast approaching.

  • Edit: Using the debugger informs me that event 5 is attempting to add a string to an integer. Looking into it.

    Edit 2: Solved the Integer/String conflict. Apparently only part of the problem. I'll look into it more tomorrow...for now, bed.

    Edit 3: Fresh morning! Fresh mind! It appears to be working properly now. After fixing the Integer/String conflict, it ended up being a conditional fallacy in the blocks and a mistyped variable. I can now save new characters and it will properly seek out and overwrite existing characters with new information. Thank you for your patience!

    Next up, the delete function. That should be delightful.

    Also, the debugger in this is great. It's so clear in listing everything that you're looking at. No more archaic C++ debuggers. <3

  • Again, I appreciate all the ideas. For now, I think I will go with the simple and brutish approach to get it up and running for my friend and I. As we'll be using it for some time, I do plan on refining it both visually and functionally, so it will likely go through some under-the-hood revisions (likely in the veins you've both suggested) to make it smoother and easier to handle.

  • Ahh, clever work around with a box object! Thank you for this, it saves me some questions later. :]

  • I read your tutorial on Arrays, Tulamide. That was very informative, and perhaps I'll look into whether I can/should use hash tables as things go on. :]

    So, to end the guessing games, what I'm putting together is a (very Spartan looking) character profiler. Name, age, height, all the details. Neatly storable in an array.

    My next question is more a matter of the "proper" way to do something. In this case, array maintenance. There is a possibility that characters would be deleted from the array, which would leave a host of blank cells. Keeping the array from becoming bloated with blank chunks means that there will have to be some form of maintenance since it can't always be assumed that the deleted character will be the last one in the Array.

    The format is X is a column that contains all the relevant information for a single character, and Y is each item of info (currently at 16, but it'll get larger).

    As far as maintenance goes, I can think of a few ways.

    A) When a character is deleted, set all their column values to 0/Empty/Null, what have you. To minimize wasted space, when saving a new character the application could search for empty columns to dump said new character into. This could still result in multiple unused columns if more are deleted than added, and would still require some kind of maintenance function. It doesn't really seem like a good idea.

    B) When a character is deleted from the list, the maintenance function automatically begins to copy over the data from any columns that follow to the empty one, in a loop. When the final column is the empty one, it truncates by reducing the array size by a factor of one. This ensure that no matter how many characters you delete in succession, there won't be any empty columns. It seems like the better solution for tidiness.

    My concern with approach (B) is the time it will take. I expect the array's final size to be something like 50x35x1, but it could be larger still. It's not monumental in size, but what kind of processing time are we looking at if the character in column 2 gets deleted, meaning that the remaining 48 columns need to be shifted over? I'm sure part of that will have to do with the efficiency of the loop, but I'm still curious. My (limited and decrepitly rusty) C++ experience from college tells me that I should always keep on top of maintenance, as in approach B.

  • Thanks for the heads up. After checking out the Object Information window, there really is a heap of undocumented features in there for some of the objects!

    The Focus on/off is doing the trick, and I can now put the focus onto any given EditBox. An If/Else block with a hidden variable to keep track of which edit box is on seems like a reasonable approach. While working on that, I hit another snafu. I can't seem to find any condition that detects whether an edit box has focus, so I could lose track of which one has it.

    Then again, maybe I can just keep track of it by detecting when the object is clicked with the mouse! I think that's doable, since there are conditions for objects being clicked, through the KB&M object.

    Ironically, after all this talk of tabbing, it seems that the edit boxes inherently have command over the tab key to make an indent that can't be overridden. It still moves between boxes, but puts indents in on the previous box.

    Really, this is a job best suited for a simple spreadsheet, but it seemed like a good way to learn about some of the basics in Construct, so I will press on anyway. Thank you again for the assistance. :]

    EDIT: On further thought, I can just reassign the tab function to a different key. Probably one of the Function # keys. Construct certainly does lend itself to clever solutions!

  • Right, so. Some hours of tinkering and reading later, I'm getting to learn things. For one, I've opted to go with the DX runtime for the application, as I can use it to make quickly swappable color blocks, which appears to not be an option for Application runtime (understandable). The DX runtime also lacks the problems with misrepresented font sizes, making layout setup much easier.

    There's now a new question. Is there a way to move the text cursor (rather than the entire mouse cursor) between the edit boxes? Let's say I have 3 EditBox objects, which we'll call Edit01, Edit02, and Edit 03. Normally, I would Tab (which I can read for with the Keyboard & Mouse object) and then the cursor would move from Edit01 to Edit02. If this can be done, then presumably reading for the combination of Shift+Tab can make it go in reverse, including Edit01 to Edit03.

    I'm not seeing any particular condition to move the text cursor between edit boxes, and I've not seen it mentioned in my searches on the forum (though there was a handy post on rigging colorable edit boxes using multiple objects). Possible? Impossible? Again, not a dealbreaker, just a matter of UI refinement.

  • Thanks for the welcome. This program is bounds ahead of ol' MMF1.5 in terms of both function and the fact that it doesn't max out your CPU cycles when a simple text application is at idle. :]

    I can work with MS Sans Serif since it's at least consistent. Courier is a bit unappealing to the eye, but MSSS is fine.

  • Hm. I see what you mean about the Zoom. It appears to be controlled by Ctrl+Wheel Up/Down (standard). That said, I'm working at 100% size, and interestingly the text remains at the same size on the screen despite what the Zoom level is at -- it's the same pixel size on my screen if I blow it up to 200% or shrink to 50%.

    Further tinkering suggests it may have to do with specific fonts. Arial and TNR demonstrate the misrepresented size, but Courier does not (perhaps because it's a system font?).

    Edit: MS Sans Serif also appears to display normal sizes. Hrm...

    Edit 2: Okay, rather than Courier and MSSS displaying normal sizes, they're displaying the reduced size (again, a font size reduction of 2) in both the editor/runtime. Well, at least MSSS is a relatively readable font. I think I can work with that, need be.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • EDIT: Rather than make a whole new thread, it seemed like a better idea to keep all my silly little questions to one thread as they come. No point in me clogging up the forum.

    _______________________________________________

    Hello. First time poster, so be gentle. :]

    I've been looking at Construct for a while, and have been tinkering with it for a few days. Thusfar, I've found it more enjoyable than MMF1.5 (which had its merits, but Construct has some indescribable facets I prefer already), but there's one thing that I just stumbled on while teaching myself how to make use of Arrays, Edit Boxes, and the Text Object.

    You see, when I make a Text Object in the Layout Editor, it misrepresents the font size. I'm guessing by a factor of about 2 or so. While I can eyeball it to compensate as I putter with my little project, it's just kind of this little gremlin that nags at me.

    Here's an example of what I mean, with the layout on the left and the runtime preview on the right:

    <img src="http://largeangryrobot.webs.com/Constructtext.jpg">

    As you can see, the font is a proper Size 10 in the Runtime, but significantly smaller in the editor. I've tried this on two different PCs (one cruddy old XP laptop, one shiny new W7 desktop) and the results are the same, even on a fresh project. All I can tell so far is that it seems possibly tied to the choice of Application or DirectX runtime. Picking Application shows the reduced size font in the Editor, and the normal size in the runtime preview. Picking DirectX shows reduced size in both the editor and the runtime.

    Is there something I can do? Should I just work around this, or is there a tweak/setting that I've missed in order to get the editor to show the proper font size with the Text Object? I can provide a CAP if needed, but it seems to happen on entirely different PCs, whether I use a new file or my current project file.

  • 14 posts