K-Editor v1.12

[Phoenix-D]

I seem to remeber this having a manual or read-me file explaining how it works once upon a time. My current Version doesn't have one. Did it, or am I just loosing it (again)?

Phoenix-D

[Krsqk]

Thanks for the kind words. They are a big incentive to continue working on this.

As for the Readme.txt, there was one with the old Python-created Version 0.75; I didn't update it for inclusion with the VB6 Versions (v1.0 and up). That was my project Last night/this morning, and here's the new file. I think it's pretty understandable, but it is in a technical manual sort of writing style. If you still have questions, do the email/PM thing. Here's the link:

Readme.txt for K-Editor v1.12.

I'll get on uploading v1.12 after I fix a couple of minor bugs I found Last night.

[ January 03, 2003, 02:25: Message edited by: Krsqk ]

[Krsqk]

Ok, Version 1.12 is officially posted. See my sig for the links. Especially, please let me know what you think of the Readme.txt file--if it can be made any clearer, I would like to do so. Maybe I'll just have to learn about making .HLP files.

I'm considering some changes to the interface, based on Geo's comments. I'd like to make it more intuitive and user-friendly, while still keeping the same features. I'm considering going with a wizard-type interface--step by step through component creation. This would inevitably mean I'd have to add some features--importing TechAreas.txt, creating facilities, maybe vehicle types, etc.--but this would also mean increasing the size of the executable by quite a bit. The question to you is whether it's worth it. I don't plan on getting into importing Components.txt, or anything like that, but it seems a simple interface and some more editing (as opposed to creating) abilities are preferred by at least a few people. Feedback?

[Skulky]

2 things.

first thing.

the first, i got this error when i tried to run the most recent Version

Failed to load control 'SSTab' from Tabctl32.ocx. Your Version of Tabctl32.ocs may be outdated. Make sure you are using the Version of the control that was provided with your application.

Not quite sure what that means, i downloaded the one listed in your sig by the way.

second thing.

Is there a tech tree editor somewhere? Where i could make up racials and stuff easier? If not, any suggestions as to how one should go about a total conVersion of the tech tree, and resulting changes to components.

thanks

[Phoenix-D]

I'll check the new Version out and let you know what I think. If it does tech-grid components well, it'll be a real time-saver. Those are extremely tedious to do by hand..

Phoenix-D

[DavidG]

Originally posted by Phoenix-D:
I'll check the new Version out and let you know what I think. If it does tech-grid components well, it'll be a real time-saver. Those are extremely tedious to do by hand..

Phoenix-D

Can you explain what you mean by a "tech-grid component"?

[ January 03, 2003, 23:53: Message edited by: DavidG ]

[Krsqk]

Sometimes called a dimensional component. Take each tech requirement, and it's one dimension to the matrix. Two requirements generates a "square" component, three requirements generates a "cube" component, etc. This would be useful, for example, to create missiles with separate tech levels which affect range, damage, and speed. Here's a sample 2-dimensional component with "sides" of "size" 3; the numbers represent tech levels.

code:

---

Damage:  1     2     3

Range:

  1     1/1 | 1/2 | 1/3

  2     2/1 | 2/2 | 2/3

  3     3/1 | 3/2 | 3/3

---

Notice that instead of 3 component levels, there are nine. With a three dimensional component, there would be 27:

code:

---

Speed:         1           ||           2           ||           3

     1/1/1 | 1/1/2 | 1/1/3 || 2/1/1 | 2/1/2 | 2/1/3 || 3/1/1 | 3/1/2 | 3/1/3

     1/2/1 | 1/2/2 | 1/2/3 || 2/2/1 | 2/2/2 | 2/2/3 || 3/2/1 | 3/2/2 | 3/2/3

     1/3/1 | 1/3/2 | 1/3/3 || 2/3/1 | 2/3/2 | 2/3/3 || 3/3/1 | 3/3/2 | 3/3/3

                           ||                       ||

---

As you can probably imagine, this gets very cumbersome to hand-code, as well as being very error-prone. These issues grow exponentially with every additional dimension or "size" increase.

[ January 04, 2003, 04:42: Message edited by: Krsqk ]

[Krsqk]

Bump...was that a clear explanation?

[Phoenix-D]

Hmm. Having a bit of a problem making a tech-grid component.

Everything is working decently, if not quite how I expected..but the "range at base damage" entry isn't. No matter what I do with that field, the range of the component never changes.

Phoenix-D

[DavidG]

Originally posted by Krsqk:
Bump...was that a clear explanation?

Still a bit fuzzy (at least with the 3d one) but I think I get the general idea. Thanks.

< Ediot > OK tried your program again after actually reading the readme file so I get it now. Pretty cool!

[ January 12, 2003, 01:05: Message edited by: DavidG ]