HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - _Omzy_

Pages: [1] 2
I was struggling with this issue all day and figured out why this shared function wasn't being called despite setting appropriate replication parameters for the noderef and its fields and assuring the replication group was working with the correct client destinations. In the end, it turned out that my noderef inherited from multiple classes and one of the other inherited class method scripts had the shared function _OnReplicationFieldUpdated.

If your _OnReplicationFieldUpdated function is not being called, be sure that your noderef doesn't have any other inherited shared functions of the same type (check all parent class method scripts). There can only be one!

EDIT: Jrome pointed out the _OnReplicationFieldUpdated entry on this wiki page holds the answer: http://hewiki.heroengine.com/wiki/Replication_Script_Interface

Called on ClassMethods scripts for classes (OR the first ancestor class that implements it) on the node that contain the field. Only called when the source field definition has Change Callback set to true. These callbacks happen for value changes after _OnReplicationNodeAdded (i.e. they are not called for Initial Set updates) is called and will happen no more than 1 time per class that makes up the node (i.e. the base class and each GLOMmed class assuming they or one of their ancestors implements the function).

The new material overrides functionality is very useful and speeds up development. I am requesting the following 4 functions be added to further add to our arsenal and speed up art pipelining. These functions are mostly already available for terrain texturing:

1) UV Scale slider
2) Normal map slider
3) Specular map slider
4) Tint masking each texture

The current workflow when we need to alter any of these parameters is to re-open the max file and make manual adjustments, or edit the textures and refresh them in the repo. This takes considerable time and would be insanely faster with sliders. We build some of our structures using modular building kits in Unity and then export them as single building objects into the engine. It would be nice to scale these UVs quickly in the engine (like a rectangular prism of wall or roof that has been stretched). If we decide to use a single wall asset but create different sized walls, this stretching occurs in the engine, which would require us to create multiple different models with different Hero materials, but if we had sliders, we could use the same object with different instance properties and save the player some lag. Additionally, it would be very useful to be able to apply a diffuse/tint color to any of the textures. Obvious utility would be importing a grayscale roof shingles texture and tinting it red, blue, green, or any other color to have a multitude of available roof colors for structures with only a single object import.

Thanks for reading!

If this is possible to add, it would be a great improvement--would save us the time of having to edit the DDS spec levels manually, and in some cases, changing the .max Hero material texture pointers  :D

General Discussion / Re: Missing worlds and worlds down
« on: Jun 27, 15, 02:19:19 PM »
I have the same problem.

General Discussion / Re: NavMesh & Pathing Issues
« on: May 26, 15, 08:59:48 PM »
Thanks for the replies Krun! I'll have to put some thought into how to smooth things out and fix the grounding, so once I work it out, I'll try to post whatever fixes I come up with.

EDIT Here are my issues:
1) Some AI's do not activate properly after being awoken by $AiControl._GetOrMakeAiAgentRootNode()._WakeupAllAgents() in HE_PostOnAreaLoad of E_AreaClassMethods. I have found that postponing this awakening and doing it manually via script command (for testing) has allowed all AI in the area to awaken properly (Solved).
2) NPCs are not grounded properly
3) NPCs take very non-smooth paths during pursuit using E_AiStatePursue

General Discussion / Re: NavMesh & Pathing Issues
« on: May 23, 15, 06:22:20 PM »
Thanks for the info Krun,
I've looked into those resources and understand the asynchronous nature of path requests and such, but what isn't clear in the references is how to solve the basic issues of npcs snapping to the ground (you mention modifying clientside scripts, but where?) and npc path smoothing. When I use the path panel to capture a FROM and TO point, the paths generated look very nice and follow the curvature of my hills. However, the paths generated from PathToPoint, which uses a $PATHSYSTEM request for a path, appear to be straight lines. Even after reading the available information, I am still scratching my head.

Regarding ground snapping, I found this old thread of yours, but it doesn't mention what the eventual solution was: https://community.heroengine.com/forums/index.php?topic=4831.0

I realized im having the same issue WorldWideZ had in his first post of this thread, which he also did not post a final solution for. A call to $PathSystem._PathSystemGetPath( me, me.E_phParameterSet, start, point ) where me.E_phParameterSet is set to $PathSystem._pathSystem_GetWalkableParameterSetHandle() is made. I have verified that the start and point vectors are good inputs with distance between them between 0.5 and 10 game units on average. The resulting path from _PathSystem_PathComplete contains path._psrPointList that is empty 99% of the time, and 1% of the time has a real path. That 1% of the time is responsible for all character movement, but many of my npcs are just standing there because they are 'blocking'.

General Discussion / NavMesh & Pathing Issues
« on: May 23, 15, 01:54:35 PM »
Hi guys,
Forgive me if some of these things have been posted before--I searched but didn't find anything related except some recent problems with paths ignoring models. I'm not sure if these are new since the recent update, are intended functionality with an explanation, or are actual bugs. Without further ado:

1) The navmesh doesn't seem 'complete'. When I turn on the visualizer, it looks riddled with holes like this one that seem non-intuitive. Surely this would have consequences in plotting a path down this actual path? I've given the PathMaker plenty of time to generate this area's paths as I've not modified the dat in days, allowed the world to sleep 2-3 times, and I see no dirty regions.

EDIT: Found this line under Path Planning panel:
WU_TestArea  (+): TaskNumber 11, BUILDING: status: BackLinking node 38702 of 49026. : /world/areas/9223372057044021587/area.dat

Would it really take this long to build the navmesh on such a small terrain? Its just a small testing area.

2) Using the default clean engine implementation of E_AIStateWander, E_PathingHelper, which utilizes its PathToPoint method, which calls '$PathSystem._PathSystemGetPath( me, me.E_phParameterSet, start, point )', these mobs are moving from random point to random point. You can see that they seem to float and sink into the ground as they path between points. Why are they not using the points from the navmesh to determine where the ground is?

EDIT: Upon turning on cached path visualization, all of the paths are straight lines instead of paths following the navmesh points

3) Using the default clean engine implementation of E_AIStatePursue, E_PathingHelper, which utilizes its PathToPoint method, which calls '$PathSystem._PathSystemGetPath( me, me.E_phParameterSet, start, point )', I ran into this mob's aggression radius, he followed me to my stopping point and accurately made it within combat range. However, his path was very erratic, and he turned multiple times before settling on a final point and heading towards my character. Is there a way to smooth this out?

Just now getting into this part of AI, so thank you for any responses!

General Discussion / Dynamic detail bug since Quartz.d
« on: May 14, 15, 09:32:07 PM »
We've noticed some glitches in the dynamic detail since Quartz.d. It seems the order of rendering is off, so that dynamic detail layers closer to the camera are rendering behind other objects, including other dynamic detail, and bodies of water. Hair seems to be affected similarly. This was tested in a seamless environment and reproducible under any circumstances--not simply those mentioned in this previous bug report: https://community.heroengine.com/forums/index.php?topic=4285.0

He's still not able to login to his heroblade or repo, but is able to login to the dashboard. I've fixed his permissions as well. He's going to try resetting password.

EDIT: Ok, he got in, thanks!

Hi there,
One of my developers was unable to login following todays update for the authentication servers, however my admin account logged in just fine. His error said "Login Failed. You may have entered an incorrect username or password, or your connection to the server may have been lost." He didn't change anything and had auto-login on, tried restarting Heroblade and his PC with no effect. So, me, being the quick-fixit man decided to play around with his permissions in the dashboard to try and reset his account somehow and accidentally ticked the 'Active' box, which immediately removed his name from the list of existing users. I am unable to view his name and see no options to show inactive users or reinstate them. I tried re-adding him, and it says his email already exists in the list...Help please!


General Discussion / New DOM Suggestions (Quartz.d)
« on: May 06, 15, 12:44:12 PM »
There have been a few threads around with DOM glitches since the latest update. Let me add a few other DOM suggestions that I've been brooding over. These are not meant as complaints, just suggestions to improve workflows:

  • New DOM requires client refresh after every Copy to Client command (old DOM auto-refreshed client) -- slows workflow significantly
  • New DOM does not save panel layout as the new DOM windows are not considered panels, slows startup
  • Also these new DOM windows, not being panels, aren't dockable to each other or other panels, impairs aesthetics and flexibility
  • Resizable elements, especially field box for classes (I know this issue has already been mentioned and scheduled for the next update), impairs aesthetics and slows workflow
  • Default archetype should be set to data rather than empty, like the old DOM. Now you have to select archetype for every single class definition, every spec, every dec, dec helper, etc. Significantly slows workflow
  • Read Only checkbox should only need to be unchecked once (currently has to be unchecked on server and client, which is different from before update), slows startup
  • Loading bar now replaces text in search box which is a bit disorienting, especially after long hours when you forgot what you typed, impairs aesthetics
  • After creating/updating definitions, there is more lag than before, or at least it appears that way. I'm not sure if code has become less optimized or algorithms have been swapped out, but it is definitely noticeable--I used to not have to wait after creation to start editing, significantly slows workflow
  • Copy to Client/Server should allow a 'forced' update even if destination classes/fields already exist, rather than just supporting creating new field/class definitions. For example, if I create a spec decorator on the server and prematurely copy it while empty, then add 10 fields to the server definition and try to Copy to Client again, I get an error that this is not possible. I'm sure this is intentionally designed to prevent overwriting existing data. There should be a checkbox with a checkmark allowing forced update (default unchecked) in this scenario so I don't have to manually add every field twice. This could prompt the user for verification and could either copy the entire class/field or just add fields that are non-existant in the destination but exist in the source, which is a compromise that avoids the issue of overwriting data altogether.  significantly slows workflow

Thanks for reading!

Art & Art Pipeline / Re: 3D software alternatives
« on: Apr 21, 15, 01:52:08 PM »
You should be able to get 2016, 2015, 2014, and even 2013 of max and maya with a subscription (2013 only if you have an annual sub, all others with any desktop subscription):


Customers with an active monthly, quarterly or annual Desktop Subscription for software listed in the Product column are eligible to download and use previous releases of Autodesk software.

Available Previous Releases
Autodesk® 3DS Max 2016   Autodesk® 3DS Max 2015, Autodesk® 3DS Max 2014, Autodesk® 3DS Max 2013*
Autodesk® Maya 2016   Autodesk® Maya 2015, Autodesk® Maya 2014, Autodesk® Maya 2013*

Design & World Building / Bugs in Merge/Re-grid Tool?
« on: Apr 09, 15, 01:48:16 PM »
Hey guys,

I've been having issues with the merge/regrid tool. If I've got a mesh thats, say 192x192 standard res made up of 36 nodes (6x6), each 32x32 verts, and merge regrid it with a node size of 192, it should create a single node from them that is size 192x192. However, it is creating one that is 187x187.

Additionally, when doing the opposite conversion, from a single 192x192 to a 6x6 of 32x32's, it doesn't split up evenly and actually makes a mesh thats like 194x194, leaving slivers of 2x32's along 2 of the sides.

Has anyone experienced or is able to reproduce this issue, and are they bugs?


One more possible bug: using the merge/regrid on nodes that are not at standard resolution does not result in the desired behavior. If you are trying to regrid a terrain at HALF res, it is necessary to convert to standard first and re-align and re-height all nodes in the group before using the tool, which can take loads of time if you have 3x2 areas, each of which is 6x6 blocks of 32x32 verts. Thats 216 blocks i have to line up and re-height =(

Perhaps this can be fixed by writing an algorithm that scales the entire terrain (all nodes) down or up when changing resolution rather than it scaling each node individually, or at least an added tick-box to add that possible behavior in case this was intentional design.

Ok, may be the quickest solved question ever. Selecting all nodes and scaling the height, then using 'undo' fixed them all. Thanks anyways, maybe this will help someone out in the future  :D

Our team has been working on seamless terrain with a node size of 32x32 at HALF res. We've run into a little issue where the westernmost nodes of each imported and regridded heightmap aren't lighted properly in the default setup. The meshes are fine, its just the way the light hits them. This is most evident when zoomed out but is still obvious close-up. It persists when different textures are added. We've tried shutting down the edit instance and bringing it back up. If anyone has run into this issue and has a solution, please chime in. Here's a pic with 4 seamless areas stitched together, note the westernmost blocks of each area:

Thanks in advance!

Pages: [1] 2