Ashley's Forum Posts

  • I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

    I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

    I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.

    So what are these advantages? From what I can gather from your post, you state code is better than events even when not human readable. Why is that? Isn't it better to write custom code in plugins which Construct already supports? I'm not saying events are always superior to code - they're not - but the options are put your code in a plugin, or ponder what to do with tens of thousands of lines of unreadable code. This isn't about code vs. events, it's about Construct generating tonnes of useless source vs. giving you the finished thing. That's not a feature, it's a waste of time to develop, from my point of view!

    Don't think this is a personal attack or anything, it's just that this idea about Construct generating source code comes up from time to time. I can't really see any point to it at all, so I'm trying to establish what people think it will enable. Such as:

    he wants to create the source code itself ... so he can take it over to another program, like you would a jpeg or a text file.

    Remember this is a big ball of mud code which doesn't make sense. What are you actually going to then do in another program with this unintuitive source code? I'm yet to hear any convincing real-world scenarios yet.

  • "export" the source code back out

    What do you mean by importing source code to XNA then exporting it out again? That doesn't make any sense. Source code is source code.

    As for exporting to source code, I really don't see the point. You would never be able to modify the source code to make changes. The insides of the event engine are very complex, and because there are no languages that support event style picking as language features, the generated sourcecode would not be human readable, it'd just be a massive mess, like a really complicated function copied and pasted a thousand times. And what kind of changes would you make? What would the advantages be? There are no advantages to exporting source code. Only disadvantages.

  • Quazi and MaxMan777, neither of you are coming across as civil and polite in this thread, and I will simply lock the thread if anyone continues to be in the slightest bit bitchy. I don't know why it's so hard to be understanding and diplomatic on the internet, but you've come to the wrong forum if you want to argue.

    There are so many nuances to making an American Football game work properly it's just not done by single programmers, and even large teams have routinely failed

    MaxMan777, I am not getting your point. Do you want me (or Davo, the only other active developer) to go to all this effort that defeats large teams and is fraught with nuances and time consuming coding? And for what, a thousand identical football games with superficial differences?

    We who make Construct do it in our spare time, unpaid, as volunteers. Our goal is not to make pre-made but moddable games - there are already loads of tools out there for that, and a lot of them seem to suck. Our goal is to provide, in Construct, a useful set of tools and high-level primitives (eg. Sprites) that can be used easily to make original games. I don't see your idea fitting in with that - but other developers can always extend Construct as they like with plugins and behaviors. I think that's your best option if you want to take this idea to Construct.

  • What advantage does exporting source code rather than built EXEs have? What does that have to do with this thread?

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Interesting ideas, just to add my comments...

    1. A Web-style creation system with simple-to-program randomization ... randomly display characters, or numbers ... all much simpler than it is now

    I don't understand your point about randomness. The random() expression gives you a random number. You can use that to jump to random layouts, display random numbers, make random events happen, etc. What are you asking for to be different here?

    [quote:23llzzmp]2. Sports-friendly creation algorithms ... engines built to accommodate shooters and platformers

    Nothing about Construct is specifically tailored to specific games - it's probably the built in behaviors that gave you this impression. If you like, you could develop (or hire someone to develop) sport-friendly behaviors via the C++ behavior SDK. Construct itself is aimed at creating any kind of 2D game, so features are necessarily generalised so they can be applied to as many kinds of game as possible.

    [quote:23llzzmp]3. A Template system

    You can select File - new template/example since we planned a system just like this, but there aren't many that ship with Construct. I'm open to community submissions for the templates dialog.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Because we haven't written full support for translations yet and there's no UI to change language - as soon as someone fixes that in the source code, translations will be more useful.

  • Another of my just-curious polls. I was wondering how many of you use the python scripts in the event sheet editor at all. I get the feeling not many people use it, but it'd be useful to know if more/fewer than I expect are using it at the moment.

    Python was always meant to be an addition to events, not a replacement, so that highly algorithmic or logical parts can be scripted. I'm not sure how successful the current Python implementation is at doing that right now, or if anyone bothers to use it at all! It's definitely an interesting idea that could be taken further, so this poll is just to see where things are right now. Feel free to add your comments below.

  • OK folks, link is updated. If you downloaded before seeing this post, hit the link again and reinstall (you can install over the previous installation and it should drop in the new physics files). That should fix the physics startup issue.

  • Physics didn't build properly so won't work atm, will upload a fixed build asap.

  • I don't think this is elitism or newbie hating, it's just the answer to "Can I make X?" is almost always simply "yes".

    As for the FAQ: in this forum is the sticky Are you new? READ FIRST! which links to the FAQ which has answers for questions like Can Construct create (insert genre here) games? and Will Construct be able to export to Mac/Linux/XBOX? which might be useful for the OP.

  • Download Construct 0.99.72 (unstable)

    This is an

    unstable build. You can help Construct's development by downloading it, trying it out, testing and reporting bugs. If you have projects you want to work on without possible bugs getting in the way, stick to stable builds.

    Link to previous build (0.99.7) changelog

    Some more general bug fixes before the new year. Hope y'all had a good christmas if that's your thing! This build fixes some problems introduced in 0.99.7 plus a batch of general other bug fixes. Davo's also added some bracket matching and syntax colouring to the parameters dialog

    Full changelog

    Behaviors

    • [FIX] Timer: crash when saving/loading
    • [FIX] Platform Movement: Detecting a wall to the left/right of you no longer picks up 'slopes'
    • [FIX] Physics: custom collision masks with a hotspot not in the centre would not work as expected
    • [CHANGE] Physics: Simulation Steps - Control how accurate this physics is.

    Plugins

    • [FIX] Canvas: runtime did not scale canvas texture if it was scaled in the layout editor.
    • [FIX] Canvas: drawing lines didn't work correctly (co-ordinates got messed up)
    • [FIX] Canvas : Pasting objects into it when its at an angle now works
    • [FIX] Tiled Background: Non-power-of-2 images are inset by a pixel, but the tiles no longer 'overlap', the area is cropped back (semitransparent tiled backgrounds now render seamlessly)
    • [FIX] Text: Retrieving text width/height now works
    • [FIX] Edit box: 'Focus off' stopped some mouse & keyboard conditions working
    • [FIX] Array: Set index to ? x 0 x 0 followed by setting a value could crash
    • [FIX] Box: setting width/height reset hotspot position to centre

    Picture Editor

    • [ADD] Hotspot and image points finally have an input thingy to type co-ordinates into!
    • [FIX] Holding alt will now position image points in all the frames

    Runtime

    • [FIX] Collisions : A weird glitch involving the near bottom of the collision reported by davioware has been fixed.
    • [FIX] Memory leak with effects
    • [FIX] Crash when family spawning an object in that family.
    • [FIX] Families reported object counts incorrectly.

    Editor

    • [ADD] Bracket matching and syntax colouring in parameters dialog
    • [FIX] Exporting an event with a trigger as a subevent, and within that trigger event having any other conditions resulted in duplicates. Now fixed
    • [FIX] You could rotate an object that wasn't rotatable (causing the bounding box to rotate)
    • [FIX] Python crash fixed.

    Effects

    • [ADD] Added new 'set' pixel shader (0.0).

    Programmer's Version: Basically shaders like 'magnify' render a distortion of the background on top of the background. This means if you combine a magnify and an opacity tint, you can get half of the distortion and half of the background which is useful. However, if the background isn't opaque (an object rendering on a layer of its own texture, or say a distortion rendering onto a canvas) you get 'doubling up' of pixels in the background and the pixels in the foreground. So 'set' ignores all the pixels in the background.

    Human Version: If you're pasting an object with 'magnify' onto the canvas to mix the pixels up, put 'set' on it to stop the pixels getting solider!

  • Construct is not fully translatable, so I would wait until better translation support is implemented.

  • Still opens OK here... (remember to describe exactly what you're doing as well - I just clicked the link and Construct launched the file, I didn't try the method you used at first)

    Try deleting the .persist file with the same name/location as the .cap. Or, load the .cap, and the project bar might have loaded it with all layouts closed (so it has in fact loaded correctly but only populated the project bar, double clicking a layout will open it)