Partial Success need some help with xsd schema hacking (making non-tradable techs)

The schema documents, it doesn't define. Fudging it so it passes validation isn't going to add functionality to the game that isn't there.

Thanks kryo. Pre-edit, my response frlt like it came off snarky after I hit submit

 In my experience with modding galcivII /II, just about any function/tag can be copied from one xml into another xml since the individual bits seem to work a lot like unix style command piping where  have it work fine after adding stuff to the xsl's if needed(f/ex I've used upr/shipcomponents/planetaryimprovements/etc stuff in colonizationevents, ideology, plametdefs,   buildings,  with success).  GalcivII was more likely to crash while galcivIII has a better validation.  modders only have one side of the coin (the xml/xsl with the compiled binaries black boxes), sometimes we throw things at the fan to see what passes through .  When I did my galcivII modding, there were some very very old threads that turned out to be more useful than people likely expected at the time, maybe this one will be too... if nothing else it's a good "here's a bunch of stuff that won;'t work, nobody has found something better"

All things being equal, the fact that <RootNode>true</RootNode><ResearchCost>0</ResearchCost> makes a seemingly untradable tech you can assign at the start of the game & that things can be gated with multiple tech prereequ's (I think) or either/or prerequ's(some of the extreme planets are a good example) gives it a pseudo option for modders in the future.  Having the details on galcivIII beta4 patch1's results documented above could be beneficial for folks later when more options/different validation might be in place after a few dlc/expansions & the rootnode makes for what looks to be a good partial option till then if nobody figures out another option:).

While It's possible that just clicking ignore instead of skip/quit might not worked at all have worked fine, I have family visiting the next couple days & won't get to test it any time soon. .  The engine for processing the xml files is remarkably robust & flexible (even more than galcivII's where starbases & a couple other things used unique xml tags)... since I don;t think that was a upr  in gcII, it seems reasonable that it would follow suit with the increased flexability & openness. 

Tetrasodium,

This does not create a tech. It creates an entirely new (logical) tech tree. And because the ResearchCost is equal to zero, and its <Prerequ> is set to PropagationTech, and its <TechTree> is set to Yor_Tree, it is then automatically attached to which every faction has said PropagationTech and uses the Yor_Tree tree. Which in your case is only the Yor.

What you have done here is to actually create a second logical tech tree and entered it into the organization tech tree (Yor_Tech). In effect you have transformed the organizational tree into a two tree forest, with the second tree dependently linked to a node in the first tree.

In the [race]TechDefs.xml file the <TechTree> tag determines to which organizational tree a tech belongs. And the tag <TechTree> in the FactionDefs.xml file determines which faction uses (can research) nodes in that organization tree.

The <RootNode> tag indicates whether a node in the logical tree is the root of that tree or a normal node. There should be one and only one node with <RootNode> set to true in a logical tree. And this root node should have exactly 4 child nodes; the four disciplines: Expansion (Social), Engineering, Warfare, and Conversion (Commercial, Culture, Approval). And there should be only one logical tech tree in a organizational tech tree.

The fact that your solution sort of works is a sign of the fault-robustness of both the xml and the data engine of GalCiv3; or maybe it is intended that factions can have multiple logical tech trees.

The structure of the Logical Tech tree is determined by the links made by the <GenericName> and <Prerequ><Techs><Option> tags. And the only node without a <Prerequ> tag is the RootNode.

A tech is tradeable if the two negotiating factions both have a tech with identical <GenericName> tags in their organizational tech tree.

If it help to visualize:

Think of the organizational tree as the unordered collection of techs (that are research-able) by your faction; And think of the logical tech tree as the structure of the interdependence of the those techs.

so the answer is to make up a unique generic name? 

i was going to say there should be several techs already that cant be traded the krynn's 'the way or the path' techs w/e they are called the yor's spark of life techs

double

While I agree, & think I know how to make that work (details below), thanks to what thecw & androshalforc added while I was out having korean bbq with visiting family, changing that would require going into the various xml files that reference those techs & setting them all to function like frozen world in planettraitdefs.xml where you can have

<ColonizationPrerequ>
<Techs>
<Option>ExtremeWorldColonization</Option>
<Option>PropagationTech</Option>
</Techs>
</ColonizationPrerequ>

or anything in the tech tree that has a foldout as one of the prerequ's i.e.:

<Prerequ>
<Techs>
<Option>IndustrialSpecialization1</Option>
<Option>IndustrialSpecialization2</Option>
<Option>IndustrialSpecialization3</Option>
</Techs>
</prerequ>

assuming <prerequ> can  also support <option> under whatever recognizes those things that shouldn't be tradable, but since almost everything gated is gated by the tech tree in some way, or exists in a file where something is gated by a tech, that last option will likely work almost everywhere

regarding thecw's comment, giving it a cost & prerequ  (as noted) appears to tkip the need to actually research it  but shows it on the tech tree, , removing the cost & prerequ should prompte the tree to a forestm but the new tree doesn't appear to show anyplace I could see (and makes a nice hidden gateway as a result:).  in my testing, the yortesttech was only in the yor tree... as noted by thecw & androshalforc to varying degrees, giving everyone else $racenaametesttech rather than just testtech for the genericname would work great for purposes of future mods regardless of weather or not a fluff item is shown on the tech trees.  ot looks like I got one to work but it was working for a different reason than suspected & I didn't go digging because my idea didn't need it to show up

Since it seems like the solution is looking like it will be "give every race a tech with unique GenericNames", it might be something that should be included with final release for purposes of mod interoperability rather than make anyone who might have some reason to make something behave differently for different races go making custom tech trees for each affected race.

... I think you're over thinking this ill admit I'm not very good at modding, i tend to work on gut feeling rather then understanding. but it feels like this should have a very easy solution

I didn't include the relevant bits in my first post by oversight, bur I was originally trying to combine this:

<UPResolution>
<InternalName>TechnologyNonInterferenceAct</InternalName>
<DisplayName>TechnologyNonInterferenceAct_Name</DisplayName>
<Description>TechnologyNonInterferenceAct_Dec</Description>
<Question>TechnologyNonInterferenceAct_Question</Question>
<VoteType>
<VoteType>YesNo</VoteType>
</VoteType>
<PersonalityTraitModifier>
<PersonalityTrait>Scientific</PersonalityTrait>
<VoteInfluence>-10</VoteInfluence>
</PersonalityTraitModifier>
<PersonalityTraitModifier>
<PersonalityTrait>Spiritual</PersonalityTrait>
<VoteInfluence>10</VoteInfluence>
</PersonalityTraitModifier>
<Behavior>BlockTechTrading</Behavior>
<Modifier>
<EffectType>CreditsPerTurn</EffectType>
<Scope>UPResolutionGalaxy</Scope>
<Target>
<TargetType>Faction</TargetType>
</Target>
<BonusType>Multiplier</BonusType>
<Value>-0.01</Value>
</Modifier>
</UPResolution>

with a modified bolded bit from this:

<UPResolution>
<InternalName>UnitedPlanetsResearchFoundation</InternalName>
<DisplayName>UnitedPlanetsResearchFoundation_Name</DisplayName>
<Description>UnitedPlanetsResearchFoundation_Dec</Description>
<Question>UnitedPlanetsResearchFoundation_Question</Question>
<VoteType>
<VoteType>YesNo</VoteType>
</VoteType>
<PersonalityTraitModifier>
<PersonalityTrait>Scientific</PersonalityTrait>
<VoteInfluence>10</VoteInfluence>
</PersonalityTraitModifier>
<PersonalityTraitModifier>
<PersonalityTrait>Xenophobic</PersonalityTrait>
<VoteInfluence>-10</VoteInfluence>
</PersonalityTraitModifier>
<Behavior>ResearchDiscount</Behavior>
<SpecialValue>
<Special>ResearchTag</Special>
<ValueParam>0.25</ValueParam>
<StringParam>NonMilitary</StringParam>
</SpecialValue>
<Modifier>
<EffectType>CreditsPerTurn</EffectType>
<Scope>UPResolutionGalaxy</Scope>
<Target>
<TargetType>Faction</TargetType>
</Target>
<BonusType>Multiplier</BonusType>
<Value>-0.05</Value>
</Modifier>
</UPResolution>

Since the stringParam can be almost anything (I experimented with in in 0.61) so long as you go through the tech trees & add new    <Tags>Not-NonMilitary</Tags> to techs (worst case it just applies to no techs iirc)  it seems like combining BlockTechTrading with a <special>ResearchTag</Special><StringParam>NewTag</StringParam>might be a far more elegant solution since it would only require modding the one tech,  not break any mods that rely on that gateway tech simply existing as a gateway,  while also also allowing BlockTechBrokering & any other Block options I've overlooked from other locations.  Unfortunately, I couldn't find a way that it liked existing in the tech tree rather than the UPResolutions.xml.  a useful workaround for the future might be if we could set a UPResoltion to be in effect at turn0 with things like:

Not repealable:

<VoteType>
<VoteType>AlwaysTrue</VoteType>
</VoteType>

Repealable:

<VoteType>
<VoteType>DefaultTrue</VoteType>
</VoteType>

It would still require modding one or more techs, but not all of the things that use them as prerequ's where mod interoperability could become a more likely issue. I originally started looking into this out of a desire to figure out if pulling together ideas for a later mod was something even possible  (massively expanding the non-extreme worlds in PlanetTraitDefs.xml) like desert, breadbasjet, shielded, etc to have race specific     <ExtremeTypeModifiers>top where different races get different benefits from different new additions.  Since the ability to seed them into  PlanetDefs.xml  (or whatever defines just habitable worlds, I'm pretty sure I've seen it before) is only a "would be nice" part of the idea, I stopped testoing at finding an untradable tech