uMMORPG Official Thread

Expected: bool respawns of 'false' and respawn time of '0' should not allow a monster to respawn. Monster should not respawn.

Unexpected: But the monster does respawn because Monster.UpdateServer_DEAD()'s check for respawns comes before the check for gameobject destruction. It will still trigger on a 0.

User solution: Assign any number to respawn time while 'bool respawns' is 'false'. The gameobject will be deleted before the respawn time expires. Easy solution but one that has to be remembered by the user.

Developer solution: Add a respawns check (as I suggested) OR rearrange Monster.UpdateServer_DEAD() so the gameobject destruction is before the respawns check.

 

Great find, thanks! Will be fixed in V1.33. If you can't wait then replace the Monster's EventRespawnTimeElapsed function with this one:

Code (CSharp):

1. bool EventRespawnTimeElapsed() {
2.     return state == "DEAD" && respawn && Time.time >= respawnTimeEnd;
3. }

 

No, not a fresh uMMORPG project. But I don't think I change anything related which will cause this problem.

It's quite weird, I still can't figure out what caused this non-syncing of SyncListStruct in client.

But this link's answer works for me perfectly. It means after I changing the public class "SyncListInv : SyncListStruct<Item> { }" from the Item.cs to the Entity.cs, the Client is syncing correctly.

http://answers.unity3d.com/question...ts.html?_ga=1.153950456.1798397746.1462257768

 

Update: uMMORPG V1.32 is now on the Asset Store. Changes can be seen in the first post!

Working on the next version already.

 

Any chance any of these are coming soon?

Soon:

• Quests that are not repeatable
• Crafting maybe
• Resource gathering maybe
• Sound effects
• Equipping items with Skinned Meshes (Jackets, Pants etc.)
• Party system maybe

 

One step at a time. I always wanted to get the existing features perfect first.

Right now, I am working on the UI, trying to make the big UIRefresh and NetworkManagerMMOUI components simpler.

 

I`ve already tried that on one my test project and the simplest way was to add "monster" called plants or ores or whatever they are and set their damage to 0. And attacking them you can gather them (dont forget add droppable items - plants, ores or other gathering worth loot items). Also you want to add new skill category - gathering and make changes on scripts to check that skill usage. For example you don't want to use gathering skill to kill other monsters or via versa. Or if you dont like to make categories then make new boolean and check that during skill casting against monster.

 

Can we do a very simple pickup item? like spawning a gameobject on server and let player pick it up?

 

Hi guys, I'm having some trouble trying to make this package work with online WebGL clients. I setup a server in my computer to run some tests and I have the following results:

Desktop client: Works fine on local network and online
Webgl client: Works fine on local network, but doesn't work online. Console says it can't connect on my IP.

Do you guys have any idea what could be the problem?

 

This requires raycasting (physics) and it adds many more GameObjects and scripts to the scene. It's possible though, I only selected the current method because the implementation was simpler, and because I kinda like that World of Warcraft style loot system.

Yes, enable 'use websockets' in the NetworkManager. Then it works.

 

Thanks for the quick answer, but actually I have already enabled it in my server.

 

Can you show us the exact error? Do you have anything in the logs perhaps? Did you try a more simple UNET test project to see if you can actually connect to your server with websockets / if it's a UNET bug?

 

Enable websockets in server and client, both are required.

 

Progress Info: our Destroy Canvas bug that prevents us from upgrading to 5.4 was given another look by QA and confirmed: https://issuetracker.unity3d.com/is...-sharedgfxbuffer-unshare-sharedgfxbuffer-star

 

Update: V1.33 is now on the Asset Store. Changes can be seen in the first post!

Note that upgrading your custom projects might not be 100% easy this time, since UIRefresh was broken down into several smaller components.

 

Quite interesting approach for UI elements I`ll try test that new version later.

 

That was a hugh script glad you broke it down to more user friendly size. I hope you do that with the player script at some point as well. Maybe move the trading to its own and maybe attributes to their own script. Then we could customize attributes properly.

 

I think so too.

Yes it was.

By the way, the new UI scripts aren't just broken down into components. They are also attached to their corresponding UI elements now. So the Skillbar has a UISkillbar script, etc. This is different from before, where all the UI code was attached to the canvas. And it is different to the old OnGUI system, where UI could would be attached to the player/monsters/npc/...

I tried all kinds of different approaches for the new UI. Attaching everything to the player, or parts to the monster/npc, or split it into components and still attach it to the Canvas, etc.

The current approach is really great. It's the first time that I am actually happy with Unity's new UI system in uMMORPG in terms of simplicity / elegance.

About the player script: it used to be split into different components a long time ago. In theory that's a good idea. Practice showed that all those GetComponent calls and caching made it too annoying. There's value in being able to access '.hp' and '.mp' easily every time, instead of using 'GetComponent<PlayerHealthMana>().hp'. That was my impression anyway.

 

uMMORPG Anniversary Post
It's august again, one year after I started working on uMMORPG. I will use this post to give a quick look on the past, present and future of uMMORPG.

The Past
My dream always was to make my own MMORPG, and I (we) are closer than ever before.

My story started just like most people's stories here. About 10 years ago I downloaded this MMORPG that would change my life. The intensity of this virtual world was something beyond any other game that I ever played. The friends and the experiences during that time will remain in my memory forever. When I learned programming in school, I knew that I would make my own MMORPG some day.

In the next 9 years, I got a computer science degree and learned an endless amount of programming languages, ranging from C/C++ to Java, C# or more esoteric languages like Lisp, Erlang and Haskell and game engines/frameworks like XNA, Ogre3D and many more. A lot of the engines and frameworks were great for MMORPG clients, while a lot of the more esoteric languages were great for MMORPG servers. The projects became too complex too quickly though, often ending up with 50.000 lines of code or more. The biggest lesson learned here was what's commonly known as the KISS principle. Simplicity is the key for the lone wolf programmer. It's the only way for indie MMORPGs.

UNET
In August 2016 I found UNET. Back then, UNET was just released to the public and was full of bugs like the UnetWeaverError that would randomly occur and mess with everything. I started playing around with it by putting health bars onto the spheres in the UNET move demo that was posted on the forum. While unstable, the simplicity of it was fascinating. SyncVars, Commands, RPCs and keeping the server & client in one project were exactly what I was looking for all those years, without knowing it.

I developed a love-hate relationship with UNET early on. I encountered many critical UNET bugs like ReadBytes out of Range and the SyncList Name Bug and reported them on the forums, with no success. Talked to the UNET developers, with no success. Reported them to QA, with no success. Some day @gintautass from QA stumbled over them on the forums and at least confirmed them, which was a big relief. This was around the time that @seanr left the UNET team. For those who don't know, seanr was working on the HLAPI, so our biggest hope to get those critical bugs fixed was now gone. Nothing happened to those two bugs for over a year now. UNET is starting to get some other improvements though, so that's at least something.

uMMORPG Progress
Boo vs. C#
The first uMMORPG versions used a very different technology than today. In the beginning, I used the Boo language for scripting. Boo is very similar to Python, which makes it a bit shorter than C#. It also has list comprehensions, which make all kinds of list operations much easier. Unity doesn't seem to care about Boo anymore though and even removed the 'Create Boo Script' option from the menu. I liked Boo a lot and since a lot of people love Python, it would be smart to put more work into it. Until then, uMMORPG will use C# for better compatibility.

OnGUI vs. UI
I also used the OnGUI system before, which was really neat since it was a immediate mode system. I worked with a lot of UI systems like WxWidgets, Qt, TKinter, Delphi, Borland C++, and so far Unity's old OnGUI system was still the easiest to use. The whole user interface lived in the code's OnGUI function, there was almost no state, hence less complexity. A lot of people requested the new UI system, which also worked better on mobile devices, looked better and was faster. I switched to the new UI system after a while, and while I still don't like the extra state, it's okay now.

ScriptableObjects vs. SQLite vs. XML
The database system was also changed a few times. Originally uMMORPG used ScriptableObjects, which as it turns out couldn't be written to from builds. Another approach was SQLite, since setting up an SQL server would have been too complicated in the long run. SQLite worked, but it was slow and we still had to deal with all those SQL queries, especially after changing items or skills. XML turned out to be the simplest and most easy to use choice. Everything is saved in a humanly readable file, the serialization happens automatically and it's really fast. Perfect for an indie MMORPG.

Art
I got my hands on a few decent monster, npc and player models as well as a few environment models early on. I still like them today, the animations work greatly and nothing is overly complicated.

Asset Store
uMMORPG was selected for the Madness Sale and as Asset Store Staff Pick a bit later, which got the attention of a lot of other MMO developers here. A lot of those developers found a few bugs here and there, which greatly improved stability.

Content Management System
An MMO also needs a good enough content management system (website), which I have been researching in the background for a while. I found a decent system that can be hosted in the cloud by the developers, so we don't have to worry about hosting, security, updates, etc. The system is still missing a way to purchase item mall currency, the rest works great.

Finite State Machine vs. Deterministic Finite State Machine
Each entity had IDLE, UPDATE, MOVING, CASTING, DEATH, etc. states, just like today. I used a finite state machine design in the beginning, which was great. The events were handled in a weird way though, some events would be ignored in some states completely, which sometimes caused weird situations like monsters still targeting their attackers after respawning. Using a deterministic finite state machine turned out to be great. Every state contains every single event now. The code is much simpler, and everything works better without any weird situations.

Game design
Of course, there were also countless smaller game design features that were implemented or improved. At this point, uMMORPG feels really great.

A few old screenshots:


The Future
As mentioned before, I will try to keep uMMORPG as simple as possible, so that everyone can understand and modify the code for their own MMO project. That being said, there are still a few small features that will come, most of them are on the roadmap in the first post. Other than that, I am also looking forward to the UNET improvements during the next year. Besides new features and bug fixes, the current set of features will also be fine tuned to improve the overall feel. One example are the damage popups, which work fine but don't feel that fine. I am currently playing around with a different color and font style, while also adding a fade effect to make them feel more smooth. More changes of that kind can be expected. The environment art might be replaced with some real MMO environment art too.

UNET's simulation server is another highly anticipated feature that would come in handy in order to split the load between several different servers. As for scripting, native F# support would be really great to make the code shorter and more simple. I will also continue with the content management system research in the background. A good forum can be used for announcements, community building, bug reports, support and internal development. That's all we need for an indie MMORPG anyway, so we are almost there too.

For my own MMORPG, the ideal technology would be:

• UNET + Simulation server
• F# or Boo as Scripting language, because C# is too verbose and not very functional
• Immediate mode user interface, like the OnGUI system
• Forum hosted in the cloud, with a way to buy item mall currency

Summary
All in all, I am very happy with uMMORPG. Always using the simplest solution for all design challenges turned out great. uMMORPG is very stable, given the state of UNET, Unity and C#.

Big thanks to everyone who purchased uMMORPG, to everyone participating in the forum discussions and helping each other out, thanks for the bug reports and the kind words. I wish you all best luck with your own MMORPG projects and hope to see many of you still around for the next anniversary post!

Now back to the code...

 

Anyone else getting "Did not find target for sync message __" warnings on the client when using missile combat? Seems to be caused by the target dying while the projectile is still in the air. I guess I didn't notice it before because I was busy running one instance with Server & Play. You can see them by running a Dedicated Server instance and playing with an Archer client in the editor.

 

Yes, nothing to worry about. What you mentioned is exactly the reason why it happens. Those kind of situations will happen because of how UDP works, and it's fine too, since we don't rely on the packet order like with TCP. I am sure the UNET developers will remove that warning some day.

 

Progress Info: I am currently experimenting with OnGUI and UI again. I want to have both systems working for uMMORPG to be able to compare them in detail.

This is not a feature announcement. Right now, the only goal is to figure out the best solution for my own MMORPG. I don't want to force anything onto you guys with uMMORPG, but at least we can have a discussion based on some real data soon.

Screenshot:

 

Hey @nonom,
I'm trying to do the same thing you did, but no luck here.
I have enabled WebSockets on both the server and the client, but I still can't get the WebGL to connect to the headless server. Desktop builds (without websockets) work fine though.
Did you have to do anything else (other uploading the WebGL into some host and setting up port forwarding to the headless server)?

 

For Your purposes im sure it would work fine as you can make a layout through code that works with your specific design, but Please don't think that even if you get a nice working system with OnGUI that it would be a better choice for Us.
There is a reason everyone wanted to go away from it, as it is far too rigid to deal with. As soon as i want to customize my UI Layout , IM @#&%$ed unless i decide i want to write/edit a bunch of code to get what i need.

 

That was Unity's promise for the new UI, I was excited about that too since having less code is good for uMMORPG. Turns out we do need to write lots of code for the new UI too. As a matter of fact, we are currently at 1092 lines for UI and my 95% finished OnGUI implementation is at 1021 lines of code. So roughly speaking, both systems need the same amount of code in uMMORPG, so that's not a deciding factor.

The next question is, which code is simpler? As I mentioned above, I will have some real data on that very soon and we will be able to compare UISkillbar with OnGUISkillbar etc.

Another question is, which architecture is simpler? UI currently has 1092 lines of code and lots of state in the Hierarchy. OnGUI has no state at all since it's immediate mode. In other words, to add a new UI we have to write code and manage stuff in the Hierarchy. To add a new OnGUI, we only have to write code.

Another question is, can UI deal with dynamic state? OnGUI doesn't care if your quest list has 1 or 10 or 100 entries. With the new UI, you need to: create a quest prefab, instantiate enough of them into the Hierarchy, delete all the unnecessary ones (in case we had 10 quests last time and 9 quests now), and then update all of them. I see this as the biggest issue. It's also the reason why the NPC had a list of quests before back when we used OnGUI, and why it has only one quest now.

Again, I'll have more data on that soon.

 

To my knowledge we cant just grab an OnGUI element and resize for customizing a UI Layout on screen. Like i want my health bar a bit bigger, so i just grab and resize it in like 20 seconds. What about scaling to proper screen size like going to mobile device, which is nearly automatic with Ugui.
I would think as you said having a prefab for skills, quests etc.. and then doing a check of how many quests or skills are currently active or available, and then spawning the correct amount shouldn't bee to hard.(just spawn the correct amount everytime that window is opened) Ive seen that done in other UI Assets like Simple IAP https://www.assetstore.unity3d.com/en/#!/content/12343
that worked very well as you would add or take away items.

I do agree there is more initial setup time involved with the new UI versus coding everything for Vis2k , but once that is done, customizing should be much quicker for everyone else here. I would have thought your goal would be to make a very flexible System that for everyone who bought it, could take and make it their own. I have to say that i have yet to see a versatile and good looking ui system from OnGui ever....so the thought of going backwards 2 years with the UI system has me a bit confused really. But i guess we will see how your new test system works, Maybe i'm completely wrong.

 

Hi @PedroRamos I did nothing else, just opened the port 7777 in the sever firewall and started a websockets server. Send me a pm and I'll try to give you a hand.

At the moment WebGL is at an early stage, so don't expect to have a good performance. But more improvements are coming. Check this link as reference http://forum.unity3d.com/threads/official-multiplayer-improvements.390823/page-2#post-2755330

EDIT: The images needs to be optimized for WebGL but it's not a problem to run the server itself. Take care adding custom code using System.Threading because it's not supported in WebGL and check the Firebug console to debug any error.

https://docs.unity3d.com/Manual/webgl-building.html
https://docs.unity3d.com/Manual/webgl-performance.html

 

Hi, here is a problem makes me very confused:
1. Build & Run the World scene as a dedicated server, and play a client using unity editor;
2. Stop the client, wait until the player disppear on the server;
3. Replay in the unity editor again, and the player doesn't show on the chient but still shows on the server.

I thought the right story is the player can show himself on the client, no matter how many times I restart it.

 

Which Unity version do you use? I remember reading something about some kind of UNET reconnect bug in the changelog a while ago. I believe someone even mentioned it here or emailed me about it too.

 

I use 5.3.6f1 unity version and v1.33 ummorpg.

 

I just finished the update to the latest version of 1.33. Removing the UIRefresh was a huge change. It took me hours to properly update my game to the new version, but think it was worth it. By dynamically populating the content, instead of using a fixed number of slots, you've prevented us from hitting walls later in develop. And now that the code is distributed into multiple parts so we can look for performance issues with more precision. Great job!

On the subject of UI vs. OnGUI, in the past I was neutral but now I have to fall on the side of staying with UI. Despite how important performance is to me, that is not my main concern.

I'm developing games with Unity because I want to create my own game and I want to develop skills that will help me get a job if my game doesn't take off. In the game industry, knowing legacy systems has little utility. 90% of the work is in development of new games, not support for older ones. True, some companies may use an old code base for their games, but if it is a Unity development house then they are likely using the newest versions of Unity.

This is part of the reason I was willing to use a framework built on UNET, despite it's beta state. You know better than any of us how Photon would have been more stable to develop with as a mature technology. But my goal is to learn what is new and study what will be in demand in the near future. And UI is the same, an imperfect technology, but one that learning and using will show evidence of an up-to-date skillset.

Anyways, I'm looking forward to the comparison data you discussed sharing with us. But I think you may be wasting your development time trying to eke out performance from the UI. After all, each client only has one UI to deal with. True they may have several windows open at a time and if each had one less update call that would help, but the real performance saving is in more efficient Entities (Monster, NPC, Players). Savings found there would be multiplied by the number of entities in the game. Fifty monsters with 30% less updates per frame would make a huge improvement.

I know many of this framework's users are clamoring for new features, be it parties, guilds, pets, housing, crafting, what have you but I think your interest in making what it already has more efficient is a good idea. I just disagree that the UI is where to look for that savings.


----


I would like to bring up one other issue here that doesn't seem to be discussed much and that is integrations.

A framework like UMMORPG is a massive undertaking for a single developer. By building your own inventory, AI FSM, NPC conversation system, minimap, chat system, etc. each of these systems will, by necessity, be less feature rich and expansive than other systems available on the asset store. It's simple math: other asset developers spend their time developing one system while you're developing a framework of a dozen systems.

Of course, I am happy with many of your systems and don't need a better chat system for instance. But I don't feel that way universally and I'm sure other customers agree. I am willing to trade performance for a more feature rich conversation system like Pixel Crushers's Dialogue System. I think time you spend on integrations would help your product be seen as a more stable, established product.

I imagine you might see this becoming a backhole of lost productivity. Even an easy integration requires time away from your game and requires updates later when the developer changes something. Also the requests for integrations for popular assets might not end, becoming a long line of “Playmaker PLZ” whining.

So do it for yourself first. Is there an asset you would want to use with your game? Something that would take too long to build yourself? There has to be something.

I'm bringing this up because I want UMMORPG to succeed and from watching the community for several years I've come to the conclusion that a lot of asset store products succeed by playing well with others. I know it is always a trade-off and making single-player systems work with multiplayer might be more work than building from scratch, but the whole reason we, the Unity community, use Unity is so we can leverage many of the tools available in this huge community. Otherwise, we could be using Ogre3D or something equally bare-bones.

Well, I spent many paragraphs typing what could have been said in five sentences, but I'm making what I know will be a difficult argument, so thanks for bearing with me.

 

Progress Info: V1.34 was submitted for review. Changes can be seen in the first post, mainly the 5.4 upgrade, better looking Damage Popups and a long list of small fixes and improvements that I noticed when playing around with the UI during the last few weeks.

Please wait for the V1.34 release and try again with Unity 5.4 then. Chances are that it's fixed. Perhaps try the latest 5.4 patch release too.

Thanks.

Good point about using the latest technology to gain experience for jobs etc., haven't thought about it like this before.
As I said above, I don't want to remove UI from uMMORPG. I am just playing around with OnGUI again to learn what's best. If the OnGUI solution ends up being useful, then I uMMORPG might come with both UI and OnGUI in the future, UI most likely remaining the default. I want to get the code to the point where moving to OnGUI is as simple as removing the Canvas and adding a few scripts to the player. The uMMORPG core features should really be user interface independent. You can see a few changes going towards that direction in the V1.34 changelog already.

About integrations: I can see how some might be useful for MMOs. My main is to get the core features perfect first, and add as much from the roadmap as possible. At some point, when things are mostly finished then we can take a look at integrations again. Right now, this would probably be a nightmare like you mentioned, with version upgrades, bugs in other assets, etc.

 

In terms of UI, I am almost always doing a code driven approach that uses assignable controls that are exposed in the component and then use lambda created events and listeners and then properties that update any display objects. That makes it very easy to maintain and a snap to wire up to new objects. Any grids or layouts use prefabs for the objects, again using code to connect it all.

 

My two cents,

In the past I've bought some of these cool assets. They are useful because integrate pretty well between them to make the things fast for beginners, mainly focused for non-devs but devs too learning best practices. The most part are multi-purpose and brings a bunch of dependences who makes the game size grow fast too packaging if dont have care. Anyways any bridge always is good to experiment and bring new features for more advanced users.

But as developer I like to do the things myself and understand every line, uMMORPG is going well on these terms and being well-documented. I want to see new features, but also optimize what we have.

About the GUI I would like to use the new one but I feel we need to wait Unity devs release these fixes. https://issuetracker.unity3d.com/is...deactivating-worldspace-canvas-crashes-editor.

NOTE: My "Wall of Text" skill already is lvl.2

 

Glad I could help you level up.

 

Could you show us an example of lambda created events and listeners?

 

V1.34 has a workaround for this bug. It uses TextMeshes again for 3D text.

 

Sure thing. This is untested, but should give an idea what it is doing. My other half is that I use those out vars to send to properties, and let the properties modify any UI elements that I need to connect to that value/change. It turns the whole setup into very efficient event driven updates.

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3. using UnityEngine.UI;
4.  
5. public class LambdaExample : MonoBehavior {
6.  
7.      public Button buttonTest = null;
8.      public DropDown dropdownTest = null;
9.      public Slider sliderTest = null;
10.      public Toggle toggleTest = null;
11.      public Text textTest = null;
12.  
13.      void Start()
14.      {
15.         buttonTest.onClick.AddListener(() => { textTest.text = "Button Click"; });
16.         dropdownTest.onValueChanged.AddListener((out) => { textTest.text = "Dropdown text is " + dropdownTest.options[out].text; });
17.         sliderTest.onValueChanged.AddListener((out) => { textTest.text = "Slider value is " + out; });
18.         toggleTest.onValueChanged.AddListener((out) => { textTest.text = "Toggle value is " + out.toString(); });
19.      }
20. }

 

Ah yes thanks, we already do that in uMMORPG. Seems like that's the best way to handle the UI events.

 

Progress Info: V1.34 was submitted for review with a long list of improvements:

• Upgraded to Unity 5.4

• Renamed Chat.ChatAddMessage to Chat.AddMessage

• Renamed ChatEntry prefab to SlotChat

• Fixed <= usage for skillindex <= skill.sCount instead of < skills.Count in Monster and Player scripts

• Added active checks to UILogin and UICharacterCreation to only update when necessary

• UIMinimap: removed unnecessary GetComponent<Text>() call when accessing levelName

• NPC Dialogue is now only updated while the panel is active

• CastCheckTarget now sets target to self first if needed for heals, buffs, etc. and player sets targetNext=target before calling CastCheckTarget. This is a very elegant solution to enforce the right target and then jump back to the previous one after the skill cast was finished.

• Damage Popups improved and feel better now
  • The are TextMeshes instead of UI Texts again to avoid the Unity 5.4 Destroy Canvas crash
  • Red, italic font
  • Shadow effect
  • Fading
  • Velocity decreased slightly
  • They spawn on top of the entity now

• NameOverlays are TextMeshes again to avoid Canvas Destroy crash in Unity 5.4

• UIShortcuts tooltips added

• UIEquipment parse last noun algorithm moved to Utils

• Utils.IsCursorOverUserInterface checks UI and OnGUI now

• Camera doesn't zoom in when scrolling in the Inspector anymore (thanks to 5.4)

• Entity.hp and Entity.mp never return anything bigger than hpMax or MpMax to avoid cases where HpPercentage would return values bigger than one after a buff anded.

• PlayerDndHandling switched split and merge comments, which where the wrong way around

• PlayerDndHandling is not a NetworkBehaviour anymore and is UI/OnGUI independent now. Also modified UIDragAndDropable to work with the new one.

• Moved all UI scripts into a UI folder for consistency

• Moved Utils.BalancePrefabs function to UIUtils for consistency

• ConsoleGUI renamed to GUIConsole and moved into OnGUI folder for consistency

• Improved tooltip readability by using a darker navy tone background color

• NPC Quest dialogue now shows the active quest status if the quest was accepted before. This makes sure that the 0/0 Monsters killed status is the up to date one.

• NPC Trading UI sell slot now has a valid check to avoid possible issues where the item might disappear from the inventory but would still be shown in the sell slot.

 

I have a question, I want to add Speedboost to the skilltemplate, where do I need to add this new variable/value?
It's so that I can make both a charge skill and mount for instance.
I guess that would be a good way to work around it.
So charge would give a speed boost for 2 sec and you need to do it on a target..
By using the mount item/skill I could simply equip it to a new invis slot and have a permanent speedboost for as long as the mount last?
The Health per sec attribute how can it effect monsters and not myself? thanks in advance!

 

Another suggestion; Is it possible to add a "grid" based inventory in the future so you are having the possibility to have multi-slot items? In the current version you can just use 1x1 slots instead of 3x3, 3x6 etc.

 

Adding more skill boosts is usually easy, as you may have noticed when looking at how buffs works. With speed however it's a bit more difficult, since entities don't have a speed property, they use the NavMeshAgent's speed instead. So to add a speed boost to buffs, you would need a 'speedBoost' property in the skill classes (just like other boosts) and then use Entity.Update to set the NavMeshAgent's speed to 'defaultSpeed + boost from all active buffs'.

Buffs can only affect yourself right now, a player can't cast a buff on another entity. This is because skills and buffs are all in one list right now, we simply set 'buffTimeEnds' to actually start a buff. You could possibly modify the code to have a list of active buffs and then add to that list when casting, but you'd also need to remove it etc., it's just more complicated.

We are a bit limited since we use SyncListStructs, which are always lists. You could however interpret it as a grid, the same way you can use any list as a grid. For example, use the first 4 entries as first row, the next 4 entries as second row, etc.

 

Thanks for the reply! I have yet another question. Swimming. Is there a way to use a boolean with the animation controller to trigger swim animation if so where would i add the oncollisionenter?
Also any programmers freelancing programmers familiar with ummorpg? A lonly 3d artist here

 

I made a speedboost buff for my game. Here is some code you may find useful:

Player.cs

Code (CSharp):

1.    
2. // The code for calculating the speedboost.
3. // Requires a buffCustomValue float in the SkillTemplate
4. public float buffSpeed
5.     {
6.         get
7.         {
8.             // calculate buff bonus
9.             var buffBonus = (from skill in skills
10.                              where skill.BuffTimeRemaining() > 0 &&
11.                              skill.name == "SpeedBoost"
12.                              select skill.buffCustomValue).Sum();
13.             return buffBonus + 1;
14.  
15.         }
16.  
17. ...
18.  
19. // Change the Speed float in the Animator Component to multiply buffspeed
20.   //GetComponent<Animator>().SetFloat("Speed", agent.velocity.magnitude);
21.   GetComponent<Animator>().SetFloat("Speed", agent.velocity.magnitude * buffSpeed);
22.     }

NetworkNavMeshAgent.cs

Code (CSharp):

1.     void Update() {
2.  
3. ...
4.  
5.         // Checking for speedboost. If it is active, change the player's speed.
6.         if (agent.tag == "Player" && agent.GetComponent<Player>().buffSpeed != 1.0f && agent.speed > 4.5)
7.         {
8.             agent.speed = 5 * agent.GetComponent<Player>().buffSpeed;
9.             //Debug.Log("Speed is " + agent.speed.ToString());
10.         }
11. // The system needs to constantly set it back to the original 5 to prevent exponential speed accumulation.
12.         else if (agent.speed != 5){
13.             agent.speed = 5;
14.         }
15.  

Hope this helps. Let me know if you have any questions.

 

The entire system uses navmesh which doesnt really support swimming(i dont think?). But there might be a way to offset the player model from the character controller& add a swimming animation. The character controller would still follow the ground ,when you enter a water trigger area. Maybe @vis2k. Has some ideas on this.

 

Amazing will test out

@JBR-games i belive the simple way is to use costs with baked navMesh to either slow down and trace specific speed or have a constant trigger to keep a "swim parlameter" to just do the animation part in the Animator and use like -1 in Y-offset? Alltho would the OnCollideEnter be best placed in entity?
You can just make a plane furterdown in the water to make it look about right with some tweeking.

Fun to work around things, next thing shall be fishing ._.
Guess a work around with skillcur could work..

 

Yeah a plane further down under the water would definitely work. You could do a navmesh.layercheck to start different animations if on say swim layer.

My last post was more towards being able to float or move around in the water instead of being stuck at a set height once in the water.

 

Never heard of navmesh layercheck, is that a thing? Where would i implement this check? In navmesh.cs thing? Im on my phone atm.

 

The name might not be correct but you can do a check and see what layer you are currently on. When i get home tonight ill find the code and post it here. Im at work on my phone also hahaa