...we have decided to focus on something slightly different than a game - creating a new FOnline development kit with improved scripts and tools. Our aim is to create a better starting point for new projects...

Do you think you could give us some more info about the process of what you plan to do? For example:

Do you plan to implement everything from scratch?

If so do you plan to implement it in AS or C#?

Do you plan to do some changes in hardcoded part of the engine? And do you even plan to use CVET's engine or create a new one?

Do you think you could give us some more info about the process of what you plan to do? For example:

Do you plan to implement everything from scratch?

If so do you plan to implement it in AS or C#?

Do you plan to do some changes in hardcoded part of the engine? And do you even plan to use CVET's engine or create a new one?

Can we help?

Thanks.

No, it's always good to reuse, depends how far we want to go.

I'm now pushing C# exclusive, as it gives more possibilities and frees of interop burden. (If we choose C# only, it would even differ from what's currently in Server/mono, because many things could've been done differently if AS hadn't been taken into consideration.

Starting new engine would be too much of a task. We definitely would want customized one, however, we're struggling currently whether to decide that backward compatibility is worth it, or not.

I suppose so, but that damned process of early decisions is somewhat blocking such initiative.

I'm now pushing C# exclusive, as it gives more possibilities and frees of interop burden. (If we choose C# only, it would even differ from what's currently in Server/mono, because many things could've been done differently if AS hadn't been taken into consideration.

Starting new engine would be too much of a task. We definitely would want customized one, however, we're struggling currently whether to decide that backward compatibility is worth it, or not.

I suppose so, but that damned process of early decisions is somewhat blocking such initiative.

1. That's what I am asking - how far do you want to go? 2. Thumbs up for that.3. From my point of view backward compatibility is not worth, if you would be forced not to introduce features that could be really helpful and better or pay for bad decisions made in the past. If you are trying to do better improved version of SDK, that should serve as a base for new projects, than screw backward compatibility and do it better. 4. I guess, it is not some decisioning that community could help you with. Or is it?

1. That's what I am asking - how far do you want to go? 2. Thumbs up for that.3. From my point of view backward compatibility is not worth, if you would be forced not to introduce features that could be really helpful and better or pay for bad decisions made in the past. If you are trying to do better improved version of SDK, that should serve as a base for new projects, than screw backward compatibility and do it better. 4. I guess, it is not some decisioning that community could help you with. Or is it?

1. Depends on 4:)4. I guess community could state their needs for better SDK, but we're aware of many needs and limitations ourselves, we just need to somehow fit it into 'roadmap' picture, so we are deciding about "how", and not necesarily "what".

I guess lots of it should be exposed outside, to give people a chance to contribute, but also some things cannot be, due to the "closed" nature of engine. And things like choosing scripting runtime is definitely an engine thing, but once it's chosen, things like utility classes, frameworks are definitely open things.

Aside from engine changes, it would be great to have SDK repository which does not require any external content, which we cannot include (maste/critter datafiles). That means new interface, tiles, sceneries, sounds, roofs, items, and so on - and all that need to be enough to fill like 2 maps for demonstration purposes. That's a faaar future plan, a crazy one, but it would need a lot help from the community~