digitalsoapbox's Forum Posts

  • (I'll count myself as an expert in as well).

    To be honest, I don't mind the text in the blank event sheet at first, since from the moment you add an event to it, it disappears and is not to be seen again.

    It is like a graffiti in the empty event sheet, and even adding a comment makes it go away.

    As for the tooltip/field helpers, they are freaking helpful and preventing from having to go dive in the manual for a quick refresher when needed.

    Especially for the kind of objects you don't use everyday, or come back to later in your development.

    Sure for common actions/conditions they are "useless" after a while, but honestly it is easy to focus on the field(s) and not even pay attention to the small line on top of it.

    I think the suggestion of having them grayed is actually giving them more focus on top of making them harder to read if you want/need to, which in the end defeats both purposes.

    Kyatric

    (I'll count myself as an expert in as well).

    To be honest, I don't mind the text in the blank event sheet at first, since from the moment you add an event to it, it disappears and is not to be seen again.

    It is like a graffiti in the empty event sheet, and even adding a comment makes it go away.

    As for the tooltip/field helpers, they are freaking helpful and preventing from having to go dive in the manual for a quick refresher when needed.

    Especially for the kind of objects you don't use everyday, or come back to later in your development.

    Sure for common actions/conditions they are "useless" after a while, but honestly it is easy to focus on the field(s) and not even pay attention to the small line on top of it.

    I think the suggestion of having them grayed is actually giving them more focus on top of making them harder to read if you want/need to, which in the end defeats both purposes.

    Kyatric

    I didn't ask for them to be greyed out. I asked for an option to hide them entirely although in an earlier user's post, if the grey was darkened a little bit, would be better than black text on solid white - right now the help text just kind of blends in with the editable form fields, so as it stands it's not as good as it could be in terms of visual clarity or defining a hierarchy of importance (help text is not as important as functionality). I don't need to be reminded of what "compare two values" does on a per-field basis. The name of the event is descriptive enough. While that's just one example, that extends across all events. If I get stuck, I can always turn them back on - maybe a hotkey toggles them? - or open the manual. Aside from needing to point out that not expecting people to read the manual is insanity, but that's another topic. Outside of being distracted by their prominence in C3, I can't remember the last time I actually read any of the hints. So it'd be nice to get rid of them. Maybe the CSS will be clean enough that it'll take just a few changes to hide them globally? That'd be good, if it's a feature that isn't going to be added in by default. Other than a dark skin, which is kind of expected these days because black on white is so hard on the eyes, that would be my first change once it's possible.

    It's a pretty common feature in both development IDEs and many other widely-used applications that are designed for a broad audience made of both beginners and more experienced users. At a certain comfort level, users just don't need to be constantly reminded about what does what, y'know? Imagine if every time you rolled over an icon in Photoshop, it presented you with a highly-detailed description of what the tool does and what it's designed to be used for. That's what this feels like in C3.

    Anyways, since C3 is in testing I figured I'd bring it up. I thought about mentioning it in C2 but with C3 being an IDE rewrite it made sense to wait. Obviously there are more pressing issues.

  • Well, like I said, I made the software (hopefully that counts me as an expert user?) and I still think it's handy to have them there. For example when you focus the Volume parameter of a Play Sound action... is it in dB or a ratio? Positive or negative? Honestly, sometimes I even coded it and can't remember what I did. The tip clears it up: it's dB attenuation, so ought to be negative, or 0 for full volume. That kind of thing is always useful IMO, whoever you are.

    Ashley

    I've never, ever done that, because I read that it was dB and have never forgotten it's dB. Or that X/Y coordinates start in the top left. Or what # IDs represent what buttons on a gamepad. I can't imagine anyone who's spent a significant amount of time with Construct or other development software not being able to do the same. I understand your point (somewhat) but at the same time, I run Photoshop, Illustrator, After Effects, 3DSMAX, etc. with the interface hidden 99% of the time, that software all has quite a bit more to remember than Construct hotkey-wise, and it's never been an issue. Less clutter is always good, and unnecessary text is clutter. Plus, you've already got a "Help" button plastered across every feature, so is it really that much of a concern to constantly remind people if they don't want to be reminded?

    As someone said above, it seems to be a target audience thing. Hence the request for a separate mode for a more advanced audience. "Always" is a strong word, because it's not really always when you just want a reminder on occasion. I wouldn't really mind C3 looking a bit less like a beginner's toy and having large prominent help text every step of the way going all Microsoft Paperclip on users isn't helping.

  • How about having it like it is, just for the free version?

    Take the training wheels off for the subscription.

    I can see value for newcomers in having this stuff in there even after subscription, but I would also like to not have to see it myself.

  • I get that Construct is supposed to be easy to use and all that, but I'm not sure I really need the extra descriptions on event popups or the event sheet itself. This seems to be an ongoing concern throughout C3 and honestly, that help text just takes up space in popups and I don't really need to see it every time I create an event sheet. I can't imagine anyone who's coming from C2 does.

    I'm referring to this:

    I know this text was also present in C2, but it's so prominent in the new look and feel. As a side note, there sure seems to be a LOT of wasted space under the fields:

    Having an "Expert" mode that rids the interface of reminders of what we meant to do in the first place would be pretty great. After all, if we need help, there's already a help button.

  • What features are missing? I get that you can't use them because it's locked to free edition right now, but they are going to be ready for testing in the last week. We're confident at the end of the beta everything will be working great and we'll be comfortable to start selling it.

    Cool. I'll try it again when they're available .

    EDIT: Maybe...those features will take longer than a week to test? Just a thought...

  • >

    > > What's been released as the C3 "beta" is very obviously an alpha. And that's fine, but mislabeling it (not to mention putting such a hard limit on accessible features) means that, even for just messing about with it, it's not entirely worth the effort right now. Hopefully we see an actual beta in the near future, prior to the release of the commercial version. Right now it feels very...meh. I'm not excited by C2 in a browser in the slightest, especially since right now it seems to be more an inconvenience than an upgrade. I guess we'll see what happens!

    > >

    >

    I mean Alpha/Beta are all fuzzy terms. We did run a private alpha before the beta. We're happy to call it a beta. Expect rapid improvements.

    They didn't used to be fuzzy terms . Beta used to mean feature-complete with some bugs, and it doesn't feel feature-complete right now. I think the biggest issue with what's publicly available for C3 is how locked-down it feels, even compared to the free edition of C2. Some of the usability seems a step down from C2 as well. I'm sure it will improve over time. Right now it's a bit underwhelming to say the least, though I'll admit part of that is because of the lack of third-party plugin support (currently) that adds features that I've found to be absolutely necessary to make Construct a complete and functional development tool (raytrace, canvas access, some filetype import options, etc).

  • I have to wonder why would Scirra tease us for months with so many new features and then release a beta where almost all of these new features are locked. I understand that Scirra wants to test and fix all the basic features first, but why even start teasing with the new features so early when in reality they are months away?

    I tested out everything I could think of with the available features. I made a few test games and tested out cloud saving support. Everything worked well for me and I didn't encounter any problems. The editor itself looks and feels almost identical to C2 editor and I really like it.

    Having to right-click is a big issue for me as well. While it seems like it should be simple, I'm so used to using shortcuts that I hardly ever touch the mouse in C2. Having to do so just slows things down. Take into accout that OSX requires a two-key combo to right click and it becomes an even bigger workflow roadblock. There seems to be a number of features that take more clicks than they should right now, and from the outside it looks like those exist to work around issues with having a browser-based IDE. Not a great sign, tbh. As for the features, yeah...don't sell me a bill of goods and then not provide the goods.

    What's been released as the C3 "beta" is very obviously an alpha. And that's fine, but mislabeling it (not to mention putting such a hard limit on accessible features) means that, even for just messing about with it, it's not entirely worth the effort right now. Hopefully we see an actual beta in the near future, prior to the release of the commercial version. Right now it feels very...meh. I'm not excited by C2 in a browser in the slightest, especially since right now it seems to be more an inconvenience than an upgrade. I guess we'll see what happens!

  • Wow... This really looks beautiful. It would be so nice to actually know how to do this. looking forward to it... there has been any advance?.

    Ashley fixed a bug with canvas resizing affecting collision cells in a recent beta (I don't remember this being mentioned in the beta, but it's working now when it wasn't before) so I've been playing with it a little bit. It won't work in C3, at least until if/when Paster gets ported, and I doubt I'll dig too deeply into adding the features I'd originally planned before C3's worked through the issues that are popping up in public testing.

    Construct 3 is built for now and the future, using bleeding edge features.

    I would also argue that an organisation not allowing updates to browser is a pretty backwards security policy. Unfortunately you'll have to wait for them to allow updates.

    You'd be making an unrealistic argument. Larger companies, especially those with security concerns, are typically at least a few versions behind. Every update to every piece of software is vetted by internal IT teams at larger companies and just about every school I've ever worked at or been in. I've worked at places that were many versions behind with Adobe's CC suite for this reason, and while it's obvious not many people are going to hack a computer through Photoshop, it's still a concern for places with organization-wide IT policies.

  • Jayjay

    Thanks for your input, but I'm already aware of these. Maybe I should have been more specific when I said "competition". Blurymind has consistently pointed out CTF and GM as being C2's competition. I'm just curious to know what he thinks those specific engines have, from a technical standpoint (ie., usability, features, etc.), that's better than C2.

    But again, thanks for pointing those out.

    From a technical standpoint, C2 is not the best choice if you want larger games that perform reliably well on mobile or console, because of the technology it's based on and mobile/console support of that technology. If your target is desktop only, C2 is fine. Not being able to export natively, and use native libraries directly (OGL, DX, etc.) is a huge issue, and makes it near impossible to predict performance across a wide range of devices, which is especially relevant on mobile. If you're doing puzzle games or runners, on mobile or web, C2 is fine. Bigger stuff? Sure, it can do it, but as soon as anything hits the rendering pipeline, even without layering on lots of shaders, effects, or particles, performance of C2 is god-awful. This may not even be a limitation of C2 itself (some definitely is, but not all), but since it's depending on 3rd-party wrappers to do, well, basically anything other than a game on a website - and even then, it has to depend on the browser's rendering tech and javascript execution speed - it quickly shows itself to not be the best choice. For example: it's exciting that (at some point) C2/C3 may support XB1 export, but Edge currently sucks at any kind of even basic shader/effect support; throwing a handful of tinted objects or, say, objects with a Multiply or Screen blending mode, and it dies a horrible, stuttering death. Which, since I use these in Sombrero, means Sombrero probably won't run very well on XB1, even though it's not REALLY doing anything that's complicated at all on the shader/effects front.

    Is C2 the easiest and most flexible to use for 2D games, if you're looking for an engine that is specifically 2D? Yeah, probably. If you want to create something of high quality that can run on multiple platforms, across a range of consumer devices, and doing so with the performance expected by consumers? Not so much. Using Unity's 2D features would be the way to go, even if some of it feels super kludgey and somewhat tacked on top of Unity's 3D engine.

  • You can install Git, node.js, Java, Cordova and the Android SDK to build locally without having to upload anywhere:

    https://evothings.com/doc/build/cordova ... ndows.html

    https://cordova.apache.org/docs/en/latest/guide/cli/

    https://www.npmjs.com/package/cordova

  • Can you post a screenshot of what you're seeing? I tried your capx but it's working fine in r243 for me, and I think this latest beta fixed an ugly kerning issue with spritefonts.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • digitalsoapbox

    I see the issue. The ObjectRefGID is the raw value, but in order to extract the frame ID, the plugin also needs the 'firstgid' parameter from the Tileset because the frame number is relative to the tileset being used. IE: frameNumber=TilesetFirstGID-ObjectRefGID.

    As the plugin currently stands I think rexrainbow might need to add the retrieval of the Tileset's 'firstgid' parameter in order to extrapolate the frame number. Sorry for getting your hopes up, but hopefully, Rex will pipe up.

    In the meantime, Bjorn, the Tiled developer (am I right in assuming you are using Tiled), doesn't recommend using Tile IDs to reference tiles in a tileset because they are 'volatile'. I had to agree with him because I found out in my situation, I could not reset certain tiles to start at 0 within Tiled. For example, in one of my tilesets, the first tile's id is 3, and there are some the skipped a number. And so referencing them in C2 was yielding incorrect frames even though the tile ordering was identical.

    The only practical solution for me was to apply a custom property to each individual tile assigning them a frame number. I think this a much better solution as it is predictable. Also, it is also possible to parse the TMX externally that will procedurally make the correspondence between the TMX tileset and the animation frames in C2.

    Lastly, I have modified Rex's code specifically for this 'Image Object Tile ID' requirement, but I have not requested Rex to 'pull' my modifications as I think it's better for Rex to maintain his plugins. If Rex allows me to post modifications to his code then I'll do that here.

    But again, I personally have abandoned the idea of using Tile IDs for frame numbers mainly because they're not dependable.

    I haven't had an issue with using tile IDs for animation frames so far. I'm using TMXImporterV2.Frame for tile objects and it works just fine. I also started with a set size for tilemaps using a single image in Tiled, so maybe that's why it's working for me. Either way, I sure would like to be able to get the tile ID for objects so I can optimize collisions a bit more .

  • digitalsoapbox

    Rex PM'd me about a TMX Importer V2 update but it seems he had forgotten to update this thread.

    Here's a direct quote from rexrainbow

    > Please update tmx related plugins.

    >

    > Add new expression:ObjectRefGID to get reference gid of an object, and extend expression:TilesetName( gid ) to get tileset name of a specific tile (gid).

    > ex : TMXImporterV2.TilesetName( TMXImporterV2.ObjectRefGID )

    > Hereis a sample capx.

    >

    The 'gid' is what you're looking for. It's basically the 'frame number' of the Object, as it were.

    I also believe that Rex updated only the one in his main site, not the Github one, last I checked.

    faulknermano rexrainbow

    Thanks! I'll poke around with it and see if I can get it working.

    This works to set the animation, but what do I need to do to set the animation frame? I'm getting the right tileset name to reference for setting the animation from TMXImporterV2.TilesetName( TMXImporterV2.ObjectRefGID ), but not a tile ID to reference as frame number.

  • digitalsoapbox

    Bit of an old thread, but I just noticed this and saw that you are iterating through TMX Objects (not Tiles). I had mention this to rexrainbow recently about adding support to reference Tileset-related parameters for Objects. At the moment, if I'm not mistaken, only Tiles properly reference their Tilesets. In Objects (and in Tiled, that's the Tile Image Object), the plugin is required to make a connection with the 'gid' parameter to the Tileset.

    Anyway, I was wondering if you solved your issue and how.

    (For personal use, I modified Rex's code and got Image Objects to reference their frame, but I think Rex might be doing his own modifications, if indeed what you're experiencing is rooted in this.)

    I missed this comment originally. I still can't get the correct frame from objects using this importer.