jcsnider

Need to use post, not get.

The server listens on all addresses, so inputting the Hamachi address into your client's config is all you need to do. Your server will still contact our servers through the internet to provide 'useful information' such as your public ip but that can be ignored. If you are unable to connect via the hamachi address that means you have firewall issues on your pc or antivirus programs blocking the connection.

Latest build is 0.6.0.124 from Oct. 6

To communicate with the server and modify live game data you should use the API.

Not in Intersect until we open source and someone custom codes it.

We are not trying to make rebranding the client difficult. We do not have access to change the icon at runtime. The only options are resource hacker or changing the icon that's within the source. Wait for source and this will be easy. We cannot make it easier in the meantime.

Player boolean variable. Make the spawn condition of the event being that the variable is false. At the end of the event set the variable to true and it won't ever run again.

Not if you're changing tile size, only map size. If you change tile size without changing the number of tiles horizontally or vertically on a map then the only thing you might need to delete is the Editor/resources/mapcache.db file which will automatically regenerate.

https://docs.freemmorpgmaker.com/upgrade/upgrading.html#upgrading

.Net Core is awesome. Moving to that is a stretch goal of mine. As for DX, a lot of the users who cannot run the client with OpenGL wouldn't be able to run it on DirectX either. If it's absolutely critical for those with PC's 10 years old or older to play your game then you can use an old VB6 engine, or create your own DirectX Intersect clients when we open source. I think it's also important to note that for the clients on the borderline who could play your game if it was DirectX instead of OpenGL are on such old hardware they wouldn't be able to enjoy the game from a performance aspect anyways.

That is a reported bug that we are working on fixing. When fixed we will update the issue here: https://tracker.freemmorpgmaker.com/jcsnider/Intersect-Engine/issues/31#issue-31

Use the event category

You gotta send them a new client if you update any graphics, ui, resources, etc. If they are missing files then you need to get them to the players with a new download.

No. You need a large png image with equal sized frames side by side and then use the animation editor:

Unpacking another games assets for any reason is not something we will support here. If you have no ill intentions then just reach out to the games owner.

On the download page there is a changelog button. Set that to 5.1. Then at the bottom of the page there will be a With version Beta 5.1: Download button.

Simple answer: No.

I didn't touch on CsHtml5 because I don't think it has any chance of working for Intersect specifically. It could never automatically translate stuff like MonoGame that utilizes OpenGL, and in my opinion you'd be better off rewriting the client from scratch in pure js before attempting that particular option. Releasing the source early, even under an NDA isn't something I want to get into. We're already super close to the point where we are going to release it to the public anyways. Just a little more patience

We're not saying that you can't take Intersect's source code and migrate it in various ways to run on Android, IOS, or even in Web. And in the process of developing Intersect I have attempted all 3 at various points in time. [Android, Web] The Intersect Client is written in C#, but only uses libraries that are compatible with Mono (a cross platform .Net framework) so we can have Linux and Mac support. Several technologies exist already that allow C#/Mono code to be cross compiled to web assembly or similar to run in a browser. Unity does that, for example. If you wanted to get Intersect's client running in a browser or on a mobile device in the future you're best bet is migrating the code into a Unity project, and then using Unity to compile for mobile and/or web. Alternatively, MonoGame (which Intersect already uses) offers project templates for mobile devices, and web is in the works. Nothing is as simple as copying some code over and watching it happen though. Here are the early challenges I faced when attempting this task: Unity: All rendering, audio, networking, and input functionality must be re-coded to hook into Unity's systems. Project assets must be imported into a Unity project, a script would be needed to configure the proper settings for each graphic. Shaders would have to be rewritten for Unity. Loading of graphics, and other resources would need to be rewritten for Unity. Unity Web Export: All the Unity challenges above. Server and client would need a new socket system since html5 only supports websockets. Performance in browsers is pathetic. Content size/memory limits which would make games extremely limited, or only allow games to be played in web on high end pcs. Unity Mobile Export: All of the Unity challenges above. Code required to hook into mobile keyboard. (Not easy, or bluetooth keyboard required) Entire UI would need to be redesigned in a mobile friendly way. (Would take forever) Crashes when trying to update ui from networking threads or when networking threads try to check Unity.Time -- lots of function rewrites would be required to get around that. MonoGame Web: Simply not capable at this time. Their web deploy side of things isn't advanced enough yet. All the same challenges faced under Unity Web Export would surely apply here anyways. MonoGame Mobile: Code required to hook into mobile keyboard. (Not easy, or bluetooth keyboard required) Entire UI would need to be redesigned in a mobile friendly way. (Would take forever) Packaging assets is annoying and difficult. Performance is better than Unity mobile, so that's actually a good thing -- but I believe less devices would be supported (especially on the Android side of things) Bottom line: It is possible to get an Intersect client running within a web browser or on a mobile device. I have done both at one point in time. (No, I will not share my work/code in that regard, nor does any of it work anymore anyways.) Getting the Intersect client to run on mobiles/consoles/or within a web browser requires rewrites of major functions for each platform including rendering logic, audio playback, network sockets, ui design, input handling, etc. Make no mistake, the work involved is long and hard. You're effectively rewriting the most complicated portions of the Intersect client which means the skill required to make this happen the same as developing the entire Intersect engine itself. Cross platform support for this community beyond Windows/Mac/Linux is not one of our goals, and that is not something I'd expect to change for a very long time. I'll encourage other developers to tackle this once we're open source, and I will be available to answer questions here on the forum, but beyond that you all are on your own. Edit: Obviously a complete client rewrite/port to a native language for your target platform (ie javascript for browser) would result in the best performance at the expense of the longest development time. I don't foresee anyone attempting that anytime soon though.

Fonts for individual UI elements are set in the client/resources/gui/layouts/*.json files. Open any of the client/resources/gui/layouts/game/event jsons and search for sourcesanspro to see what I mean. The font you want to use must be put in there.

That is unicode character U2665: The source files for the Beta 6 fonts are here. You need to add the following character range to each font file and then rebuild using the content program as described above: <!-- Heart Symbol --> <CharacterRegion> <Start>&#x2665;</Start> <End>&#x2665;</End> </CharacterRegion> Then overwrite your fonts with the new ones generated. Edit: Updated the OP with a link to the Intersect-Assets sources branch which contains the sourcesanspro font source files.

No. This is not a goal of ours. Only Windows, Mac, and Linux support for the foreseeable future. Unlike the Eclipse era it's actually somewhat of a feasible task with source, but the skills required to do so are the same as developing your own browser client from scratch -- it won't be remotely easy and it will be fairly time consuming.

@panda and @Kibbelz are also developers of the engine with full access to the source. They would release the source and likely continue working on the engine in the event of my untimely demise. It's all coded in C#.

Thats the required process to generate fonts, and the only way you're gonna get the extra characters you want. So read it over a few times, actually give it a try, and then if you get stuck show us what step you're on, what's going wrong, and ask any questions pertaining to that process and we will try to answer them.

Only other thing is making sure that the clients and server are all the same exact version. Every number must match or the handshake won't work. Maybe try running netdebug again as well to see if its changed.