Page 1 of 2

fire_rate coding

Posted: Tue Aug 30, 2011 3:56 pm
by sdrubble
Howdy all,

I've been having some fun hacking the Caduceus shipdata, trying to make it just a 'little' more über ... :mrgreen:

I'm not being lucky regarding specifying the [b][color=#0000FF]fire_rate[/color][/b] parm... the only previously-made examples I could gather use a syntax which is different than the one in the Caddy OXP.

Here's a snippet for the main ship entity of my modified [b][color=#0000FF]shipdata.plist[/color][/b]:

Code: Select all

   <!--  ###############################################################################################################################################  -->
   <!--                                                DARK RAINBOW - PLAYER VERSION                                                                 -->
   <!--                                  (more cargo, more missiles, more turrets (with more COLORS !!!) than Caduceus Omega)                                         -->
   <!--  ###############################################################################################################################################  -->
<key>dark-rainbow-mk1-player</key>
   <dict>
      <key>aft_eject_position</key>
      <string>-0.1985 -5.5002 -57.7762</string>
      <key>energy_recharge_rate</key>
      <real>5.8</real>
	  <key>cloak_passive</key>
      <false/>
      <key>hyperspace_motor_spin_time</key>
      <integer>12</integer>
      <key>exhaust</key>
      <array>
         <string>-4.663113 -0.5 -55.1 3.8 3.8 2.0</string>
         <string>4.663113 -0.5 -55.1 3.8 3.8 2.0</string>
         <string>-4.663113 -0.5 -56.0 1.1 1.1 1.0</string>
         <string>4.663113 -0.5 -56.0 1.1 1.1 1.0</string>
      </array>
      <key>forward_weapon_type</key>
      <string>WEAPON_BEAM_LASER</string>
      <key>laser_color</key>
      <string>greenColor</string>
      <key>max_cargo</key>
      <integer>150</integer>
      <key>extra_cargo</key>
      <integer>30</integer>      
      <key>max_energy</key>
      <real>512</real>
      <key>max_flight_pitch</key>
      <real>0.8</real>
      <key>max_flight_yaw</key>
      <real>0.8</real>
      <key>max_flight_roll</key>
      <real>1.8</real>
      <key>max_flight_speed</key>
      <real>460</real>
      <key>scoop_position</key>
      <string>0.0 -6.48006 53.297053</string>
      <key>missile_launch_position</key>
      <string>-3.532853 -10.17446 -12.143362</string>
      <key>max_missiles</key>
      <integer>16</integer>
      <key>model</key>
      <string>cbodyg.dat</string>
      <key>smooth</key>
      <true/>
      <key>name</key>
      <string>Dark Rainbow</string>
      <key>roles</key>
      <string>player</string>
      <key>thrust</key>
      <real>45</real>
      <key>view_position_aft</key>
      <string>0.0 0.0 -60.1</string>
      <key>view_position_forward</key>
      <string>0.0 0.0 54.1</string>
      <key>view_position_port</key>
      <string>-8.59 0.0 0.0</string>
      <key>view_position_starboard</key>
      <string>8.59 0.0 0.0</string>
      <key>weapon_position_forward</key>
      <string>0.0 0.0 53.9</string>
      <key>weapon_position_aft</key>
      <string>0.0 0.0 -59.9</string>
      <key>subentities</key>
      <array>
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
         <string>cenginea       -4.5   -0.5 -60.5  1  0  0 0</string>
         <string>cengineb        4.5   -0.5 -60.7  1  0  0 0</string>
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
         <string>cmount          0.0   -2.6  26.0  1  0  0 0</string>
         <string>cmount          0.0   -2.6  13.0  1  0  0 0</string>
         <string>cmount          0.0   -2.6   0.0  1  0  0 0</string><!--  *** mid-ship, front-to-back (0.0 in #3); mid-ship, right-to-left (0.0 in #1)   *** -->
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
         <string>caduceusturret   8.0   -2.7  26.0  1  0 -1  0</string><!--  *** front-most lateral turret (26.0 in #3)                                                        ; fires sideways  [ 1  0 -1  0]  *** -->
         <string>caduceusturret   8.0   -2.7  13.0  1  0 -1  0</string><!--  *** middle lateral turret                                                                         ; fires sideways  [ 1  0 -1  0]  *** -->
         <string>caduceusturret   8.0   -2.7   0.0  1  0 -1  0</string><!--  *** mid-ship, front-to-back (0.0 in #3)                                                           ; fires sideways  [ 1  0 -1  0]  *** -->
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
         <string>caduceusturretB -8.0   -2.7  26.0  1  0  1  0</string><!--  *** front-most lateral turret (26.0 in #3)                                                        ; fires sideways  [ 1  0  1  0]  *** -->
         <string>caduceusturretB -8.0   -2.7  13.0  1  0  1  0</string><!--  *** middle lateral turret                                                                         ; fires sideways  [ 1  0  1  0]  *** -->
         <string>caduceusturretB -8.0   -2.7   0.0  1  0  1  0</string><!--  *** mid-ship, front-to-back (0.0 in #3)                                                           ; fires sideways  [ 1  0  1  0]  *** -->
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
   <!--  original top & bottom turrets: both are MORE to the REAR of the ship  -->
         <string>zeroturret      -0.198 -7.8 -32.0  1 -1  0  0</string><!--  *** bottom turret (-7.8 in #2); mid-ship, right-to-left (-0.198 in #1); aft-most     (-32.0 in #3); fires downwards [ 1 -1  0  0]  *** -->
         <string>zeroturretB      0.0    1.4 -14.8  1  1  0  0</string><!--  *** top    turret ( 1.4 in #2); mid-ship, right-to-left ( 0.0   in #1); forward-most (-14.8 in #3); fires upwards   [ 1  1  0  0]  *** -->
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
   <!--  additional turret: front bottom, fires forward  -->
         <string>zeroturretC      0.0   -6.9  60.1  1  0  0  1</string><!--  *** bottom turret (-6.9 in #2); mid-ship, right-to-left ( 0.0   in #1); forward-most ( 60.1 in #3); fires forward   [ 1  0  0  1]  *** -->
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
   <!--  additional turret: back top, fires backwards  -->
         <string>zeroturretD     -0.198  5.5 -56.0  0  0  1  0</string><!--  *** top    turret ( 5.5 in #2); mid-ship, right-to-left (-0.198 in #1); aft-most     (-56.0 in #3); fires backwards [ 0  0  1  0]  *** -->
   <!--  ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  -->
      </array>
   <!--  ===============================================================================================================================================  -->
<key>shaders</key>
      <dict>
            [ . . . ]
      </dict>
   <!--  ===============================================================================================================================================  -->
      <key>custom_views</key>
      <array>
            [ . . . ]
      </array>
   </dict>
   <!--  ###############################################################################################################################################  -->
And here's the turret code where I'm experimenting with [b][color=#0000FF]fire_rate[/color][/b]:

Code: Select all

   <!--  ===============================================================================================================================================  -->
   <!--      'ZEROTURRETD-NPC's - turret ABOVE ship, on central axe, aft, fires backwards             --> 
   <!--      - not used ANYWHERE - CLONEd into 'ZEROTURRETD's            --> 
   <!--  ===============================================================================================================================================  -->
  <key>zeroturretD-npc</key>
   <dict>
      <key>ai_type</key>
      <string>nullAI.plist</string>
      <key>laser_color</key>
      <string>orangeColor</string>
      <key>model</key>
      <string>zeroturret.dat</string>
      <key>smooth</key>
      <true/>
      <key>name</key>
      <string>Zero Turret</string>
      <key>roles</key>
      <string>ballturret zeroturret</string>
      <key>setup_actions</key>
      <array>
         <string>initialiseTurret</string>
      </array>
      <key>max_flight_pitch</key>
      <real>1</real>
      <key>max_flight_yaw</key>
      <real>1</real>
      <key>max_flight_roll</key>
      <real>1</real>
      <key>thrust</key>
      <real>1</real>
      <key>weapon_energy</key>
      <real>50</real><!--  *** 50 is maximum for NPC ships   *** -->
      <key>fire_rate</key>
      <real>0.25</real><!--  TEST: interval between shots, in seconds. Default: 0.5. Minimum 0.25   *** -->
	  <key>accuracy</key>
      <real>8</real><!--  *** original value: 5   *** -->
      <key>energy_recharge_rate</key>
      <real>5</real>
      <key>max_energy</key>
      <real>200</real>
   </dict>
   <!--  ===============================================================================================================================================  -->
   <!--      'ZEROTURRETD's - turret ABOVE ship, on central axe, aft, fires backwards                                                             --> 
   <!--       - used by DARK RAINBOW - PLAYER and NPC VERSIONs - CLONEd from 'ZEROTURRETD-NPC's                                                     --> 
   <!--  ===============================================================================================================================================  -->
   <key>zeroturretD</key>
   <dict>
      <key>like_ship</key>
      <string>zeroturretD-npc</string>
   </dict>
   <!--  ###############################################################################################################################################  -->
The ship is already working overall (minus the fire_rate override), now with ten turrets in six different colors (yeah, I KNOW it's quite corny indeed :lol: ). But what I'd like to achieve is to have different fire rates for each turret, so that even if the fire_rate differences are not that much significant, it would turn out a beautiful, chaotic out-of-sync effect. :twisted:

I suspect that the fire_rate thing would fit better in the main ship entity, alongside the quaternion specs of zeroturretD... would anyone care to provide examples and/or coding suggestions ? (Just bear in mind that I'm not an OXP'er, just a copy-paste-tweak guy :oops: ).

Cheers

Re: fire_rate coding

Posted: Wed Aug 31, 2011 8:15 am
by Eric Walch
The problem is that fire_rate is not a ship_key but part of the new subentity definition. So, you must not define it in the subentity, but you must use the new style of subentity definition. Instead of the current single line for each turret, you must replace it with something like:

Code: Select all

<dict>
	<key>type</key>
	<string>flasher</string>
	<key>position</key>
	<array>
		<string>0</string>
		<string>0</string>
		<string>60</string>
	</array>
	<key>frequency</key>
	<string>0.15</string>
	<key>phase</key>
	<string>-1</string>
	<key>size</key>
	<string>150</string>
	<key>colors</key>
	<array>
		<dict>
			<key>hue</key>
			<string>60</string>
		</dict>
		<dict>
			<key>hue</key>
			<string>30</string>
		</dict>
		<dict>
			<key>hue</key>
			<string>30</string>
			<key>saturation</key>
			<string>0</string>
			<key>brightness</key>
			<string>0.85</string>
		</dict>
	</array>
</dict>
for each turret.
This is an example for a flashes because I could not find an oxp that already used the new style for turrets. Advantage of the new style is of cause the definition can now contain much more specific settings than the old single line definition.
But defining it in XML syntax is quite awkward when using text editors.

The same in ascii is much more readable

Code: Select all

			{
				type = "flasher";
				position = (0, 0, 60);
				frequency = 0.15;
				phase = -1;
				size = 150;
				colors = ({ hue = 60; }, { hue = 30; }, { hue = 30; saturation = 0; brightness = 0.85; });
			},

Re: fire_rate coding

Posted: Wed Aug 31, 2011 3:53 pm
by sdrubble
That's great, Eric, thx a lot.

So if I got this right, I should do TWO things (edit: actually THREE - see below), starting from the examples I gave in my previous post:

1. in the [b]zeroturretD-npc[/b] subentity block, remove the [b]fire_rate[/b] entry I had added in there (leaving the rest as it is);

2. in the [b]main ship entity[/b], replace this CURRENT CODE:

Code: Select all

<!--  -------------------------------------------------------------------------------------------------------------------------------------------  -->
<!--  additional turret: back top, fires backwards  -->
<string>zeroturretD     -0.198  5.5 -56.0  0  0  1  0</string><!--  *** top    turret ( 5.5 in #2); mid-ship, right-to-left (-0.198 in #1); aft-most     (-56.0 in #3); fires backwards [ 0  0  1  0]  *** -->
<!--  -------------------------------------------------------------------------------------------------------------------------------------------  -->
with this NEW CODE:

Code: Select all

<!--  --------------------------------------------------------------------------------------------------  -->
<!--  additional turret ZEROTURRETD: back top, fires backwards  -->
<dict>
    <key>type</key>
        <string>ball_turret</string>
    <key>subentity_key</key>
        <string>zeroturretD</string>
    <key>position</key>
        <array>
            <string>-0.198</string><!-- HORIZONTAL CENTER -->
            <string>5.5</string><!--    VERTICAL   TOP    -->
            <string>-56.0</string><!--  AFT-MOST          -->
        </array>
    <key>orientation</key><!--   fires BACKWARDS [ 0  0  1  0]    -->
        <array>
            <string>0</string>
            <string>0</string>
            <string>1</string>
            <string>0</string>
        </array>
    <key>fire_rate</key>
        <real>0.25</real><!--  TEST: interval between shots, in seconds. Default: 0.5. Minimum 0.25   *** -->
</dict>
<!--  --------------------------------------------------------------------------------------------------  -->
I'm not quite sure if the [b]subentity_key[/b] piece is done right :?: (take a look pls ? :) ). Your example doesn't have this entry, but I guessed it was required here so it would point to the specific subentity code further down the plist.

I hope I'm not missing anything else, at least judging by the specs given in the Wiki for a [b]ball_turret[/b] subentity.

3. [added by later edit] - The last thing I'd need to do - and about which I'm a total loss after Googling around plist's and XML's - would be how to glue the changed entry into the global plist file.

It was only after I had originally posted this, and started editing the plist file, that I encountered this issue. Which is: the original one-liner for the zeroturretD subentity is within an array... I don't think I could place the complete DICT block inside the SAME array where the one-liner was, together with all the other one-liners for the other subentities. So it's more or less obvious to me that the new DICT block should be placed OUTSIDE the array, which brings along a new set of questions such as: should it go INSIDE or OUTSIDE the main dark-rainbow-mk1-player block ? Would it require its own key entry above its initial dict keyword ?

I'm starting to feel that accomplishing this with my current knowledge would require quite a bit of hand-holding from this board... not that it wouldn't be welcome (it most certainly would), but I wouldn't consider it fair to expect this level of assistance without my willingness to delve much further into coding specs and techniques.

So, depending on how this comes out, I might be giving up on this little project, which I had initially thought it would involve little more than learning the given syntax for a new parameter.

Anyway, thx a lot. :|

Thx a lot!

Re: fire_rate coding

Posted: Wed Aug 31, 2011 5:24 pm
by Eric Walch
Yes, that code looks correct to me. And you get errors in the log when you made a mistake, so you will know soon enough. :lol:
(The new style just make the plist much longer as you have to replace a single line with a whole structure.)

Re: fire_rate coding

Posted: Wed Aug 31, 2011 5:57 pm
by sdrubble
Eric Walch wrote:
Yes, that code looks correct to me.
Thx Eric, but I don't think you saw my EDITED post (new item #3 added.)

Re: fire_rate coding

Posted: Wed Aug 31, 2011 6:16 pm
by Smivs
Hi sdrubble,
I'm sure no-one will mind helping you with this-we're noted for being the 'friendliest board...etc'.
This stuff is quite easy to get to grips with once you understand the basic, but I do think you aren' t doing yourself any favours by trying to do this in XML. I understand the original that you are working from is coded in XML, but most Oolite plists today are written in ascii (or 'openstep' as it's sometimes called).
The reason for this is simply that it's much easier to read and write an openstep plist than an XML one, and that's why it's recommended.
You therefore might want to consider starting by 'translating' the XML .plist you currently have into openstep. This will help teach you openstep (which you'll like a lot I'm sure), and give you a .plist which will then be much easier to edit and add to.
If you want some examples of openstep .plists, look no further than the .plists for Oolite. The core game that is.
And if you get stuck, just ask.
Smivs

Re: fire_rate coding

Posted: Wed Aug 31, 2011 6:28 pm
by Eric Walch
sdrubble wrote:
Thx Eric, but I don't think you saw my EDITED post (new item #3 added.)
You are right, i didn't see your last edit. But still, the original is an array with strings. And every sting can be replaced by the new, corresponding dictionary for the new style definitions. You can even mix new and old style definitions to obtain an arrays filled with strings an dictionaries.

Re: fire_rate coding

Posted: Wed Aug 31, 2011 6:36 pm
by Eric Walch
And when you want to test your models in Oolite itself, I always like to do that in a missionscreen by typing in the console:

Code: Select all

mission.runScreen({model:"role"})
Actually, I am very lazy and once defined a macro by typing:

Code: Select all

:setM show mission.runScreen({model:PARAM}) 
And now only use

Code: Select all

:show role
in the console. It brings up the model in maximum screen size and it won't drift away. And you can even access the model with:

Code: Select all

mission.displayModel

Re: fire_rate coding

Posted: Wed Aug 31, 2011 7:21 pm
by sdrubble
Thx a lot folks...

@Smivs,

Yes I understand your point. Your idea is interesting and I might be looking into it soon.

However I took a look at the original shipdata file in the Caduceus OXP (that is the smallest one I'd have, disregarding the larger ones I did by multiplying the ships). If I further do some streamlining on that one (taking out the 2nd ship), it'd still be around 550 lines to translate... :? I know many of those are redundant and could be done quickly by copy-pasting, but even so I don't feel overly enthusiastic at the moment about doing that (even if the end result would end up being much smaller).

However, your suggestion is definitely noted down for the next occasion I might be hacking Oolite stuff. Thx indeed.


@Eric,
...the original is an array with strings. And every sting can be replaced by the new, corresponding dictionary for the new style definitions. You can even mix new and old style definitions to obtain an arrays filled with strings an dictionaries.
Well this is auspicious news. In other words I can just stick my 'NEW CODE' block above in place of the former single line for the turret...

That's the quickest solution I can see. I'll trust you that it will indeed work (that's the main quest), although the code will indeed look UGLY (well, Frankenstein also did BOTH, so that's not a real issue). :mrgreen:

I'll test this first with this turret which is almost 'ready', and later propagate to the other turrets. In any case I'll come back with whatever results (expecting the better ones of course). :roll:

As to the console & macro stuff, I'm afraid I'll have to research a bit more, in order to have a better idea of what you're talking about... sometime later, most likely. :shock:


@all,

Thx a lot & cheers... be back soon. :D

Re: fire_rate coding

Posted: Wed Aug 31, 2011 8:04 pm
by Eric Walch
sdrubble wrote:
However I took a look at the original shipdata file in the Caduceus OXP (that is the smallest one I'd have, disregarding the larger ones I did by multiplying the ships). If I further do some streamlining on that one (taking out the 2nd ship), it'd still be around 550 lines to translate... :?
Don't do that by hand. A few months ago there was a python script published in one of the BB topics that would do the trick. i added a link to that topic and to the script itself at the bottom of the [wiki]Property_list[/wiki] page.
It works okay as far as i tested. I don't know how good it handles embedded comments. For the mac there is the plist editor. There it is just a matter of doing a 'save as...' and selecting the format. For the mac plist editors I have, it means all comment is missing after a save. (That is probably the reason I rarely use comments in plist because it means I must proceed with plain text editors after that.)

EDIT: I just tested a XML plist with comment. That python script can't cope with comments. But when removing the comment, it converts it within an eye-blink .
That comment is not handled well is not the fault of Cmd Jettison, who wrote the script, but it is python that is not supporting comments. The major part of the conversion is done by a python library for plist handeling.

Re: fire_rate coding

Posted: Wed Aug 31, 2011 8:26 pm
by sdrubble
Eric Walch wrote:
sdrubble wrote:
However I took a look at the original shipdata file in the Caduceus OXP (that is the smallest one I'd have, disregarding the larger ones I did by multiplying the ships). If I further do some streamlining on that one (taking out the 2nd ship), it'd still be around 550 lines to translate... :?
Don't do that by hand. A few months ago there was a python script published in one of the BB topics that would do the trick. i added a link to that topic and to the script itself at the bottom of the [wiki]Property_list[/wiki] page.
It works okay as far as i tested. I don't know how good it handles embedded comments. For the mac there is the plist editor. There it is just a matter of doing a 'save as...' and selecting the format. For the mac plist editors I have, it means all comment is missing after a save. (That is probably the reason I rarely use comments in plist because it means I must proceed with plain text editors after that.)

EDIT: I just tested a XML plist with comment. That python script can't cope with comments. But when removing the comment, it converts it within an eye-blink .
Thanks a million.

The plot thickens... :D

Re: fire_rate coding

Posted: Thu Sep 01, 2011 11:18 am
by ClymAngus
10 turrets and a gaudy paint job eh? You've pimped it haven't you?
Image

Do we get pictures of this flying Homunculus? :D

Re: fire_rate coding

Posted: Thu Sep 01, 2011 8:22 pm
by sdrubble
Hahahaha!!!

Right on the spot, Clym! (including - and mainly for - the picture you've posted). You couldn't have guessed it more rightly. :twisted:

BTW, 'paint job' is not exactly true. I'm still using your original textures and elements - the additional colors are only for the plasma bursts.

Actually, this started as a simple 'home tweak' of the Caddy. After decades of unsuccessful attempts at various flight and space simulators (since I lack the minimum standards of environment awareness and hand-eye coordination required of a would-be pílot), I marveled with Oolite at the possibility of improving an already über design and end up with a ship which sort of fights for itself.

On a side note, I even tweaked the MilHUD OXP, so that TAF=0.5 gets automatically set whenever a fight starts. I've also been seen 'fighting' at TAF=0.25 or less... So that I've even toyed with the possibility of releasing a meta-OXP called something like "Uber Ships for Creaky Commanders", composed of the 'Dark Rainbow' plus my own set of slow-motion preferences for MilHUD.

Well, back to the 'home tweak' of the Caddy: after I added more missiles, more cargo, 2 more turrets, 6 flying colors for turret fire (a bit like an old-fashioned circus portal)... and presently in the [still experimental] process of adding out-of-sync firing rates and maybe more colors, it's starting to become a quite distinctive beast (whilst also a visually ridiculous and exaggerated one). Another would-be change - which I'm still in the process of weighing up - might be slightly changing the quaternions of the 4 fore and aft lateral turrets into diagonal orientations, so as to give a bit more coverage of fore, aft, up and down. That would mean 10 turrets firing in 10 different directions. Way to go, yet.

Pictures of the Homunculus ? This is starting to become likely. That is, if I can obtain your consent for publishing this blatant ripoff of the Caduceus as a new OXP.

BTW, I'm not quite sure if 'Dark Rainbow' would be the most appropriate name. Someone might even consider (after seeing a screenshot, that is) that 'Warty Popsicle' might be a good alternate name. It would mostly depend on if you're just observing it pass calmly and uglily by, or if being simultaneously nailed by up to 5 turrets, all out-of-sync and in multiple colors.

A corner of my mind has already produced snippets of a back-story, involving an unspoken & unadmitted ripoff of the Caddy by Skavurzka Shipyards, located in some high TL commie system, general availability at most medium TL commie systems, a hefty price tag (it'd be meant for assumed cheaters, after all...) and officially aimed at 'millionaire and billionaire' lazy space-farers.

BTW, the picture you've posted looks like a personal caddy... :mrgreen: here's a relative, albeit an unmanned one - The Shadow Caddy

Cheers !!!

Re: fire_rate coding

Posted: Fri Sep 02, 2011 9:31 pm
by ClymAngus
congratulations your fine works have been officially recognised in Caduceus Canon.

Check the wiki. :D

Canon, I really hate that word. I much prefer "accommodation of new ideas".

Re: fire_rate coding

Posted: Sun Sep 04, 2011 4:20 am
by sdrubble
ClymAngus wrote:
congratulations your fine works have been officially recognised in Caduceus Canon.

Check the wiki. :D
I'm deeply honored sir.

Looks like we've been internally connected thru higher levels of Existence... "Sincronicity", that's how we call this while still temporarily bound by the tri-dimensional levels of Earth-constrained incarnation. :mrgreen:

While I consider your approval to be one step further into publishing an offspring OXP - or maybe simply hooking the new genetic variation as a new download from the original Caduceus Canon - there's still some way to go. :roll:

I've got a feeling that around the forum and wiki there's a somewhat, erm, "elders consensus" of what is acceptable or not. While there are some eventual obviously cheating-targeted initiatives like Thargoid's ooCheat, I suspect that a new Caduceus variant would have to be sort of "toned down" as to its perceived über-überness and required to be subdued into some sort-of-normal ship. OTOH, it might very well be accepted for what it is, i.e. an outrageously powerful instrument seeking a niche among players that tend to feel cumbersome inside most action simulators and would (or not...) freely admit some sort of cheating to compensate for their self-perceived deficiencies.

In any case I will shortly start a forum thread about this *possibly* new OXP, and pointing to this one thread here, and we'll see where the Cosmic winds will take us to.

As to the possible christening of the new Caduceus offspring, I see that while I had my own ideas on it, your mentioning of the word 'Homunculus' suggests you might prefer this denomination. That's fine with me - however would you care to provide the background on your preference ? Wikipedia has a number of different references on this, so that some nudge in a general direction would be welcome.
Canon, I really hate that word. I much prefer "accommodation of new ideas".
Mmm, I don't think that 'new ideas' do exist. What always happens is that some human being gains access to whatever idea was floating around the multiple levels of Conscience. So that he/she can express it and claim "intellectual property" over it... :wink:

So that the word Canon, if I understood correctly what Wikipedia (again...) means, reflects a pretentious concept of men, regarding the condensation or concentration of whatever 'known' knowledge into some kind of repository. But of course, you can have your Caduceus Canon, sir. :lol:

Cheers, Joy and Light*

*I'm just a bit more inspired today than usual...