# Deregister Angelscript Type

This topic is 846 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Is there a way that I can deregister a single type in Angelscript? The type is registered as follows:

iResult = pkEngine->RegisterObjectType("TypeName", uiSize, asOBJ_REF | asOBJ_NOCOUNT);
iResult = pkEngine->RegisterObjectProperty("TypeName", "int value", uiOffset);

If I wanted to change the type of "value" to float, for example, is there a way to do so without rerunning the program, or restarting the script engine?

I would then have to recompile any scripts that use that type, of course.

Edited by Wolfbrother

##### Share on other sites

AngelScript doesn't have the functionality for that, and probably good reason.

It'd likely cause all sorts of hell for everything that is of that type. My suggestion to you is to do one of two things. Write a whole new class, or spend the extra bit of data even if it might be wasted space.

You -could- also try casting your ints to floats, and floats to ints. Or use a double precision to capture the range of the int.

Edited by Tangletail

##### Share on other sites

AngelScript doesn't have the functionality for that, and probably good reason.

It'd likely cause all sorts of hell for everything that is of that type. My suggestion to you is to do one of two things. Write a whole new class, or spend the extra bit of data even if it might be wasted space.

You -could- also try casting your ints to floats, and floats to ints. Or use a double precision to capture the range of the int.

Thanks Tangletail.

My purpose is a bit more general than changing a single, specific type, though. I want to be able to change any type at run-time, with any type/number of member variables.

Specifically, I'm making a game editor with an interface for creating entity component types. They have a corresponding type in Angelscript. When I change a type via the editor, the engine will handle any reallocation of memory to existing entity components of that type, and recompile scripts that use that type. In order for this to work, I need to be able to re-register the type.

I'm just having a look at Config Groups. I might be able to register the type in a config group, and then remove it, and recreate it and re-register the type.

Is there any reason not to have one config group for each component type? Otherwise, I could just recreate all types, and recompile all scripts, whenever a component changes in the editor.

##### Share on other sites

I got you. But you're probably overthinking this.

There is the concept of hot reloading, which is possible with angel script. However if the data set changes, it screws up a lot of things. Instead, I recommend doing this.

Create a parser in your editor that will scan through your angle script for special tags. These tags will simply exist on a commented out line. Observe

// #EDITOR_REFERENCE_INT("HEALTH", 0, , 100) | [This field is for HP]
int Health = 100;


Angel script does not have a preprocessor directive. However it should be a piece of cake to look for familiar strings in a program. There are even libraries that will do a compare very quickly for you.

So... let me explain what's happening here.

Program looks for lines starting off with comments, and ignores white space till it sees the first valid character. It spots a comment, and it finds the Preprocessor Directive token "#"

It reads this line, and it sees the message EDITOR_REFERENCE_INT. This tells the program to make a new data entry for an int. Then it creates the UI element. The first argument names the field: HEALTH
Second argument tells the editor that this is the minimum value it's allowed.
Third argument tells the editor what the cieling is. Because it's empty, it's implied as high as possible.
Fourth argument tells editor what the default setting is for this entity or component.

The Brackets is the health field's hover description.

I did something similar to this with Lua script.

When you publish or test your level, you'll compile your code if anything has changed. Your preprocessors will not be in the final code naturally.

Keep in mind though, you need to make some sort of method that will apply your changes to the entity's components when it loads up.

This also assumes that your components are defined in Angel Script.

Edited by Tangletail

##### Share on other sites

Thanks Tangletail, I am familiar with the concepts you are presenting above.

I'll explain a bit about how my entity system works, because your solution will not work with the way I have things at the moment. I'll re-wirte it if it needs to be changed, but at the moment it is working well (except for this re-registering of types business).

My entity components are purely data, and are not managed by Angelscript. Component types are defined in a (non script) file, and changed in the editor. When a component is added to an entity, the ComponentType c++ class (which holds the definition of a component) will allocate memory for the component.

When the ComponentType is defined, it registers an interface in Angelscript. Scripts are then run that reference the type, and they load components from the entity manager like so:

Health@ health = cast<Health>(GetEntityComponent(entity, "Health"));
health.value -= 1;

GetEntityComponent() returns a pointer to the component data that was allocated.

My reasons for implementing components this way are:

• It's easier to define c++ components. Just create a struct for the component, and map it to a ComponentType. No need to use inheritance, on the c++ or Angelscript side (the Angelscript component types are all inherited form a base, but ComponentType handles that, not the person defining the component).
• Since the component is purely data, you don't define it in a script, just a list of variable types and default values. In the editor, there is no need to open a script file to change a component (not that this would be a bad thing, it just seems more intuitive to use a GUI for this).

I can see how defining the components in a script would allow me to recompile them when any changes were made. And I could then use metadata to hook them up to the GUI. But if I can find a way to make my current system work, that would be preferable.

Perhaps I could generate a script file from the ComponentType, and compile that into the script module, rather than defining them as global types?.

Or perhaps I could just restart the whole script engine if a component type is changed in the editor. Hmmmm...

Anyway, thanks again for your help, Tangletail

1. 1
2. 2
Rutin
19
3. 3
4. 4
frob
13
5. 5

• 9
• 15
• 10
• 9
• 17
• ### Forum Statistics

• Total Topics
632603
• Total Posts
3007365

×