This is probably something that is not implemented yet.

Meanwhile, you have two options:

Either modify the ajax plugin and add options for modifying headers (shouldn't be that hard to do, but requires you to learn a bit of the SDK)

Or set up a server-side request proxy, that takes your request, modifies the headers, and forwards it to the destination - you'll need to know a server-side language (such as PHP) for that.

I recommend the first option.

You might have more luck in the correct subforum:

Help Wanted

What if I don't want to animate my particle, but still want the ability to load it's single image from URL?

You wanted a use case:

Say you have a platformer where you can have a floating companion, which emits particles when it floats around. You can unlock new particles for that companion, without having to regenerate the game's spritesheet - super useful for when you want a special "christmas edition" or similar.

Ashley - why don't all objects that display an image have a "load image from URL"? Sounds like a nice case for standardizing, as that same use case could be applied to everything.

> LennardF1989

>

> Did you somehow miss Ashley's response? The SDK is perhaps your best bet.Her response is the reason as to why I am bumping a topic from 2012: The SDK doesn't support it.

Hence I am asking her to reconsider and expose edit-time drawing functions to Behaviours for debugging purposes, my example being one way to apply it.

Ashley is a male, btw.

Also, bump. I see no reason why behaviors shouldn't be able to draw - some possibilities have already been mentioned: a debug behavior, health bars, a speech bubble surrounding text (that has the benefit of being compatible with other text-modifying effects)

So,

Fimbul From what you've said, am I correct in saying that I can design a peer that functions as a server using WebRTC?es! We'll see what Ashley comes up with - in principle, there's nothing in WebRTC preventing you from doing it all within construct.

Ashely would a Construct 2 app be able to successfully/feasibly function as a server using its upcoming p2p features with WebRTC?he only problem with that is whether you mean a normal server (one of the player is the host) or a dedicated server. Both are feasible with construct 2, but for a dedicated server you'll either have to pair it up with a tracker (that is, a non-construct server responsible for handling handshakes between peers), or Ashley will have to come up with a server-side exporter (maybe node.js?), which is a lot tougher (But I would pay a hefty sum of money for a node.js exporter that could handle application design instead of purely gamemaking - might be a way to expand into the corporate market Ashley? *Wink*Nudge*)

Matter of fact, I do have another question, can/will/does C2 have the ability to interact with MySQL? So say I create a peer server, could I then store/retrieve, say, user data using MySQL?

Would this all (peer server & MySQL) even be worthwhile?nless Ashley makes a node.js exporter (in which case you'd probably have plugin wrappers for the npm database drivers), the only way you'll be able to talk to MySQL is via the traditional method of calls to a webserver. If the "server" isn't publicly available and is just a construct app that you leave open in chrome (quite the flimsy architecture if I may say so), you could design a pretty simple PHP proxy to forward ajax calls to MySQL - it would probably need less than 20 lines of code total.

It would definitely be worthwhile! For more complex games, say MMOs, you'd probably want to ditch construct for the backend though (unless there's that node.js exporter)

Ashley, but do you even have to have a switch point? Wouldn't it be better if, instead of having the "use collision cells" be a project-wide setting, why not let it be a property of the turret/LoS behavior?

Wouldn't it be better to just optimize the turret behavior and line of sight to work better in those edge cases? I.e. switch the turret off from collision cells if it detects that it's doing extra work...?

Fimbul, I beg to differ. I?m not a game developer, I work with servers and datacenters for a living so I actually know when I tell you that most people want servers for their games and p2p has all type of troubles for data connections unless your requirement is just for 2 persons and packets are low on bandwidth. also work with servers, datacenters and clusters, and I can tell you it's looking more decentralized every day, because monolithic servers simply cannot scale.

Not only I see people asking this all day but like I explained before, even Microsoft switched Skype off from p2p. Most people using Voip which is going to be similar to game requirements, also use a middle server, usually a voip provider, and do not usually call from machine to machine.icrosoft moved skype to the cloud. The p2p remains, but now the peers are microsoft's own servers. Even if Microsoft ends up completely centralizing the whole Skype infrastructure, so what? As if Microsoft were the king of good decisions - see Internet Explorer.

On the Google presentation they even explain for WebRTC, you will need a server to handle multiple connections because its just the nature of it once its scales.ou need a server for it to work at all, not just for scaling it.

This may work wonderful for someone playing chess with another party, but not if you want to connect 100 players together playing the same game at the same time. The network will start to drag the slowest link of all.hat? If that were the case, bittorrent would only download at the speed of the slowest peer, and that is clearly not the case.

Its not correct than p2p is the shortest path either because that is not how networks are deployed worldwide.

...snip...

In this small example case if your target is Latin America or have players there you would have a server in the US and it will be faster for everyone vs players connecting with each other.layer A in Brazil connects to Player B also in Brazil via link C in the US (p2p-model)

vs

Player A in Brazil connects to server C in the US, which then transmits data to player B in Brazil (server model)

How is that any faster? Worst case scenario, they are exactly the same. In all other cases, the p2p model is faster.

Besides, like I said three times before, you can mix the models:

Player A in Brazil connects to Player B also in Brazil

Player A in Brazil connects to Server C in the US

Player A sends data to both B and C

Server C sends player A's data to player B

Player B receives the data from player A and, much later, the same data again from server C

In player B's perspective, data received directly from player A isn't trusted implicitly, but is used for interpolation. Data received from server C is authoritative, and is used to determine serious state changes, such as kills, health, etc., and also as a backup should the direct link from A to B fail.

Even if they are local players (same city, state, etc) you will not achieve high bandwidth outputs with p2p, it will work for a couple of players tops because each user needs to stream their connection up to the network, and even in countries with high Internet speeds this is usually very low. Example, last time I was in Germany on a residential ISP connection download speeds for a 25 MBPS connection, only had tops 1 Mbps upload, now try connecting all your players via 1 Mbps. For a small game that only sends positions this will work fine, but it will cause problems as players increase. Now most games only send a few details, like position, score, etc, but still if latency sucks in one user it will drag the whole game down, this means all players.Mbps uplink is more than enough: you could send 10kb packets every 10ms (that is, 100 frames per second) - 10Kb of UTF8 text allows for between 10240 and 40960 characters. Those are insanely high values for a packet, and you could probably get away with something like 128 kbps.

On real live games this means suffering connection drops, slow games, etc.

Is that all worth?

In particular because setting up a server is so cheap and you will need to host scores, registrations, and probably a website anyway for your game.

I?m not against P2P but if P2P worked for most things we would not have datacenters and servers today. P2P like its name says is peer to peer, and is usually designed for person to person. I imagine someone developing a game will need more than just a couple of players, that is the idea of multi-player. If you are creating a big multiple player game there is no way P2P will ever work.

If you only need to test it with a coupe of people or are playing with friends, then this will work just fine.2P is not exclusively person to person, though, it's peer to peer. Must I repeat myself again? A server is just a special type of peer!

If you want to argue with me that you can't possibly program a server in construct 2 to handle thousands of players, then yes I agree, but no one said you had to do that. Fire up node.js, it can talk to c2 just fine.

But for open code like HTML5 games usually are, a server side is the only way to protect the game, just like no one would allow users to view your asp or php code that runs on the website. The server side option is the only realistic option that can potentially avoid some of this cheating problems.id you read what I posted? It makes no difference whether the game is made in HTML5 or C++, and it makes no difference if the game is hosted on a server or on a machine in the client, the architecture is all that matters. If starcraft 2 needed server-side security to prevent cheating, it wouldn't have become the e-sport it is today. If bitcoin needed a server to provide security, it wouldn't be worth over $800 each.

Besides, no one said you can't have a server.

And good luck with anti-cheat using Javascript. There are client-heavy games that have succeeded in preventing cheating, but the only ones that come to mind are Flash games such as RotMG, which uses an insane AS3-specific obfuscation that JS will never have.o competent engineer will think a third-party anti-cheat solution is appropriate to an online game. You have things like GameGuard, PunkBuster, valve's VAC and blizzard's warden but all they do is create parallel markets for cheats. Cheating countermeasures must be integrated in your game's architecture.

Even if client-side anti-cheating solutions were a good idea - and they are not - there are no technical reasons preventing you from deploying your own JS-based obfuscation that runs circles around AS3 solutions - heck, you'll probably make a ton of money if you can do it.

Games like League of Legends have no anti-cheat programs - you can run cheat engine right along with it and it won't ever complain. Yet there are no cheats for LoL (except rudimentary tools that can't even be considered cheats). Meanwhile, gunbound has had decades of cheat signature collection and has tried many anti-cheat providers, but it's still a festival of aimbots and hackers. Why do you think that is? One word: architecture.

> ...snip...n a p2p system you often have a host and a client(s) - or at least from what I've learned in my classes - and if you figure out who is the host, and you are it, you can do pretty much anything unless you have a server to check it.ot at all. P2P simply means you allow clients (aka peers) to connect to each other. Like I said many times before in this thread, a server-client architecture can be achieved easily in a p2p solution, but not the contrary - hence Ashley saying server-based is a subset of p2p.

Besides, who said if you're the host you have free reign to cheat? Games like Warcraft 3 use that architecture and you cannot simply "cheat" the quantity of gold or wood you have: if you attempt to, the game desyncs and kicks you out (thus ending the game).

I'd agree that you could properly design a game to prevent the majority of cheaters, but the degree you could achieve is limited by using JS or using C2 for web-browser games.hat makes you think JS is inferior to anything else? Clients are self-contained, in order to cheat in a properly designed "pure" p2p game, you'd have to find a way to modify the code in the remote clients, which would require attacks of a magnitude far greater than simple game hacking. That is the same in all games, regardless of programming language. Making the game in C++ (for instance) would change nothing.

This book explains everything you need to know about game security - I highly recommend it

And then, only the host can mess around with things - and if you're playing with a cheating host, I guess you can just find someone else to play with.he clients can do their own verifications to see if the other peers (including the host) might be cheating. In that case(excluding certain kinds of cheats like bots), only the developer would be able to cheat.

Even if it has P2P capabilities that is no the way you want to go.

P2P does not work nicely in games and real time protocols because you can?t expect a certain quality in terms of lag, performance and speed. It may work great if your user A is in the same city as user B but go to hell if user C is in another part of the world with a crappy Internet connection.gh, no. If you broadcast your data to peers, it will still be faster than sending it to the server only and letting it re-transmit, regardless of where you are in the world. A straight line from A to B is always shorter than a line from A to C and C to B.

Finding or setting up your own server is just plain silly easy today and you will have so much more benefits, just use the same server where you are hosting your game.nd you'll still be able to do that with a p2p architecture, but you also gain the benefit of not HAVING to have one.

In P2P the server just acts as a hub to connect players together or initiate the handshake connection, but users are not connected via the server after it, but directly passing data between from one user to the other. This creates all types of problems.ou are confusing the handshake server, aka. Tracker, with the game server. You always need the tracker, but the game server is optional, and is just a special type of peer.

Sure for a "AAA expert commercial product" this might not cut it.

I don't see why it wouldn't cut it.

I suppose the main issue I and others are concerned about is security and cheating.

In a p2p connection, cheating is often as simple as loading up Cheat Engine and changing one or two variables. Obfuscation or no, this is incredibly simple and can take little no nearly no effort.ou can implement a completely secure game on a client-only p2p architecture (that is, one that has no "hosts" or "servers") - saying you can just "load up cheat engine and change some values" couldn't be further from the truth in a properly designed environment, that'd be the same as claiming you can edit the amount of bitcoins in a wallet or infect a torrent swarm with a malicious file.

Serverless has another major downside:

What about scores or leaderboards ?

User registeration ?

This sort of functionality, which generally goes hand in hand with online multiplayer or game play, will typically not be availble in a pure p2p gaming connection. (you can have scores and names exchanged between 2 p2p players, but not store it for later review or leaderboard purposes)

Ofc, you can have some alternate means, like updating through ajax calls and what not ... but then you would still need a server.ou provided the answer yourself. Ajax calls are more than enough. Why do you think you are constrained to one approach only? When we say serverless it means servers aren't required, not that they are banned.

Having an active socket pumping data back and forth in your browser can causse lots of slow downs.

Especially if your going to try more then two players.ebRTC is a new standard designed to avoid said slowdowns and offer performance.

Yep, I was just about to say that. P2P solutions can implement the authoritative server model, just as long as you find a way to make clients always connect to the "server peer" and recognize it as being an authority, while at the same time making it impossible for other peers to impersonate a server (this is all pretty easy to do).

Ashley - would you mind sharing what was wrong and the fix? It seems like it was a rounding error and could be useful to keep in mind as a javascript programmer