Not logged inOpenClonk Forum
Forum Home Help Search Watchlist Register Login
Up Topic General / General / object id
1 2 Previous Next
Post
- - By fritz_rockt [de] Date 2009-08-01 20:23
I think it is time to break up with the 4 alphanumeric as indentifier.
Because the old szenes are already incompatible with OC i think should think about changes in the defcore file.
And the ID of Objects often cause al lot of trouble if you use more than one pack in one szene.
( I remeber an Clonk that shoots atombombs because of an conflict )
Reply
Parent - - By Isilkor Date 2009-08-01 20:32
Yes, this one is already on the imaginary To-Do list.
Reply
Parent - - By fritz_rockt [de] Date 2009-08-01 20:58
I thought about an case sensitive String as Identifier with Additionally an Identifier for the Pack the Object comes from.
To complete it there should be an Version number and an array with identifiers that get overwritten.

So If there are two objects with the same identifier from different Packs there is no conflict.
And if there are two objects with different versions its easy to decide witch one is the current.

It might be possible to make the ClonkScript realy object oriented.
Reply
Parent - By Caesar [de] Date 2009-08-01 21:18
And how do you overload then?
Reply
Parent - - By Zapper [de] Date 2009-08-02 14:22

>To complete it there should be an Version number and an array with identifiers that get overwritten.


CreateObject("MetallAndMagic.c4d-TwoHandedSword-Version2.32ALPHA")?
Reply
Parent - - By Ape [fi] Date 2009-08-02 15:04
This looks awful. The ID (or the it's replacement) should be short and easily remembered. What about just using a longer ID / name?
MONS = Monster
EFLN = Tera-Flint

CreateObject("Monster")

Also I think we don't need to have the version / pack information there.
Reply
Parent - - By MrBeast [de] Date 2009-08-02 16:02
I would like to have simply longer IDs. Maybe 6 Chars instead of 4?

MONS would be MONSTR
EFLN would be TRFLNT
CLNK would be CLONK_
FLNT would be FLINT_
etc.

ExternalPacks could use a prefix then:
SBASSA - Assasin from ShadowBlood.c4d
Reply
Parent - - By Zapper [de] Date 2009-08-02 16:31 Edited 2009-08-02 18:35
You can do that with a unlimited length for IDs as well
Reply
Parent - - By Caesar [de] Date 2009-08-03 08:33
And how do you distinguish IDs from var names then?
Reply
Parent - - By Zapper [de] Date 2009-08-03 09:17
Well. If it is declared as a variable, it is a variable. If not, it is treated as an ID
Reply
Parent - - By Caesar [de] Date 2009-08-03 09:19
var CLONK;
CLONK = MONSTER;
CreateObject(CLONK);

o_O
Reply
Parent - - By Ape [fi] Date 2009-08-03 11:31
var CLONK;
CLONK = "monster";
CreateObject(CLONK);
CreateObject("monster"); //Same as the previous line
Reply
Parent - - By Caesar [de] Date 2009-08-03 16:04
Okay, Interpreting strings as IDs is an Option.
Reply
Parent - - By Zapper [de] Date 2009-08-03 16:15
But normally IDs are converted to the internally used representation during the preparse iirc. And you do not want all strings containing an itemname to become invalid as strings
Reply
Parent - - By Caesar [de] Date 2009-08-03 16:18
Uh. Kay, then that had to be removed and replaced by inline interpreting...
Reply
Parent - - By Zapper [de] Date 2009-08-03 16:33
That is slow
Reply
Parent - By Caesar [de] Date 2009-08-03 17:12
Hu? Hastable!
Reply
Parent - - By Ape [fi] Date 2009-08-04 12:04
The string doesn't have to be the object itself. There could be a function that gets the object that corresponds the string.

CreateObject(getobj("monster")); => CreateObject(MONS);

There doesn't have to be ID that it gets. It could just get the object (no matter how the real object is named). Also the getobj could be inside the CreateObject, so you could just use the line I showed previously.

function CreateObject(object, other, parametres, here, please){
    realobject = getobj(object);
}
Reply
Parent - - By Zapper [de] Date 2009-08-04 12:29
Strings are still slower than preparse-time-translated IDs
Reply
Parent - - By fritz_rockt [de] Date 2009-08-05 22:18
You are able to preparse an string if it's static, too.
Reply
Parent - - By Isilkor Date 2009-08-06 02:06
You are, but the engine won't know it's to be used as an ID until runtime, so it can't resolve calls before.
Reply
Parent - - By fritz_rockt [de] Date 2009-08-06 12:59
If you have to use an getObject(string) function than the engine could solve it
Reply
Parent - - By Zapper [de] Date 2009-08-06 15:48
var foobar="monster";
Message("I'm gonna create a %s!", foobar);
SetName(foobar, GetCursor());
CreateObject(GetObject(GetName(GetCursor()))); and stuff..
Reply
Parent - By fritz_rockt [de] Date 2009-08-06 20:25
not that way but as long as you can be sure that the string is unchanged

as  CreateObject("clonk")

or var clonk = "clonk"
CreateObject(clonk)
Reply
Parent - By Isilkor Date 2009-08-07 13:36
No, it couldn't, since some Script could overload that function.
Reply
Parent - By alex-clonk [de] Date 2009-08-06 19:31
Perhaps a new id-delimiter can be introduced so the engine can determine what's an id and what's a string.
For example:

var id = <Monster>; // other ideas: :Monster , {Monster} , 'Monster'
CreateObject(id);
Log("Just created a %s.", id) // With automatic cast?
Reply
Parent - - By Günther [de] Date 2009-08-06 17:35

> There could be a function that gets the object that corresponds the string.


That function will probably be GlobalN().
Reply
Parent - - By Luchs [de] Date 2009-08-06 19:31
So the objects will just be global variables? Then it will be something like CreateObject(org.openclonk.clonk, 100, 100);?
Reply
Parent - By fritz_rockt [de] Date 2009-08-06 20:17
If wee start to see an ClonkObject as a class (sense of oop) than that would give sense
Reply
Parent - By Günther [de] Date 2009-08-06 22:37
You can create new definitions by script, so it only makes sense to store them in variables. Features to help avoid namespace collisions still need to be implemented, though.
Reply
Parent - - By Isilkor Date 2009-08-03 14:03

> ExternalPacks could use a prefix then:


Nobody uses the guidelines for IDs with four-character IDs, why would you think they'd care when they've two characters more available?
Reply
Parent - By MrBeast [de] Date 2009-08-03 14:17
Yes. I need 4 letters for an ID wich is saying something. Then I have 2 letters left for a prefix. I dont use prefixes on CR because of 2 letters are to less for an ID.
Reply
Parent - By Günther [de] Date 2009-08-03 19:14
The reason for four-character IDs is that they are easily stuffed into four bytes, which made implementing C4Script easier for matthes. While you could stuff six C4ID characters into 32 bits (36^6 < 2^32), it wouldn't be straightforward anymore, and the work spent doing that and ensuring that everything still works is better spent implementing a real solution.
Reply
Parent - By Zapper [de] Date 2009-08-02 16:30

>This looks awful.[...]Also I think we don't need to have the version / pack information there.


That was my point. But without that it would not help in any way to have informations about the package or the version in the ID
Reply
Parent - - By fritz_rockt [de] Date 2009-08-02 19:29
I think we schould not make it necessary to write something like

> CreateObject("MetallAndMagic.c4d-TwoHandedSword-Version2.32ALPHA")


because it is obvisious that you want the latest version.
And i think there is no Problem to say exactly from wich pack you want the object.
It might be possible to keep out the pack definition if the object is in the same pack as the object that executes the script
Reply
Parent - - By Luchs [de] Date 2009-08-02 19:43

>because it is obvisious that you want the latest version.


Not really.
Reply
Parent - - By Zapper [de] Date 2009-08-02 20:09

>Not really.


If not, what do you want then? Its not like the previous option would still be loaded. Only all you CreateObject-Calls would become invalid when I change the arrow damage from 3 to 4 and therefore increase the version number - yay
Reply
Parent - - By Luchs [de] Date 2009-08-02 20:41
It would be useful if newer versions didn't overwrite the older ones.
Reply
Parent - By MimmoO Date 2009-08-02 20:55
Massive of Space required then!
Reply
Parent - - By Zapper [de] Date 2009-08-02 22:43

>It would be useful if newer versions didn't overwrite the older ones.


So every object package should be delivered with each and every object in each and every version it has ever been?
Reply
Parent - By Luchs [de] Date 2009-08-03 13:59
It should be combined with hg!
Reply
Parent - - By Caesar [de] Date 2009-08-03 16:04
Hm. Polygonal objects are not that large, right? (I know, it's crazy.)
Reply
Parent - - By fritz_rockt [de] Date 2009-08-05 22:34 Edited 2009-08-05 22:52

> Hm. Polygonal objects are not that large, right? (I know, it's crazy.)


they are not that much smaler because a small bitmap uses very few data too (bmp 20 * 20 = 1,22 kB)
even if you implement the polygonal objects in a very effective way i will consume much more Space
Reply
Parent - - By Caesar [de] Date 2009-08-05 22:38
You forgot, that we will perhaps have bone animations...

And btw, you should reply to every post separately.
Reply
Parent - By fritz_rockt [de] Date 2009-08-05 22:52
sry you are right i should have sepperated the posts [ill correct that]

> You forgot, that we will perhaps have bone animations...


thats brave i wounder who is going to implement that. i do not think it is easy to do.
Reply
Parent - - By fritz_rockt [de] Date 2009-08-05 22:52

> It would be useful if newer versions didn't overwrite the older ones.


That is not very useful becaus you can anticipate that the later version is the better one.

to have the information of the version would just help the engine to decide (if there are more than one with the same identifier) wich one is the current.
It might give the possibilitie to patch Packs witchout updating the hole pack.
So for example you can put all objects that should get patched in a pack that uses the same namespace as the pack that should be patched. in the patched objects you increase the version number and easily just the current objects get loaded.
Reply
Parent - By Luchs [de] Date 2009-08-06 10:49

>you can anticipate that the later version is the better one.


Yes, but often later versions change something which breaks up old scenarios.
Reply
Parent - By Günther [de] Date 2009-08-02 11:51
They are also already partially gone: Instead of C4IDs C4Script now uses pointers to definitions (or rather, proplists), but internally those are still often first converted to c4ids and later back to definitions. It's now just a question of cleaning that up and providing an easy-to-use method to get definitions without a C4ID.
Reply
Parent - - By Günther [de] Date 2009-08-03 18:25
I've thought for quite a while about this, and I think the only viable solution is to use "reverse DNS". Developers without an own domain could use de.ccan.<username>.objectname, core objects would use org.openclonk.objectname. And because the exact same problem exists for global variables and constants, these and object identifiers should share a common namespace.

Now those identifiers get quite long, and we might want to choose not to solve the problem of two people creating identically named Megaflints after all. But with a little syntactic sugar, like "using namespace org.openclonk" to bring all core objects into the local namespace, and perhaps automatically doing this with the object's own namespace, it could be managable.
Reply
Up Topic General / General / object id
1 2 Previous Next
Post

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill