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 - ToY-Krun

Pages: [1] 2 3 ... 43
**Removed**  The last test resulted in even more questions than answers.
Will post if I find a concrete workaround or cure.

General Discussion / Re: Im having a problem
« on: Sep 14, 18, 04:47:20 AM »

But it will then say it must be started with the launcher, and you can just click okay/yes, and it will.

once it starts, you can pin it to your task bar.

Note, i placed an "*" above in the pathname, as that will be the number of the blade you're on, 20/21/22 etc

The reason its not simply in the HeroEngine folder is that there is are a great number of blades, all of which, that IF you have access to, will be installed to the "HeroEngine" folder, thus you'll find them in the folder with the name/number of that blade.

Hope that helps

Actually I should have posed this as a question rather than assume anything  :)

Is it possible that the assumption I made above is the issue, or is it that the x/z rotations are different somehow due to the 90 Degrees off character rotation?

Just curious!

I may use mono audio for the time being til this is sorted.


Hey guys, I finally found the cause of 3d sounds playing on the right, when they are on the left, and vice versa.

The long and short of it is, HE is apparently setup to use RightHanded coordination, where Fmod Studio is setup to use LeftHanded.  Im not sure theres anything on the licensee end that we can do to swap it, i assume it would have to be changed in the blade/client code where Fmod is initialized.

Heres where it is discussed on Fmod Support:
Look for this "FMOD_INIT_3D_RIGHTHANDED" in the answer, then click on the link there to see the full page:


Heres a ss off Fmods support for setting up Fmod Studio:

Will do, and yep, that would be a good repro :)

can confirm that allowing the EDIT instance to rebuild the navmesh, minus the tops of the caves, did work.  it resulted in "white" nodes, which are supposed to indicate a "Non" terrain mesh.    And, once i loaded up a play instance, the npcs were perfectly happy to path on this.   So, my guess is that underwater nodes (yellow) are getting ignored at least, not sure about water (blue) as they dont ever seem to get produced :)

I've tried every combo of walkable parameter set one can do.

Anyway, this will do for now, in the subterranean levels, nonTerrain works fine.

Everything else aside, if the pathing process in the back end would recognize the underwater nodes that are drawn by the navmesh, it would work fine on our end as we'd just use the yellow nodes the navmesh gives us.  my guess is that the pathing/physx server is missing those from its version of the navmesh.


There are options for this if anyone else has problems with pathing.
Reg sliced the cave into where the floor met the walls/top, so i deleted the tops/walls in the EDIT instance, and allowed the server to build the navmesh without it,  Then placed the tops where they should be via HSL when the area spins up (all but the EDIT instance).

However, if your cave or building has interior paths that pass over/under one another, those intersections will cause spots where the npcs won't stand/path.  if its not too big of a spot the server will direct them across it without using those path points.

Just thought I'd add that.

General Discussion / Re: [Resolved] HW vs SW mouse cursor
« on: Sep 13, 18, 06:18:15 AM »
Thanks a million Scott!  Finally got round to setting up the custom cursors in AoH, and this helped a ton.
I decided to go with HW cursors, for my use, i don't need the added benefits of the GUI elements.

(Yeah i know this is quite an old post but wanted you to know I appreciated it)

Design & World Building / PathSystem or Navmesh malfunctioning
« on: Sep 13, 18, 01:00:34 AM »
I've tested this for over the last year or so, each time trying something a little different just to make sure there was a problem and not just a misunderstanding on my part :)

The backend PathSystem (physx server) does not recognize path nodes marked as anything but terrain.
This is a major problem for needing npcs to path inside of buildings/caves etc.  or even beneath trees, as the navmesh beneath a large tree gets marked as being underwater (yellow) which gets ignored apparently by requests to the pathing system for pathpoints for npcs.

To run a quick test, go to the edit instance of an area and place some object above the terrain... just let it hover there, but leave room beneath it for an npc/char to walk (even an inverted heightmap will do).  wait for it to rebuild the navmesh, log out, and back into that area.  turn on "visualize navigation mesh".  you'll note that the nodes beneath the object you placed are yellow (according to the wiki this indicates "under water".  this happens under trees and inside buildings etc.  place an npc in the middle of this yellow patch, and he/she will simply stand there.  the result from the request for points to path, is nothing.  no point is found.  Be sure to make the object fairly large so the system doesnt pick a point outside of the patch of yellow nodes.

Have attempted using an override of the walkable parameters set and several other things, but no matter what nodes the npc should be pathing on, the pathing system doesnt return a valid point.

I have alot of caves, and in AoH there will be more area underground, than above (many levels downward).

I attempted to solve this by having Reg slice our caves and separate the top from the floor.  I then set the top portions to "PathingMode = Ignore"... well... then i enabled Live Region Updates and watched it rebuild the navmesh for the cave... bingo!  I thought, it rebuilt with "WHITE" nodes, which indicates "NonTerrain"... the npc did path then.... however, when I went to the EDIT instance and made these changes, The resulting navmesh was neater than before BUT  the nodes were once again YELLOW (underwater)...  This is where it seems wierd to me, i assume the same code backend produces the "temp" or "test" patch to the navmesh when using the Live Region UPdate.... so why does it and the actual navmesh rebuild, produce two very different outcomes?

Really could use things like this fixed :)  I realize there are other things going on, as well as work on the engine Upgrade, but would it be possible to get a list of "high priority" fixes, and push them out?

At any rate, we are working around everything we can, and will continue to do so, as well as offer our full support to the team for the work going on.   Just wanted to post this issue up so that it was known about and/or act as a reminder of it.


Need to be able to switch off specific (or even all) of these messages to the console from the backend.

certain external functions result in these messages being printed out in the console, and I need the use of one in particular, and even though I dont need to call it more than say.... every 5 seconds, I certainly could do without it spamming the console with this message, even if its only every 5 seconds.

Give us a way to turn off this callback message to the console for the following external function
Code: [Select]
external function UpdateAreaOffset(foreignArea as ID, offset as Vector3) as Boolean
I use this for our ship system as our ships are in special areas where the area offset of the ships area is adjusted dynamically by timer, and any clients on board the ship, must receive this offset update using this function.

Cheers for all the hard work going on!
I can live with it for now, but this would be an awesome addition :)

(finally have a near perfect ship system working with this, or I wouldn't ask)

Art & Art Pipeline / Re: Dynamic Detail "Popping" Issue
« on: Jan 30, 18, 09:26:55 AM »
I just realised that you had said :
Which is interesting because the grass originated from the area that i'm loading -into-.

thats wierd...  see if there are any error printouts in the console (black), especially related to dynamic details.

It could possibly be a "room" issue i suppose, might ensure that automatic room selection is ticked in the area panel/rooms tab.  though I've never seen that setting affect the dyd like that.

Just offering whatever comes to mind..  not sure many other folks have worked in depth with the dyd's other than Sar, and obviously she already knows about it.

Art & Art Pipeline / Re: Dynamic Detail "Popping" Issue
« on: Jan 30, 18, 06:58:01 AM »
Schemes have caused similar issues as stylesets in my experience, as its pretty much the same thing, I believe its the schemes that cause stylesets to have issues.   I don't know exactly what the cause is as thats all backend code, little is exposed in HSL with those.

My best guess has been that its due to schemes being created in one area and used in another, and it only seems to happen when DYD are involved.  Dyd are nodes, and they may not be getting duplicated correctly.  again thats not exposed so its hard to test/debug it.   Hopefully the new upgrades will resolve it.

Corrupted .dat files don't have to be in old areas.   If The dyd node ( or any other node) thats written to the dat file doesnt exist in that GoM, it can cause a conflict.   Dirty might be a better word than corrupted but its the same result :)

Again, this is my best guess not actually being there... but if you add a new dyd in your current area, and it works fine, but the one from the scheme does not, then thats a pretty good indicator this is the problem.

Scripting & Programming / Re: Logic question - targeting
« on: Jan 30, 18, 06:49:03 AM »
Lol, i hate it when that happens.  good that its not throwing an error, but I always want to know what caused the error :P

Scripting & Programming / Re: Logic question - targeting
« on: Jan 28, 18, 10:23:44 PM »
Thaz, a bit more on this.... 

I'm not positive whats going on here, but I'll run through the possibilities.. maybe that'll help ?

Lets look at the interestSet first:
I'll add some comments

Code: [Select]
public function QueryRemoteInterestSet( subject as NodeRef, interestSet references List of ID )
  // determine the "remote interest set" for the given subject, i.e. the connected players
  // within spatial proximity of the subject and/or other servers with a proxy of this node
  *InterestSet is referenced, so its changeable.  its passed in empty, and populated by this next sas query:
  $SPATIALAWARENESS_AREA._SAS_QueryBySubject( subject, interestSet )   
  *now we loop through the list of ID's provided by the SAS query (account nodes within SAS range)
  loop i from interestSet.length to 1 by -1
    *reference this ID "I", as a noderef and see if its valid.. if not, its an invalid/out of date entry in the SAS
    observer as NodeRef = interestSet[ i ]
    *If the node does not = none, and is NOT a player account node, remove it from the interest set.
    *it was probably an npc.... so we dont want it in the list
    if( ( observer != None ) and not ( observer is kindof _PlayerAccount ) )
      remove interestSet at i
  *If subject is a player account... and by the way this wont work if its not
  where subject is kindof _PlayerAccount
    *Add the playerAccount in question to the list, because we're collecting a list of clients in SAS range and
    *that includes the account in question... Assuming that the SAS query ignored the calling account
    add back subject to interestSet                        // <---- add noderef to IDs?
    *Adding a noderef to a list of ID's converts the noderef to an ID , using less memory than a list of noderefs
    println("QueryRemoteInterestSet "+subject)

And this code is an exact match to mine, hasnt been changed.
So the problem isnt here..

Lets take the code in commonPlayer:ApplyLife()

Code: [Select]
MiscUtils:QueryRemoteInterestSet(me.GetInterestSetSubjectNode(), clients)
you'll find that there are two versions of GetInterestSetSubjectNode()
one in E_CommonCharacter, and one in E_PlayerCharacter....
As best i can recollect at least...

The one in CommonCharacter returns the player node
The one in PlayerCharacter returns the account node....
If the player node is passed into QueryRemoteInterestSet() , it shouldnt work..
Make sure its the account node being returned by GetInterestSetSubjectNode()

you can test that by checking the ID given in your error msg :
"In function RemoteCallClient: player not found:9223372092080021780"

in the console type \sn 9223372092080021780   
and see what type of node that is. it should be an account node.

As to why it didnt do this before... I would double check any recent changes in scripts/classes/prototypes.
Have you begun using a Custom player character or account class other than the E_ character specs?

Scripting & Programming / Re: Logic question - targeting
« on: Jan 28, 18, 07:43:19 PM »
the noderef is automatically converted to an id, and vice verse, at least in this type of situation.

if you're comparing a nodref (subject) to a list of potentials (the list of ids) the noderef pointer is the same as the ID, and so forth.  However for an ID to be converted to a noderef, it has to be a valid and loaded node of that ID, otherwise the result would be Null.  ID = noderef and noderef = ID are both valid convertions.  the exception is that you cannot say a list of ID = a list of Noderef and vice verse, the conversion only works individually.

The noderef is valid (shown by the valid number/id in the error), whats invalid is its being referenced using the wrong class most likely. 

Make sure "subject" is a _playerAccount node and not the playerCharacter node.   only an account ID will match up to the interestSet list.

you could add in a block like this to check and see what the "subject" is:

foreach c in GetClassesOnNode(subject)

Art & Art Pipeline / Re: Dynamic Detail "Popping" Issue
« on: Jan 28, 18, 10:19:35 AM »
looks like a styleset issue to me.  the styleset system has had some issues for a bit now, ive seen similar problems.  if your not using a styleset then im not sure what it could be.  there are some other dyd issues ive seen... i would clear the console, log out of that area, log back in, and check the console printout for any dyd errors.   another issue ive seen is in using the "clone" tool to copy and paint.  when this clone involves dyd assets such as grass etc, it can cause problems and errors when new instances are loaded on the client, even to the point of causing client crashes on moving from one area to another.  Hard to say just by looking though.  if its none of the above, then there must be an issue with corrupt maps or even area.dat file(s)

My best take on it

Pages: [1] 2 3 ... 43