No promise, no ETA, not even "two weeks "
Already in the wish list:
- MDI application (multiple windows to view/edit many objects/cores at the same time)
- better and larger UI windows for all objects
- change to objects hierarchy and attributes names to match source code
- core header (author, version, url, comments, etc) (stored in core)
- names for pre/def/local tech numbers (stored in core)
- visual editor for tech tree (with hypergraph/hyperbolic display)
- names for projectiles (stored in core)
- more navigation shortcuts everywhere (like going to projectile from weapon with a single click)
- more bookmarks (only 2 in current ICE)
- import/export and cut/copy/paste between cores
- dump cores to HTML and/or XML for documentation purpose
- dump dependant artwork files list (+ check if files exist)
- more "filters" options (faction filter for instance, reverse filter)
- eventually an integrated core simulator to test cores
- names for DMs and ACs (stored in core)
I'm currently porting the Java source of hypergraph to C# and finishing ICGLib.dll which will be an "IGC I/O managed DLL" (load ans save .igc files) generated directly from Alleg sources (R4 and above).
Once these 2 are finished (no ETA), I plan to start working on ICE II (full managed C# project).
But once again nothing is certain, this might just end up into oblivion (not the sector:p)
I'm just gathering ideas and wishes for now. So go ahead.
edit: if your idea/wish is about new feature for cores rather than about editing cores, use this topic.
edit: added some of your suggestions.
ICE II
-
- Posts: 6993
- Joined: Thu Aug 07, 2003 7:00 am
- Location: Green Bay, WI
I'll repost my ideas here, some might take small code changes, but eh
- Could you add a check option? That option could check if everything works and that the core will not crash.
I often make silly mistakes when I change stuff and it would save me a lot of time.
Examples:
-It could check if every tech that replace another exist(If you just remove starbase, a core will crash if you don't tell the garrison that it cannot be upgraded anymore).
-It could check if every faction links to a proper pod and a proper garrison.
-It could check if every drone is linked to a proper ship
-Etc...
-Make the name of the armor classes dependant on the core rather than fixed.
-Make the time required for an aleph res to blow up dependant on a missile property rather than a global core setting.
-Add more "masks" for the ripcord ability(10 instead of 2 would be great).
-Could you add more numbers? there's nearly 300 and I didn't run out, but there are many ideas I could use if I had a lot more.
-I would like a manual classification system. Example: I could label an interceptor class and link all interceptors to it. Then, I could choose to load the "interceptor" class and would see all objects that I put it there.
I'm planning to have unique names for all the ships in my core. The main reason I haven't renamed them yet is that I like to have all expansion ships next to each others in ICE.
Then a more complicated idea, but still something I'd like:
-Could you make 2 save format? 1 could be for developppement and one "real". I would love to have a documented version of my core. I'm note sure if a bigger core would slow the game or not, if it doesn't, it's not very important.
- Could you add a check option? That option could check if everything works and that the core will not crash.
I often make silly mistakes when I change stuff and it would save me a lot of time.
Examples:
-It could check if every tech that replace another exist(If you just remove starbase, a core will crash if you don't tell the garrison that it cannot be upgraded anymore).
-It could check if every faction links to a proper pod and a proper garrison.
-It could check if every drone is linked to a proper ship
-Etc...
-Make the name of the armor classes dependant on the core rather than fixed.
-Make the time required for an aleph res to blow up dependant on a missile property rather than a global core setting.
-Add more "masks" for the ripcord ability(10 instead of 2 would be great).
-Could you add more numbers? there's nearly 300 and I didn't run out, but there are many ideas I could use if I had a lot more.
-I would like a manual classification system. Example: I could label an interceptor class and link all interceptors to it. Then, I could choose to load the "interceptor" class and would see all objects that I put it there.
I'm planning to have unique names for all the ships in my core. The main reason I haven't renamed them yet is that I like to have all expansion ships next to each others in ICE.
Then a more complicated idea, but still something I'd like:
-Could you make 2 save format? 1 could be for developppement and one "real". I would love to have a documented version of my core. I'm note sure if a bigger core would slow the game or not, if it doesn't, it's not very important.
Posted this in the 'core' thread, but you said it goes here:
If you delete Booster 1 in the core, then the core crashes. If you make ICE so it can't delete items that would make the game crash if they are not existent, it would be very handy
And a few other things:
As mentioned, having items be able to use anything - Fuel, energy, ammo, whatever.
Integrated MDL viewer - Hit the button next to the model entry, and it would bring up a mdl view of the model, able to rotate and all, instead of just showing the skin
'Insert item' - Make an 'empty' version of an item from a set template, IE a cloak or booster. This would be handy if all of that kind were deleted, or making a core from scratch.
If you delete Booster 1 in the core, then the core crashes. If you make ICE so it can't delete items that would make the game crash if they are not existent, it would be very handy
And a few other things:
As mentioned, having items be able to use anything - Fuel, energy, ammo, whatever.
Integrated MDL viewer - Hit the button next to the model entry, and it would bring up a mdl view of the model, able to rotate and all, instead of just showing the skin
'Insert item' - Make an 'empty' version of an item from a set template, IE a cloak or booster. This would be handy if all of that kind were deleted, or making a core from scratch.
Bump!
-Allow for all ships of the same type (such as adv stl fighter) be stored in a drop down menu or something, and the ability to apply a multiplier to all at the same time.
-Allow for drone icons to be applied to different named cons.
-Allow for all ships of the same type (such as adv stl fighter) be stored in a drop down menu or something, and the ability to apply a multiplier to all at the same time.
-Allow for drone icons to be applied to different named cons.
Spidey's tactical advice on TS during Tourny game
QUOTE We don't need to save our thingy.[/quote]
QUOTE We don't need to save our thingy.[/quote]
lol nice necroposting.
As some already know, i'm officially retired from 'developping around alleg'.
ICE II project main purpose for me was to write a 'real project' implementing hyperbolic trees UI (HT here after) in C#.
Althought HT is far from mandatory for a core editor, it was the only real 'motivating' reason for me to write ICE II. Because back then I needed this for another project at work.
so porting HT to C# was a mandatory step but I gave up on this when I saw that ****** Xerox patented HT (at least in the US since they can't do this in Europe thanks to the European Patent Convention 2c and 2d).
Damn americans and their ****** patents/copyrights everywhere. I bet they would copyright the wheel if they could
Other than HT the other mandatory part was IGCLib (managed library to write/read cores) and that part is done (but not fully tested).
So someone can eventually take over and write a new ICE in C# (or any managed language) using IGCLib which can be downloaded (bin and source) at http://code.google.com/p/allegice/downloads/list .
As some already know, i'm officially retired from 'developping around alleg'.
ICE II project main purpose for me was to write a 'real project' implementing hyperbolic trees UI (HT here after) in C#.
Althought HT is far from mandatory for a core editor, it was the only real 'motivating' reason for me to write ICE II. Because back then I needed this for another project at work.
so porting HT to C# was a mandatory step but I gave up on this when I saw that ****** Xerox patented HT (at least in the US since they can't do this in Europe thanks to the European Patent Convention 2c and 2d).
Damn americans and their ****** patents/copyrights everywhere. I bet they would copyright the wheel if they could
Other than HT the other mandatory part was IGCLib (managed library to write/read cores) and that part is done (but not fully tested).
So someone can eventually take over and write a new ICE in C# (or any managed language) using IGCLib which can be downloaded (bin and source) at http://code.google.com/p/allegice/downloads/list .
KGJV wrote:QUOTE (KGJV @ Mar 18 2009, 08:55 PM) <{POST_SNAPBACK}>lol nice necroposting.
As some already know, i'm officially retired from 'developping around alleg'.
=(
Well at least you did team alliances for R5, im pretty sure spidey owes you $20 for that. And when am I going to see the count in-game? I'l go pure exp until you return!