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 - Tarra2012

Pages: [1] 2 3 ... 8
I cant help you on this usability issue, but am happy to see, that someone tried those "editor cells for lists".

Maybe you can post a graphic link of your solution, my old Links seem not to work anymore.

I couldnt see the observation, that the list sorts itself, but i guess everyone who sets it up, could run into the same behaviour.

To clearify again the intention - and why i better stop writing -

If at any time you encounter anyone that says, that system1 is always to use, no matter what prerequisits your system/your customers/your skills/your dependencies have, i can assure you with long time expierence over many IT projects, its a wrong attitude. Whoever says it, fell in love with a single idea, blending out other possibilities. Or he is a marketing guy :)

Each system has pros and cons. What i wanted to give is a decision HELPER when to use what. I never said NOT to use spec.  I use specs myself. I say its a disadvantage when used in wrong cases. When used by people with less background. When used for things that are close to "global vars" ... just read my first post....

I can find as many systems where i would use them, as systems where i wouldnt. ALL that matters in my post was, to find identifying points, when to use what. And nothing of the rest helped sofar identifying them...

This is a BIG difference keeper, to what you claim i say.

My initial thoughts about not posting were realistic. I am not much attached to it. Yet this thread is going in the wrong way. Its not a helper when to use what, but its a "i defend specific systematics in programming". Sadly. I should have kept it.

This is my last post, as we dont help people to qualify when to use what.

>>His point was when you want to run damage for 70 skills
I didnt want to discuss pros n cons of lists and batch loading. I did it a lot and know where strength and weaknesses are. Your points about how this could work with prototypes are semitrue. But i dont want to mix it in here.

>>Hard coding any type of raw data is never a wise decision
Thanks about a wall of text about a widespread knowledge. My point is, that someone should think before throwing in "one liners" with no real connection to topics. I can throw in 10 more general coding rules that are always true and dont care about thread titles or connection to it.

Now to make it short: Constant data is somewhere set. DialogText1="haha". In terms of constant data definition it doesnt matter where. In terms of programming with hardcoded vars and using them everywhere it is. Latter one was never my point. And should not be done. But how does it affect the thread? Did i call for it? Did i say use hardcoded approaches?

>>instantiate the prototypes for each player
Guess how many prototypes are clientside instanciated. Right, all the time for every player. (even in standard engine a lot) It doesnt matter much. They are running as a clientside ressource. Make them, use them. If you follow a general rule too look HOW big your different data get. (deciding rules).

>>4.) No way to easily read the data in the prototype without
Really? You say a synchronous read data from prototype one liner is not easy, but spec are?

>>5.) Time savings. With prototype only you want to change a value for a skill, you have to know the skills name, the exact spelling of the property name hoping it's not misspelled

Time saving is on prototype side if you follow decision helper. Even batch editing and (oha! versioning comes ontop) is your friend, if you keep your definitions in scripts. And those definitions create a prototype. Time saving is not on your side if you exeed some limits / amounts. AND IF you need category based browsing AND if you need some Guys that can only use editors. to do fireball[dmg]=3 etc.

Your correct on possible mistakes. As a spec editor might catch/handle mistypes. Yet all this is bought by time spend for creating dev tools. Sometimes this overhead is not justified. There is even a good article about this out there in google world. Use it wisely and when its appropriate i suggest. Thats why the thread was born.

The thread was not born to many discussions that now went off (coding massiv multiplayer and needed skills).
Sorry if i step on some feet. I didnt intend to. I should have kept the decision help away from newcomers...


>>batch enter data into the oracles using
I think this is a generally good idea, but you loose the track why there are editors for spec data. Because non coders can use em to define game-data. If you use coder constructs and have have excel lists that define constant data and push them into the system, żou wont need to care about editors much. I like those things too, but you miss category based browsing or "very extended editor, like shown in hj ref, where you link ids, customize on the fly appearances for npc etc."

>>The answer of "I hard coded it all because
I wonder how this generalized statement fits here and how it helps newcomers to decide in the broader context.
Typing game definitions is mostly done "hard written". (if not procedural data) Weather the data is in files/repos/scripts/lists doesnt matter.

>>Total 48 bytes of data. of data to be sent to the client when
Data on the wire. Thats an issue to speak about in constant data realm and sharing this data to client.
Yet if i get it correctly. Clientside prototypes dont need any of your described "send data via network" operations.
Because they are clientside. Only important mutable data will (with or without spec) come from nodes that origin in server environment and thus need network transfer. This is unavoidable.

Avoidable and what specs do in their nature is: Only transfer an ID for some object and then get all constant data out of a repository (ID=400 for an item is transferred to client: then all properties like item_name, item_image,item_stats come from the already on client residing storage - if its filled, if not spec system will sync).

This base mechanism works too with prototypes.
Transfer ID over network and get all constant data out of repository/prototype.
The base mechanism is usable with much less effort. But of course (i mentioned it many times) you lack some other benefits of the spec system, while need less time and knowledge to set it up.
In not too large things, its yet a lot easier to start and even to develop.

What has not been mentioned is memory consumption server side:
This is maybe a bigger thing with specs. have the most reduced representation of objects in server environment.
And use constant data totally constant/globalized. In mmo its usefull e.g. if skill-constant-data for calculating damage are only held 1 time in memory for all people. The mutable data needs to be held for each player anyway.
Otherwise no calcs are possible.

But I still only see a small disadvantage of prototype. As (if i recall correctly) they are stored for each area.
So again my inital decision helper is ok. If the amount of data is overviewable.

Sorry to say, yet your post is exactly one of those posts that i meant and thats why I came up with the given decision helper. Please dont turn this thread into a: Solve everything with specs. Even though i saw indy developers fail heavily on understanding and debugging those intervowen systems properly. In fact i saw more than 30 ppl coming n going on our team and some of them even dont understand easier parts of HE. Most of them never really got to the point to truthfully handle complex spec constructs.

Your assumtions are misleading on some parts. Mutable data is nearly always stored with persisted nodes in DB.
Speaking of skills, it doesnt matter if constant data comes from spec or from prototypes. The mutable per player data(skill-xp-counter, skill-level...) will be managed by you as a coder and will be safed directly with playernodes or some hard-association constructs. This is not the main point of spec system.

Difference is: You ll write lots of code for it to work within spec-world and all of my points are valid. You ll have heaps of scattered code (base classes,derived classes, decorators, oracles... ), high OO-dependencies, editors classes to keep care of and a lot of asynchronous access clientside. So you ll have infact a good system, but one only trained HE developer will really customize well. And at certain scales all those points make a rethinking valid.
Rethinking towards "useability" for small indy teams.

>> So stop trying to justify a reason to build
You really got me wrong. I tried to give a help. Yet you show strongly, that you fell in love with exactly one system and you ll likely give the same answer. Not considering all other options that HE gives.
Not considering state of developers or really need based approaces. Sometimes a mix of other outpasses plain specs a lot. And just a tiny note: I implemented many different ways already. With or without Spec. Guess which ones are easier to maintain for newcomers...

>>a Skill_IS_AOE class that you glom onto the base skill class.
please dont mix advantages of "Glomming" or compostion of objects with spec system.
you can write OO classes and glom them on objects. doesnt matter which approach you follow for constant data.
thanks to HE we have "Glomming" - "live introspection of nodes /sn clicommand " - "rdy to use replication" -" rdy to use persistancy"  etc. a lot things that are used within specs and can be used without and really give advantages over other engines

>> the spec system is really simple to use
I say: In my career i have seen many languages and frameworks. I vote for the opposit and say: they are good, but they need deeper knowledge and handling skills in HE. There are many engines with concepts that are much easier to follow and to implement.

Just a rough estimation: Setup and access of a constant values in a prototype is five times easier.
Access to prototypes is what coder from other realms understand as constant/globales
They need 1-2 lines to access them. They are intuitive.


A lot of forum topics are answered with "use spec system". The justification,
why its used, is not transparent. Thats why i started a small decision list
with hints, when to use "Spec System" vs "Prototypes/Scripts."
Reading -data storage options- in the HEwiki is a good prerequisit.

When you are close to do sth. that in other languages is done by use of "global" values

When the amount of data is "overviewable"
  say 70 skills with 8 attributes
  say 20 areaeffects with 20 attributes

When your derived objects are easy to manage
  say you spawn ~2 different classes out of the definition

When your own knowledge is limited with HE Systems
  say be true to yourself and even if you handle HSL the dependencies of HE frameworks are not
  your deepest knowledge

When you prefer direct access in coding (synchronous)
  function a) calls and gets values immediate

When you dont need editors to "change constant values"

=> you should go with prototypes / scripts

When you are close to do sth. that builds complex objects (mutable,non-mutable data in objects)

When your amount of data is "big",
  say  500+ dialogdata
       1000+ Items with lots of categories
       120+ NPCs with different attribute sets (shop npc, boss npc, regular npc, trainer npc)

When derived objects are architected in strong OO manner
  say main class: task
        derived classes: killtask / findtask / talktotask / delivertask
        optional decorator classes: timedtask  / rewardedtask / collectingcountertask

When you dont hesitate to use indirect access in coding (asynchronous callbacks)
  function a) calls
  function b) retrieves callback

When you need editors for teammembers to change constant data

When you support the category based browsing of big number of data (300NPCs,1000Items....)

=> you should go with SpecSystem

Note 1)
I didnt mix more storage options. But remember you can use them.

Repository is shortly spoken a filestorage possibilty that exists for server n client.
Normal Text or even serialized complex objects can be saved/loaded as XML/STRINGS.
Infact the Whole SpecSystem is a mixture of Prototypes/Repository Storage,
with interal synchronizing features.

Using Repository standalone:
- For Saving "Player Customized" GUI/CHAT Settings. (Clientside)
- Generating timed Reports "ItemDrops per 24hours" (Serverside)
- Filebased data (remember: DB persistancy for objects is given by DOM flags
                            and the createpersistednodefromclass)

Note 2)
The spec system is harder to setup, to debug und to understand.

-You will write more classes and lines code. The code itself will be scattered around in MANY
different places. The factory of different "nodes" that represent the same object on server / client
is a major point in all of this. It is solvable in many fashions.

-You need to care about the editor. When you use complex datatypes (path references, lists of "objects", 1:n relationships) the standard editor is limited. DO think how much time you want to spend on developing "developer tools".

-There are many base concepts to be understood before diving into spec world
GOM/DOM Handling
Debugging and Using /commands
Replication vs RPC
Event Handling (Events with Observer/Listener)
GUI Creation
Startup/Shutdown Callchains (Areaserver, Character Loading, Entry Points)

I wrote this initially many month ago, then stopped a bit with HE.
I still think, a valid discussion when to use what is a benefit to many coders.
Especially to people, that are using HE in the first month.
Basically i dont want to convince that one system is better than another one, but i want to give a bit realistic view on what awaits you.

Maybe some experienced coder can add their views on "when to use what".

Is any HE member analyzing for an answer?
Or shall i better leave my hands off those functions CreatePhysicsBoxCharacter() / MovePhysicsCharacter()?

I do vote for WWZs post.
First implement some basic systems. (inventory,skills,triggered doors,mobspawners,quests,chat,xp)
Then let testers come. Until then you probably got some month++ work and afterwards you can
judge better how the engine behaves and how its underlying concepts are best used.

The CLI Commands for live node inspection (/sn /sp \sn \sp) are worth looking into.
They are a quite remarkable feature allowing understanding/debugging of HE.

Developer Created Tutorials / Re: DOM basics
« on: Feb 11, 14, 12:42:35 PM »
*Ignore this*
Saw you already mentioned the default "read-only" checkbox.

I think we used the association concept.
You create an own class, make a persisted node out of it and "hard link" it to the area root.
Thus you dont have method collisions.

Storing the data in a node requires that you; Instantiate a persisted node from a class containing the field(s) you need to store your data and associating that node to the area root node in the EDIT instance of your area. The node(s) must be associated to the area root with at least a base_hard_association and may optionally have additional soft associations to facilitate querying for the node(s). Using nodes to store the data has an advantage over storing the information in a class GLOMmed on, in that you may have multiple nodes to store data should your system require them.

Trying to understand

 - what "Physic Actor" Properties do really exist Serverside and where i can find information about them
   and the state of the physic scene. More explicitly, if i have a "physics_character_id_out references ID"
   where can i find debugging info about it? (its not a gom node, its a ID running upwards from 1)

 - why Functions like CreatePhysicsBoxCharacter() / MovePhysicsCharacter() always return true
    but nowhere any evidance, that something has been created or moved exists.
    nowhere debugging possibilities to be found. (Code Example below)

 - how to create a PhysicBox/Capsule that is used for NPC/PC
       but i like to use it for a box. So that i can use "Collision detection + base Sweeping Tests".

Code: [Select]
acct as NodeRef of Class E_playerAccount = SYSTEM.REMOTE.CLIENT
pc as NodeRef of Class E_playerCharacter = acct.GetMyChar()
phys_id as ID
pos as Vector3 = pc.GetPosition()

//We need a requester Node, simply take the selected "clicked" target
ctarget = MiscUtils:ClientToServerNode( acct.GetClickTarget() )
myid as ID = ctarget

//Specify class that handles callbacks from physic operation

//Extents - ? no idea what the input means
newvec as Vector3

//FYI: How the Method is described in _external
//CreatePhysicsBoxCharacter( requestingNode as NodeRef, physics_character_id_out references ID, extents as Vector3, slopeLimit as Float, skinWidth as Float, position as Vector3, gravity as Float ) as Boolean

if CreatePhysicsBoxCharacter( myid, phys_id, newvec, 2.0, 1.4, pos, 1.0 ) == true
   $CHAT.ChatPlayer( acct, "","Physic Created box: "+phys_id)

if MovePhysicsCharacter( ctarget, phys_id, pos ) == true
  $CHAT.ChatPlayer( acct, "","Physic Box moved: "+phys_id)

Output when Executed:
Physic Created box: 1
Physic Box moved: 1

[hsl_debug] 9223372056307022385,4: SCRIPT[EO_Physic_NodeClassMethods]: physchar created:9223372073882021740 a:1 b:true

[hsl_debug] 9223372056307022385,4: SCRIPT[EO_Physic_NodeClassMethods]: physchar moved:9223372073882021740 a:1 b:(0,0,0)


Hm, so there is no way we can access any physics server logs/output?
Even though the Function "PhysicsCoreDump()" supposes this?

Another proposal, to make the setup easy:

Have the constant data in a prototype (GAMESKILLS)
Have the central formulas in a class (script serverside)
Have the mutable per player data (like skill-experience) at each character.

In many cases the usage of Prototypes (and their instanced objects called SYSTEMNODES) is more easy than the usage of SpecSystem.
I will show you how easy the access could be serverside.

constant data
$GAMESKILL[Skill1].name = Myname
$GAMESKILL[Skill1].range = 12
$GAMESKILL[Skill1].mana = 5
$GAMESKILL[Skill1].dmg = 10

mutable data
player.skilllist[skill1].experience = 1000
player.skilllist[skill1].level = 1

Formulas (ServerSide ScriptMethods)
untrusted remote trigger_skill(skillname)
  *do your calculations
  *e.g. (playerlevel + mainstat + $GAMESKILL[Skill1].dmg) * randomvalue

Dependent on how you communicate the Skillinfos, both data can be available on client.
This mean replicating a Prototype (server->client) and normal replication of a skilllist that belongs to each player.

System nodes were adopted as the primary mechanism at the HSL script level enabling game-specific implementations of a licensee to extend/override the required functionality included in the Clean Engine. As with all system nodes, this is accomplished by GLOMming a game-specific class onto the prototype ($NAME) from which a singleton node ($NAME) is instantiated for a particular local GOM.


Create a class like the one I have shown in my entry post: Class EO_Physic_Node

Glom it to the subject. Now the callbacks work. Its a simple callback error, as the method was not found on the node.
Yet it doent change at all the behavior. "Physics Function return true" yet no evidence to be found, that they actually did sth.

How would the savepath look like to "reference" a clientside directory in HE?
I never tried anything like that or ever have seen this.

   savepath as String="\ScriptData\ZEO_PhysicsLog_"+SYSTEM.TIME.NOW

   if PhysicsCoreDump(savepath) == true
     println("saved debug log")

*Maybe we misunderstand each other. I still assume that the "serverside" physic process logs to a standard server logfile. 

1) My 1st thought is, i can access this file by using the repository browser.
   I failed. I dont find it anywhere.

2) My 2nd thought is, i use the function "PhysicsCoreDump" to dump the log to a "user specified" location.
   I failed. As all PhysicFunction return a true, yet i cant find my specified file.

Now you came with a very interesting approach, to redirect the PhysicsCoreDump to a "networked" clientside location. Something i would say that is rater untypically, but not impossible.

Pages: [1] 2 3 ... 8