Jump to content
  • entries
    941
  • comments
    5,894
  • views
    870,217

Small behavioral change


Josh

6,460 views

 Share

In the next beta update, the way entity fields work in the script properties will be a little different. Instead of dragging an object from the scene tree onto the field, you will type in the name of the object (or copy and paste the name from the object's name field). This is being done to make the behavior more intuitive. After working with both approaches, I find the new way much easier to use.

 

blogentry-1-0-96881600-1433173830.png

 

This does however mean that an object that is used in this manner must have a unique name, since that is what is used to make the linkage. Additionally, prefab limbs can now have their names changed without breaking the prefab, in order to accommodate this design.

 

Your existing maps will be unaffected until they are resaved in the editor, but if you have multiple target objects with the same name, your map will need to be updated.

 

Alos, the texture list in the material editor is being reverted back to its original design, which was a bit more obvious in its presentation and usage.

 

blogentry-1-0-33029800-1433183272.png

 Share

33 Comments


Recommended Comments



I'm trying to look at this with an open mind but this is what I keep getting back to these points..

 

 

- The user can change referenced name at anytime.

- The user can make a spelling error.

- The editor will add meshes with a duplicate name by default

- Random things happen if there are duplicates and cause frustration.

 

Honesty, intuitive is not the word I would use. I also really like Einlanders suggestion.

 

I'm just going by what I've read, I'm not too keen on updating my projects if I can help it just yet.

Link to comment

I would be interested in hearing about how you are using the entity script property feature. It only was used in two of the example maps I made, in very simple situations. This has no effect on the flowgraph, which is the primary mechanism that links objects together. If I understand better how you are using it, maybe I can prevent problems.

Link to comment

I'm making a game similar to Portal, and I have alot of moving platforms (4 platforms, 14 pivots, total 18 target entities). This is just the first level. I have to look forward to the fact that imported assets are not uniquely named, so I will have to name every moving platform, launchpad, and elevator, separately, then name all the pivots separately. Thinking to the future i'm already reconsidering how i'm making the levels to avoid making work for myself.

Link to comment

I'm thinking in the space of my Mages game.

 

I mainly use the target field so I can access the entity in C++.

 

So I can have any number up to 10 targets as a max number I think it is.

 

For example a door script assigned to the door mesh:

 

slot 1 = pivot :closet orientation

slot 2 = pivot :open orientation

slot 3 = pivot: hinge orientation

slot 4 = camera orientation when casting the spell on the door

 

My C++ door wrapper then keeps a reference to those targeted entities using it's "name" field so I too need to keep the names unique.

 

For this I just grab the entity I want and chuck it in the target field, very easy. As a 100% C++ user, this is the only way I know how to access an entity from the editor so I heavily use it.

 

You know what, that old method of linking entities was a real good feature in 2.5.

Link to comment

If you already are using unique names for each linked object, how does the new design have any effect on your game?

Link to comment

No effect on the game, more the development of it. It was just easy to drag the entity that I wanted into the box. I took a quick look at the new method tonight, still not convinced its better.

 

I've never been happy having to use the 'name' field to do lookups in code. I'd much rather having a unique value taken care of in the editor like an auto increment field in a database table assigned to each model and use that instead whether it be a new ID value or forcing the name to be unique in the editor don't care. I don't know about any difficulties your end of the implementation of something like that, I'm just giving my thoughts on it and at the end of the day it's up to you.

 

 

An alternate method for drag n drop would possibly be the other way around....

  • A non editable text box a button next to it with a crosshair icon on it or something similar to before.
  • Click on the crosshair button your cursor changes to the icon and you can then click on to select an entity in the perspective view port or in the scene graph to select your entity and your target field is populated.

 

Also not sure if it's your end or mine, but after I compile I'm getting a 'Map file version 35 not supported' error. VS Project has been cleaned recompiled and updated in LE. Seems I run into that one regularly when I update the project. (when I load the game in code, it loads in the editor)

Link to comment

I updated the standard edition. Sometimes the change doesn't go through unless I do it twice, for some reason.

Link to comment

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...