Posts by Conno

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Moo is very unlikely to be ported - I think we all know this; but there should be some support in F3 for networking, other than pre-defined protocols/messaging systems designed by someone else. Something akin to MooSock.

    At the same time, Lacewing/Bluewing has a place at the table too. Not everyone wants to design an (or integrate with) complex protocols.

    TCP is in Lacewing. Are you referring to a raw TCP protocol?

    Raw TCP might be slightly outside the scope of Fusion-based applications, but the ability to send ascii encoded byte arrays, and decode the other side, with the buffer firing recieving events based on a predefined delimiter. There's a mammoth amount of applications and games that use plain text protocols - interfacing with these would be essential for a lot of development. It also means not relying on a backend server that's part of Lacewing that may or may not be suitable for scaling or everything that one wants to achieve with their application.

    I do the vast majority of my development in C# and FlatRedBall now due to limitations in F2.5 -- such as working with raw TCP and UDP -- I'm big on multiplayer, online gaming, and network play, but I'm hoping I can return to Fusion in a future version. Not having the ability to communicate on the Internet the way I want to is one of the things that would prevent a return to Fusion for me.

    If I do return to Fusion for clients (which I hope I can); I would still build servers in C# and keep the vast majority of game-based logic there, while using the Fusion app as a shell-like client with very little logic.

    Disclaimer: I haven't looked at Lacewing for years as I've always stuck with Moo for this functionality. It may well support something more open than what I remember it supporting years ago... which was a pre-defined client/server protocol messaging and backend rooms/channels on shared public or self-hosted servers (which again had to meet the standard setout by Lacewing.

    As far as I know, Moo isn't supported in F2.5 as it was superseded by Lacewing, though I'm unsure if this will be supported in F3.

    Not sure how it can be a successor or replacement when it's incredibly limited in comparison.

    Let's hope F3 has an option to work with TCP for transfer of data. Some of us want/need to communicate with established protocols.

    I'm 100% certain one of two things is true... F3 will support 3D to at least the same capacity as F2.5, or Clickteam are the worst 'business' that ever existed. You don't release a new iteration of a product that removes a major chunk of functionality that was present in a previous iteration of the same product and expect it to sell.

    For something like "Finn and Jack were here" would be fine to use, it's a couple of generic male names, you can't copyright "Finn" and "Jack". Your argument would be that the reference is coincidental - like how most fictional TV shows end with a disclaimer). However, if characters are depicted visually - then you're gonna need permission. You also wouldn't get away with non generic names like "Mickey Mouse"; but you would get away with "Pluto" - because it's a planet and again your argument would be that the reference is coincidental.

    The answer is "it depends"; and to be safe - you'd have a copyright lawyer sign off on anything before you release with the intention of making money.

    Not sure if this thread is still active or if suggestions are still being taken:

    One stand-out thing that's missing from HTML5 Exporter (and for app/game development in 2015 is absolutely necessary) is some support for WebSockets; the ability to open a connection to a remote server/port, and send/receive data/bytes/strings. I'm not talking about support for some primitive hard-coded protocol like lacewing; but generic websocket support (which could be used for lacewing, smtp, irc, pop3, http or <insert any other protocol that exists, or one that's still to be invented>).

    Personally I am putting together a prototype for a browser based version of a popular multiplayer competitive game - then it occurred to me, there's no web sockets in the HTML5 Exporter.

    I've uploaded a video to YouTube demonstrating the problem; after putting the current values into a string; they did appear as floats -- but they're definitely not being used as floats within the standard objects.

    Note that the HTML5 implementation seems to scroll properly (layers); but the actual movement of items down the screen is not working correctly - they move far too quickly.

    This is the same basic conditions/events for all 3 builds; no third-party extensions in use.

    Note that the Windows build is the intended function.

    Please login to see this link.

    Any input would be much appreciated.

    We are looking at it, Amazon too, the issue is with some transactions as low as 0.99 cents companies like Paypal take to much out of it with minimums. We will keep you posted Tisnart!

    Best way around that is the same way every other company deals with micro-transactions; allow people to deposit $10 or $20, then spend it in chunks as credit.

    I'm using a basic implementation of sub pixel movement, and a basic implementation of positioning layers.

    Both of my implementations work fine in Windows - but not in Flash or HTML5, where everything is jerky is out of sync.

    It feels like, to me at least, that floats/decimals aren't supported in Flash or HTML; or I'm missing something completely obvious.

    For example:

    Code
    Set Y layer 5 to YDistance * lyrGetLayerYCoef( "Layer object", 5 )

    Where YDistance Is a number is like: 5.3423

    A separate issue is moving an object using the following 3 conditions (Which again, works fine in Windows)

    Code
    Always - Add YSpeed to YOffset("Someobject")
    Always - Set Y position of Y("Someobject") + Int(YOffset("Someobject"))
    Always - Sub Int(YOffset("Someobject")) from YOffset("Someobject")

    Where YSpeed is a number like 0.734 or 1.232

    Again, this works fine in Windows; but in HTML5 or Flash, undesirable speed hikes are noticed; there's no fluid speed increases/decreases as YSpeed is changed - just jumps between 1, 2, 3, 4 pixels per frame.

    Is anyone aware of these issues - and are there any (I hate this word) workarounds?

    Nah, it's not really a concern, 'free' just means unallocated. In your example above 980mb has been allocated but is available for use ("available" memory usually retains cached data of other applications which can be discarded to be used by a more active application at any time). You can always increase the size of your Please login to see this link..

    Once an MMF game is loaded into memory, a lack of excess memory shouldn't cause slow down (unless its a absolutely huge game loading resources on the fly)

    Your CPU should run most Fusion games just fine.

    I am not a consumer of budget cards in general; but a (what NVidia considers to be) budget card from the GTX 600 or GTX 700 range would be more than ample; however - when you say 'budget', I'm not sure how cheap you mean.

    nVidia have always been just a step ahead of AMD as far as I can recall - and as Snail suggested, always much more expensive! nVidia cards also run much hotter than AMD cards; and I think you would be hard pushed to find a semi-decent one without a fan, again because of how hot they run.

    If your games run better with all other programs closed, then it sounds like your CPU needs the upgrade; what CPU is in your PC?

    Physics are now a base 2.5 feature. They aren't extensions. They aren't optional. That is part of my gripe with it still being for sale and stating "Works with 2.5" ... neglecting to mention excluding all new built-in features/physics (which might never be done). I don't really care when the Flash Exporter is updated; I am more eager for the acknowledgement that it will be done.

    HGF, as I said, I agree you have some valid points about Lacewing. However, for some of us, Lacewing is far too restrictive. Perhaps there have been no requests for such an extension because MooSock works perfectly fine - and such networking is generally only needed in Windows builds.

    As I posted in the beta section of the forum; it would be nice to have some primitive networking built into MMF (enough for raw tcp/ip and udp sockets) - both listening/sending and the ability to send/receive strings/binary data.

    To answer the OP, though, MooSock works fine - so long as you're building your game for Windows.

    As for other exporters, we're going to have to wait for some kind of native support in MMF.

    Moo doesn't support those, either, last time I checked. It also isn't supported any more, so if you encounter a crash, it will never, ever get fixed. Ever.

    A new extension would have to be made for sending pop3, http, irc, or custom protocols. Some of those might not even be possible at all for an MMF2 extension, such as a custom protocol. Also, Lacewing works well enough that you shouldn't need to send stuff with those protocols for an online multiplayer game in MMF2. I think you may have missed the point of using Lacewing or Moo, Conno. And I think you ignored the fact that the person who made the thread was almost certainly making a game and not an application.


    MooSock allows for tcp socket connections; you can send and receive whatever data you like outside the confines of a "lacewing"-like inflicted protocol. All of what I listed are completely possible with MooSock - I speak from experience. An extension capable of making a TCP connection (or UDP packets) and sending strings or binary data is all thats required for any type of protocol. MooSock exists exactly for that purpose.

    If you're designing a game client for an existing protocol - then Lacewing wouldn't suit your needs. If you want to design a scalable backend server for a game you are creating, then Lacewing could work - but so could your own creation. The point I was making here is: Lacewing can be restrictive. I don't doubt it suits the needs of many people; but to proclaim that "Lacewing" is the way forward for networking is absurd.

    Being unnecessarily restricted when designing anything is annoying.

    Incidentally, MooSock could be used to connect to (and utilise) a lacewing server, amongst thousands of other networking protocols.

    Yes, but those are really old and unsupported. Lacewing is what you should be using now. :)

    And if we want to interface with another protocol such as pop3, http, irc, or a custom one? Forgive my ignorance if Lacewing supports standard tcp sockets/udp packets, please enlighten me. If not, then Lacewing is definitely not what we should be using. Being locked into a protocol seems like a step backwards (as "customisable" as it may be, the premise is the same)

    It is already compatible with Windows, HTML5, iOS, and Android. Just not Flash, yet.

    I would reply to your entire post point by point, but most of it is superfluous. I have no problem with Flash not being supported "yet.". My problem is that we're being told that it might never support Fusion 2.5's features. There are no promises. Which is insulting. Not least because the product is still for sale but MMF2 isn't.

    Marv, I understand what you're saying - but MS has less control now than it ever has had with shrinking browser shares, more people shifting over to Apple devices and operating systems, so on and so forth. Does this mean its time to drop the Windows run time too?

    I don't doubt Flash will eventually see the end - but that end isn't now, nor is it next year.