oosyrag's Forum Posts

  • Looks like a bug. The blue outline should be lined up with the red/yellow corner boxes. Have you tried resizing the window? Or maybe just rebooting.

  • Agreed it isn't recommended, but it is possibly workable. Most MMO's were hardly truly real time anyway, there was a lot of fudging going on.

    You can still get 6 states out of a single byte character rather than 8 with little work. The overhead of messages will always be a problem though, so you still have to weigh what data to transfer carefully.

    Anyways it would basically be pretty far outside the scope of a beginner, considering a normal multiplayer game is difficult enough to make properly as it is. Just throwing some ideas out as possible workarounds in case anyone really wants to do this with the capabilities we currently have. The general feeling I got was that there would be no more work done in terms of the multiplayer plugin, regardless of a new runtime in C3, so I'm not holding my breath.

    I also had some crazy ideas involving separate zones/hosts with agents dedicated to popping in and out of each server in succession to pass low priority data.

  • Set variable to len(TextObject.Text)

  • Try 0 spacing?

  • Difficult to diagnose without seeing how tilemap is set up.

    Are you loading the right image? Are your tile sizes, offsets, and spacing set correctly? Are you changing anything at runtime that might make it look different than in the editor?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Straight lines are easier - just use a series of rectangles with fade behind the player.

    Curves are harder, but you can do something like to make it smooth , just add lines between the circles.

  • The on created trigger is probably running before your myEnemy sprite has any properties.

    Try a different method, such as using a container, adding the create myFont action to the event that created myEnemy in the first place. The "wait 0" trick might work here too, if you put that above the spawn action.

  • You could simply pick a random x/y, then check if the tile at my is valid and repeat. If valid, stop loop.

  • I modified it a bit to try to account for commas within cells, but I didn't really test extensively. Give it a shot and make sure to proofread.

    Note this will now completely not work for .csv files that don't encapsulate cell data in quotations.

    Edit: Also will break if you have any newline breaks in cell data.

  • You can, but you'll have to build your own sync algorithm via messages rather than use the built in sync.

  • It depends if you're booting into the layout with the large sprites.

    Blank layout (fast load, no memory use) -> Layout with sprites (takes time to load sprites into memory)

    Is equivalent to

    Blank layout with empty sprites (fast load, no memory use) -> Load images via URL into sprites into same layout (takes time to load sprites into memory)

    The top setup will normally keep images in memory when moving to the next layout with the same sprites. Have you tried making the sprites global and/or using the persist behavior after loading from URL? That could possibly keep them in memory across layout changes.

    Generally speaking, it is advisable to design around a set peak graphics memory limit rather than try to fiddle with loading and unloading graphics into memory dynamically to try to get past memory limitations (Usually results in bugs and crashes and time spent with extra coding).

  • newt No actually it's not. Try making a blank project and put 20-50 1080p images in the files folder. Notice how previews boots instantly, and there's no increase in image memory use. Now place those same images in a sprite. Boom got yourself several seconds of loading, and that memory use's pretty big. Also done tests on HTML exports, and you can clearly tell the images from files needs to be loaded from the server. They're not loaded in the same way as sprites. Also if you have a text object print the image memory use, you will see it rise considerably once you use the "load from url" action. Restarting the layout makes it disappear, and the memory use is reset.

    This is the solution to making projects scaleble. This way you don't have load your entire game just to playtest that one level giving you trouble.

    You probably didn't understand what he meant... It actually is pretty much the same. Sprites aren't loaded into memory until they are required in the layout you load into. It is the same as On start layout, all sprites load from url. The benefit is that if those same sprites are used in the next layout after that, they are not unloaded from memory.

    Try putting all your large images in a sprite on an unused layout, you will notice if you preview an empty layout, those sprites are not loaded into memory.

    You use load from url on any given layout to spread out the loading process, so it doesn't necessarily have to complete all in one tick at the start of layout. This can give your users some heads up so it doesn't look frozen in the event of large amounts of sprites loaded.

    There are also advantages such as under the hood sprite sheeting that using the sprite object gives you. Regardless of which method you use, the sprites will need to be loaded in the end and your peak memory use will be the same regardless, so you still have to split up your image memory load across layouts anyway.

    Now if there were a specific action to UNLOAD a sprite from memory in a given layout at runtime, that would open up some possibilities in certain fringe cases.

  • The advantage is that you can decide for yourself which ones to load dynamically and which ones to load normally.

    Also, there are ways to restart a layout manually, so you never have to change layouts after your initial load. You'll just have to put some work in.

  • Use play at object, or play at position actions. This feature might have limited support depending on the browser.

    You can also add an "object is on screen" condition to have it only play when the laser is visible.