See... below!

And here's the visual proof.



- When switching locations of "Abduction" with "Sabotage_Group" straight into the xml file order; the tree developped as it should.

- But, whatever i tried with "Xeno Business" and "Entertainers" wouldn't since "Influencing" is after "Xeno Business"!!

Meaning; It is parsed alphabetically within a given ID-Branch as they are written in a top-down sequence within the xml... but the condition resets after evaluating the number of subsequent techs to the right of anything. Then priority_UP kicks in, the parser keeps going until the lowest xml content fits in (think rare Spore techs!).

Left-To-Right unless MORE techs must be shown above anything below a specific Node.

Tadaammm.

bsaksida, you're a genius.

Now... are you up for another challenge?
Read the *Technos Numbering* thread and lemme know eventually!

I quote myself...
I also want to be genius

Oh, you most certainly also are! But did you mention the quantities necessary to the right of any given path which re-orders the biggy amount line(s) above anything else?

Then, you might call yourself "quantitymaster" ^^
BTW, still no success placing my "Fusion Pulse Drive" at the top, I need to restructure the tree for this to be happen

So if you wanted to swap the order of the entire TRADE and XENO-ENTERTAINMENT branches, you would need to make sure that all of the XENO-ENTERTAINMENT techs are in the XML file before the first TRADE tech?

Sounds promising, I'll play around with this soon.

Thanks!!!

Nope!

Look left for the preq and also look right to find how many techs are consequential to any given pre-ordered (alphabetically) lines even through an xml re-location (via branching similarities or otherwise) editing round -- sort of.

Nothing better than testing and solid reference or evidence.

bsaksida gets most of the credit, btw.
Say somethin' like; 5%_me, 45%_MrKorx & 50%_bsaksida
Etc...

I still can't figure out how to make it work for TA.

First, I'm dealing with three TechTree files - the default one (techtree.xml), the default custom one (custom_techtree.xml), and the modified custom one (custom_techtree.xml in the MODS directory).

I might be able to get rid of the third, but the problem is still the same - how do I order techs between multiple XML files?

Second, I can't even make it work for techs which are all defined in a single XML file.

Some details:

I'm trying to reorder all the Thalan techs to be based on the concept of "Adaption." As such, I've added Adaption levels 0-4. Each tech branches off one of these adaption levels, depending on how much the Thalan must adapt their own technologies to this universe. Basic things such as Xeno Ethics, or things they pre-planned such as the Hyperion Matrix, are adaption level 0. The three levels of industrial adaption are tied to these adaption levels. Adaption level 4 is for some end-game stuff that I've created: Warp Drives, MechaGodzilla invasion techniques, etc.

Adaption levels 0-2 have 14 techs off them, Adaption level 3 has 11 subordinate techs, and Adaption level 4 has 4 in its tree.

So I would like to do the following:
* Make each adaption level appear at the BOTTOM of the tree for each previous adaption level. For some reason, it's currently appearing THIRD no matter what.
* Reorder the techs, within each adaption level, to have some concept of logic. Maybe government, foreign interaction (trade & influence), financial, research, industry, drives, and war.

I currently do not have any techs with two prerequisites, although I would like to experiment with this once I have the ordering sorted.

Has anybody been able to reorder techs in TA? Including new techs?

Awesome, guys!

@DisneyDestroyer



This is not possible, at least to my knowledge.
The game only allows ONE dependency.

For the rest of your question, (re)read post #27 carefully

Thanks, actually Zyxpsilon told me (in PM) that his fix doesn't apply to TA, he's not sure if/how it would work. He was the one who suggested I ask for TA-specific clarification, hence post #33.

Regarding two prerequisites - it has worked for me in DA. It only shows a single line, but you can't research the tech until you've researched both prerequisites. I'm not sure how TA would handle it, let alone the tools.

I've been able to reorder some branches, not too many.
However, the solution does not seem to work out properly for TA.

Another question appears...
If I create 5 PI(superprojects) Mk1 upgradeable by 5 PI(superprojects) Mk2 with the 'colonize special worlds' ability, then this works fine. BUT the planet icon does not update properly to say yellow, as it usually does, when the ability is being unlocked by the techtree.
It's a minor annoyance.

Dunno if you could provide us with a sort of 'image' that could guide us a bit further towards a specific hint.
For what it's worth, i believe the tech-editor does have its own relative calibration re-writing procedures (as both the Default_tree and the new Custom_tree(s)... must depend on each other for common resources) as soon as you click Save.
This actually scans the entire new file for doubled Branch-IDs and simply slaps the default tag... while somehow altering any text which may have been there in the first place.

Thus, my doubt about a reliable method to design a strict type of assembly-framework for techs locations as they relate to the hypothesis presented in the OP. Well, at least not without a huge visualization skill that's for sure.
TA has its strange connections but might also automatically screw up (in a good or required way, in fact) whatever pseudo-orderings we create and wish for.

I can only do so much, as i'm developping my very own EXTREMELY complex DA tree for X-Worlds in a manner which isn't exactly conscious of any specific variations of key-locations for techs A, B or C, etc. I had to relocate a few things here & there.. so that it looks 'logical' enough and easy to consult, but that's all.

Surprising, indeed, that some double pre-requisites can indirectly be swallowed up by the engine. If anything, that opens up a gauntlet of other interesting possibilities.

I guess at 90%, the solution may just be a matter of identifying the exact Twilight rules (Darn, we absolutely & surely need any of the SD coders' knowledge for that) which are applied to the new multiple trees and its centralistic approach at general layouts resulting from alterations (even if properly ordered as intended!)-- hopefully compatible and accurate, btw.

So -- some some sort of a snapshot, please?

Specifically about the above, this is a Sequencing attempt, right?
Cuz, the left2right schema would certainly influence whatever amounts are distributed between X and Y node pathways as they could be written up ON the *developping at runtime* tree framework.

There is a very good reason for this engine routine, btw;

Newly acquired techs such as The Evil ethics triplet of weaponries which must be inserted after discovery from a fresh gathering of total_global items rather than inserting into or from a preloaded grid.

Consequently, when the research screen pops up, we don't recognize the activity since it is very fast and yet, a complete re-organization is happening.

Thus the analogy of Custom_trees.xml vs Default.xml as they combine to make up what we see at the current stage of gameplay... an everchanging loop of slots allocation - so to speak.

Isn't this based on the integer count that invariably adds a 50% for each #-ONE value until 100% is reached?
Cuz, if you were to slap a Minus (1 or 2, btw) to the Mk1, it would take twice the time to obtain the expected 50% level and so on.

yes, if I build say the Aquacontroller I(ability 32=1), then the little lefty window updates the planeticon to yellow, but not on the starmap instantly, despite of this, after reloading the save, the starmap planet icon got also updated as it should.
I'd say, this is a glitch, and solved by a simple "redraw engine call" when ability 31-35 are set

I'm trying to add a screencap, but I can't find the image after printscreen! ARGH.

CTRL-PrintScreen does save these files into the c:\MyDocuments\MyGames\GC2Twilight\Screenshots folder, i'm quite sure.

OK did it, here's an image of the top of the tech tree.

I would prefer to have all the techs FIRST, then the next level of adaption.

http://img338.imageshack.us/my.php?image=researchtreeew1.jpg

Try this:

http://img338.imageshack.us/my.php?image=researchtreeew1.jpg

Btw, all you need(ed) to do is insert the terms (IMG) before & (/IMG) after the link itself within brackets (instead of the above parenthesis typed here for proper formatting reasons) such as [ *** ]... and your image would have shown straight into the forum engine.

In the meantime, i'll have a look at this and let you know later if i can figure somethin' out.

Ahhhhh, now i know exactly what you're up against.

-- With the huge number of techs in each ***COLUMNS***, there is obviously a plumbers' pipe clugging rush to exit any given instances of these Adaption (or is it, Adaptation??) levels.

-- One basic fundamental aspect which i thought was clear to anyone trying to re-organize the layout of trees is that NO connections can diagonally overwrite anything deploying under the root source tech-box currently in focus; ex_cluding the rule-based special cases of Ethics weapons & defenses and Neutral Buildings, etc which are inserted by the game engine rather than pulled straight off the default file since an ingame condition toggle must be turned ON.

-- The alphabetic parsing CANNOT override the amount of connections as they are calculated to fit under each other;

a) If there are, say, 5 preqs nicely lined-up under a single column and the first has less allowed slots to deploy to its right - IT simply will receive the highest priority OR be given another row only when the connections DO NOT interfere with the subsequent layering process.

Then if the second has MORE techs to deploy to its right - IT may get to have the highest priority but only if the above interference rule is respected.

c) The last (as a result) will always be the most with the higher 'volume' (as perceived from the same logic particularities implied by the DO_NOT_OVERWRITE_CONNECTION_LINES strict rule) because it makes sense to have it distributed without introducing unnecessary confusion by an X (//\/.. sort of) type of collision.

It may not be so obvious to some, but the number of connections must remain under a minimal (or feasible) distribution schema for it to be readable. Thus, the tree parsing algorithm reacts to some amounts and connections points relative locations.
Meaning, what you want to do is almost impossible to do without evaluating the exact connections flaw(s) created from editing the xml order - if there is.

One more thing to note though... everything which worked in DA (and previously discussed) still applies to TA, it seems.

head... exploding...

columns? volume? diagonally overwrite?

It seems like there's a ton of background information about tech trees that I'm missing.

Can you please try to dumb it down for me?

Something along the lines of the following:
We're talking about a set of techs that all have the same tech as a prerequisite.
- If they're all single techs or groups (with nothing else below them), they're ordered according to the order they're first declared. The XML files are parsed in order: base tech tree first, then the default race tech tree, then the custom tech tree.
- If they all have other techs after them, they're ordered according to the number of all techs below (including continuing down the line as far as necessary)
- If some have techs after them and others don't, they're ordered alphabetically.
Then this is repeated for all the sub-techs.

Also, I should say that the image is only 1/3 of the tech tree. For example, under Adaption Level I, there's another 8 techs below the Adaption Level II that you're seeing, which couldn't be captured in the screencap.

Thanks!

A) & above are the only important part that you must realize before delving deeper into a plan for reorganization of any wanted or possible layout.

The easiest way to fully grasp the basic principle behind left_to_right calculations is to know exactly how many techs are present (minimally presented in my #27 post) in any given node AS IT IS connected (as in, final, frozen, uneditable even if an alphabetic parsing could modify the location) to the previous preq(s).

isn't really what's happening - since

1) the xml text file could have any of the source nodes scrambled all over the place, it still would have to find out how many techs are to its right until the whole path runs out of items. Then this value is number X.

2) as the engine gets to the next node below the one mentioned in #1 above (while it knows number X is equal to say 15 in total)... it simply finds out that everything to the right of the node currently under evaluation makes for a total of ****16****.

Second node must go above the first.

Priority_UP kicks in as i stated in an earlier post.

Then, and only then... if a diagonal connection overwrite causes the setup to collapse will the parser have to reset the layout.

Now, my whole argument is also based on the fact that a central core default tech resource is scanned to produce these connections at runtime while it also must take into account what differs or/and corresponds in a secondary race_tech_tree.

Knowing this, the final layout still has to stick to some general rules WHEN it has completed its analysis of the left_to_right ratio(s) it just found.
And, then deploys all these techs to the end of file_S.

Head, lightened.

It's logical, abstracted to my best explanation.

One last thing; my X-Worlds tech-tree (which is extremely complex also, btw) is made up with ONLY two very strict principles in mind;

-- The default(s) xml structure aren't touched (order, alpha, 1 to 272 items, first to last) except for some extra techs preqs modification and other values like cost, descriptions. The branches IDS are all still exactly where they were. Nothing inserted, moved or renamed. (When i compare two files, its much easier to detect a flaw)

-- Everything new is written after and below the GC listing in a single coherent block of references. (Again, much faster to edit and compare).

That's all i can do for you, buddy. Good luck, and let us all know if you find THE way --- of the Krynn.

Ynrhed Eidden of The Krynn here, reporting as ordered or parsed --

Kay, let's try this again but this time, i will attempt to be much more cohesive and precise with a fairly good example.

When i was fleshing out the XW_TechTree and decided to make it a bit (lot) more leaner, some areas weren't grouping or deploying as i truly wanted too. Namely, the tricky Hulls and Buildings node.

It took me quite awhile to devise an indirect solution as i figured the obstacles to any alternative settings i'd care to slap in at mere random guesses.

Abstracted and step by step, here's what happened about two months ago. Although, i shoulda taken snapshots back then, it was easy to reproduce the process... so, take a good look at the image below with its A_B_C_D_E and/or F sections & the default values found in an XML file excerpt.




Very, very simple;

A) Grouping Hulls only. (Connections conflict!)

Grouping 1-Hulls & 2-Buildings as specifically unique. (Ooops, and this is the IMPORTANT part... SuperiorHulls_#128(yellowed off) is at the end instead of between Medium & Large Scale buildings as it should.)

C) Alright, this must be fixed... UN-grouping the Hulls but assembling Buildings only. (Ooops, once more... LargeScale (purpled off) didn't get to show SuperiorHulls as its valid preq. Besides a few more odd things creeped into the temporary structure.)

D) Re-Grouping H&B together. With a small (but maybe conflicting, btw) edit to the XML order to MOVE SuperiorHulls straight between M&L scale Buildings. Note this though; it is no longer recognized as #128 and as a result the other techs of this whole node MUST receive new numeric tags. (Ooops, the preqs aren't tied where they should either!)

E) Un-Grouping Buildings once more... only to realize; the connections are still somehow, unreadable although in the expected sequence and that if this stays as is, it would be difficult to determine the exact preqs of Hulls.

F) Final... everything as clear as possible without making MassiveScaleBuildings less important than it should since it is, in fact the last of its group.


Done, ordered as i would expect. But, not without having to edit the xml to force a single move (#128, thus becoming #123, etc) from the default tree previous location.

Connections -- non-intrusive. Sequence -- exactly right.

Now, you may say: What's this got to do with reversing or re-organizing a specific node above or below anything else even if the number of techs to the right of everything MUST be evaluated?

Much more than i believed at first before i finally nailed the parsing rules as they apply to any circumstances or modder's needs.