Not logged inOpenClonk Forum
Forum Home Help Search Watchlist Register Login
Up Topic General / General / object id
1 2 Previous Next
Post
Parent - - By Zapper [de] Date 2009-08-04 09:38

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


Would still be nasty if you write a major package based on the original objects and have to jump between the namespaces all the time. I would rather like the system of the developer IDs (maybe allowing four characters). ABCD::Flint would be a lot easier to type than org.clonkforge.project123.Flint (assuming that not everyone has an own domain).
Of course, not everyone will use those IDs. But not everybody would use your namespace system as well
Reply
Parent - - By Günther [de] Date 2009-08-04 12:48 Edited 2009-08-04 12:51
Well, no. You'd declare "#namespace org.clonkforge.project123" and "#using org.openclonk" (or some better syntax), and "Flint" would refer to org.openclonk.Flint. If project123 also has a "Flint", you'd get a warning, and would have to qualify the identifier with either "org.clonkforge.project123.Flint" or "org.openclonk.Flint". But project123 would still work when openclonk suddenly uses an identifier previously used by project123, because identifiers from the scripts own namespace have priority. "project123.Flint" and "openclonk.Flint" could probably also work as long as it's clear what's meant from the #using declarations.
Reply
Parent - - By Zapper [de] Date 2009-08-04 13:00

>If project123 also has a "Flint", you'd get a warning


That would work as long as the base package doesn't change. But if the base project introduces a "Flint" later on, the project123 would cease to work.
I would like to have the package identifier belonging to the ID (like the current developer IDs now) but shorten its length
Reply
Parent - By Günther [de] Date 2009-08-04 14:56
Hm, did you miss my edit? "But project123 would still work when openclonk suddenly uses an identifier previously used by project123, because identifiers from the scripts own namespace have priority."

So a script in namespace org.clonkforge.project123 would prefer the flint in that namespace to a flint in other, imported namespaces. The warning is just a warning, so that a developer updating project123 can look into org.openclonk.flint and decide whether project123 should use that instead.
Reply
Parent - - By kevda [de] Date 2010-03-07 23:45
As for now, there is following introduced.

>clonk->CreateContents(Bow);
>clonk->Collect(CreateObject(Arrow));


http://hg.openclonk.org/openclonk/file/fbe2b32500d5/planet/Tests.c4f/Targets.c4s/Script.c#l30

I would suggest to create specific guidelines for IDs which can be followed by random project maker, but dont have to. As for OpenClonk i would suggest Core_Bow.
Reply
Parent - - By Sven2 [de] Date 2010-03-08 00:20
I think the current plan is to differentiate IDs from other identifiers using a character symbol (":"?) and add prefixes to extension packs once they arise I.e., no "Core_". You can find the conventions here:

http://wiki.openclonk.org/w/C4Script_Style_Guidelines
Reply
Parent - - By Newton [de] Date 2010-03-08 13:53 Edited 2010-03-08 14:40
Hmm, who added that?:

>* subobjects of other objects should prefix their parent object name. e.g. <code>Shovel_Dust</code>


So we gonna name the arrow Bow_Arrow, the musket ammo Musket_LeadShot now? Where is the sense in that?
Reply
Parent - - By Sven2 [de] Date 2010-03-08 14:53 Edited 2010-03-08 14:55
If ammunition can be fired with different objects (will probably be the case for arrows), I guess a prefix won't be needed.

I don't know what "Musket_LeadShot" is. If it's some internal musket object, then yes, it should be prefixed. Reason being that names of internal subobjects are very likely to reappear in other objects. Different variants of "Dust" may appear for the shovel, a carpet cleaner and a bulldozer.

This will also help you when you understand where an object is coming from when you stumble upon it in developer mode. A prefix like "Core_Dust" is rather useless; but if I see Shovel_Dust I immediately know where the object came from.
Reply
Parent - - By Newton [de] Date 2010-03-08 16:13
The LeadShot (=Bleikugel) is the ammunition for the musket. Can we agree on writing:

* objects which are exclusively used by their parent objects should prefix their parent object name. e.g. <code>ParkourCheckpoint</code>

The checkpoint of the parkour goal is named ParkourCheckpoint.
Reply
Parent - - By Sven2 [de] Date 2010-03-08 16:19
If you think that's more clear than "subobjects", go ahead.

Btw: Do you think it should be ParkourCheckpoint or Parkour_Checkpoint?
Reply
Parent - - By Newton [de] Date 2010-03-08 16:27
Well, I am the one who named it ParkourCheckpoint, so what I think is the better way should be clear ;-). This is why:
The goal parkour's ID is Goal_Parkour. For me, generally this Prefix_ means "is a" - the parkour is a goal. The hand is an icon, the airblast is a spell etc. Out of this logic, neither Goal_Parkour_Checkpoint (the checkpoint is ultimatively a goal??) nor Parkour_Checkpoint (the checkpoint is a parkour?) would make sense. Also, the arrow which shows the direction of the parkour goal is consistently named GUI_GoalArrow instead of Parkour_Arrow or something like that because it is ultimatively a GUI element, not a parkour.
Sounds good?
Reply
Parent - By Sven2 [de] Date 2010-03-08 16:31
Yes, makes sense. GUI_GoalArrow is certainly better because it can be used for other goals besides the parkour.
Reply
- - By TheBuilder [us] Date 2010-03-08 16:35
Just thinking on the topic in general; mabye objects should be targeted by their script/function, as in what it does/how it works, with version being a factor described by the date it was made.
When a scenario is made, it would look for the required objects by their script/function, and then by version.  In this way a new id definition/variable might not be needed.
If what im saying makes no sense, sorry.

Or mabye something like this:  (don't know how it would look in scipt)-(*)

Name = Flint
Version =  Official, 1

Custom content might look like this: (*)

Name = Flint
Version = Custom, (creator name), 1
Overload = yes/no/with
                                            with = is available as another object, (each subsequent occurence of a flint would be identified by the creators initials and then the name of the object)

So the official flint would be called "Flint" and the custom ones would be "(creator's initials) Flint":  Flint, TB Flint, AB Flint, and so on and so forth.

Again sorry if I don't make sense or if I'm off topic.
Reply
Parent - - By Anonymous [pl] Date 2010-03-08 20:03
Well, objects are defined by their ID, so there is no need for this, but I think, that something like that for scenario folders/expansion packs could be not a bad idea.

[Asmageddon here]
Reply
Parent - By TheBuilder [us] Date 2010-03-08 22:28
Cool, but i meant this could be used as their ID.   I've read this entire topic, and it seemed like you guys were still trying to agree on how to ID each object/thing.

But it doesn't really matter, as long as i could be of some help, im happy.
Reply
Up Topic General / General / object id
1 2 Previous Next
Post

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill