Kibbelz

You can spawn and despawn npcs using events but thats about it.

You're using everything on the lowest layer possible, tiles you wish to render above other tiles put on the layer above the previous. Currently you have everything on the ground layer, keep your sand tiles on the ground layer and transfer your dirt transition tiles to the mask layer.

You'd have to write a converter for this. Why didnt your friend just connect to your server and make spells using the spell editor? 

The original post from @nippe  should require some form work and a few logic changes which ill try to get around to for 3.0. A full fledged UI based system for leveling resource proficiencies will not happen in Intersect. We have said no against this a long time ago but its probably buried somewhere. There are too many variables that force a fantasy orpg style game with this in the base client or its completely redundant in a space/futuristic styled game without renaming resource types assuming they want the system at all. Either way it will be released as a source tutorial by someone.

It should function exactly as you described. Could you send screenshots of your projectile editor and maybe a small video of in game results for replication purposes so I can fix this next patch.

I always personally remove solid players from any of my personal projects for this exact reason. However a lot of users like this feature, I'll look into adding an option in the server config files for next patch. @MiniGrief Post this in the suggestions section of the bugs/suggestions as a reminder for me in case I forget.

The quest editor is currently under developmentand has been disabled until completion. It will become available in later versions of Intersect, we also support data transferral between different versions of Intersect with database converters so you can develop without worrying about restarting with each new version.

Hmm, i downloaded the latest version and its not anywhere. We'll include it in the next update.

Visual studio 2017

Not too sure what you're asking here. The quest editor will allow more advanced quests alongside making them faster and being fully integrated within the event editor. Fundamentally you will still be able to make a quest with just the event editor however we plan for the addition of quest logs on the client UI. Only quests made within the quest editor will display in this quest log.

I may be wrong here but I think there is an indoor map property with disabled day and nights. I may be wrong, if so we need one.

Not yet, Once Intersect goes open source you will be able to code this yourself or follow a tutorial by another member on it. I assume it will be one of the first since its quite simple and a frequently requested feature.

hmm this is because resources, npcs and players are children of the entity class, in order to save time coding. Hence they share the same damage calculation function and thus critting is somewhere in there. Admittedly, this isn't intended within the design. I'll remove it for next patch, if people wish to keep critting on resources, just comment the an if statement.

There are many ways, through events using the give item function, spawn the item on the map via the map attributes, shops or by the source code if you want to code something custom. Source will be released on Intersect release

@jcsnider tagging jc so he'll read this later, we could potentially add a delete account on the menu of the client. Currently the way to delete accounts is to use DB Browser for SQLite or another database editing program. Open the users table and all of the character tables associated with that account and delete the record. Intersect should have this in the future, definitely as an admin tool.

My thought process on doing it would be a client and server merge running all server code on separate threads, removing all data transfer code and all packet sender methods, just call the packet handlers passing in the packet, hence skipping the TCP. I could just re-direct directly to the handler methods passing in the data as parameters to be more efficient and clean. I doubt I would use method 2 since it would be boring to re-write each handler one by one for barely any efficiency bonus'.
 
i'm open to debate but that's how I personally would do it, @jcsnider will probably find a better solution or someone with more patience who hasn't been working on Intersect for nearly 2 years now

Hi, as of yet there are no plans for scripting in Intersect. Intersect right now is in closed source alpha, it will become open source at Release which will be about a month from now.

You cannot change the size of a single map, all maps have the same static size. You can change this static size however we highly don't recommend it. However to get larger maps you can connect your map with other maps with our seemless map system! Ingame the player can run between maps connected in this way.

It says here that resources will be automatically updated too.

I forgot to announce this but the cliff autotile is fixed for 1.6

There are only so many bugs someone can fix which is why we have you guys to find them so we can squash them!
 
@PhenomenalDev There is a limit to what you can do without creating graphical reliance. What that means is, lets say we have a Zelda spin attack. You need the animation frames for the whole attack, even the character frames as well as the paperdoll/animations. Adding the ability to create such spells with no free to use graphics with enough resources to make a good game limits an extreme amount of people on this forum. Assuming you have no pixel talent, that would also include you. So now we have an engine that only ~1/100 users here at AGD (since we have barely any artists) can actually make something with, that is a terrible design flaw. 
 
If you're not satisfied with how combat works in Intersect, I suggest you go make your game in Eclipse or Orion+. Either that or release your own source tutorials of how you know combat should be done.
 
@WereAlpaca This is probably because the animations you're using have a lot of "white space" between frames which can cause offsets. The animations are programmed to be in the centre of the tile, not the character. if the character is 64 pixels high and the projectile shoots out in a line in front of it, it will shoot out from the bottom of the character. This is because in an ideal world everyone would be using 32x32 sprites, of course thats never the case. Also depending on what animations you use and what sprites you use the positions of projectile to character will vary, By adding offsets in pixels in the source it will put the projectile in the right place! As stated many times before, we can't accommodate all graphic types which is the danger of advanced combat with more diverse graphics!