Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Add built-in calculations. One can go far than just having a built-in bible, you can set a limitation warning when a developer goes out of bounds. What I mean is like for example lets say the person has created dozens of ship and lets say they are going to make one more which would of had a ship ID 192. Well a warning message pop up will tell the person that they can no longer make anymore ships since they have reached the limit, and then show them a part in the bible where it says so. Using quotes of a bible to explain the warning message will help alot.
Another idea is to make an extension feature. What this means is that while most editors can call up original EV/O/N data resources, one could make it so that it can also call up plug-ins, incase anyone wants to make a plug-in compatible. Also another feature would be an extensions manager that can allow you to enable or disable certain plug-ins. Should there be any conflict between certain numbers of plug-ins. That person would be given a choice to disable which ones and stuff.
Personally I like the idea of having a plug-in extensions manager.
------------------ Nosumus Fortiolis Quad Volimus
Quote
Originally posted by Coraxus: **Add built-in calculations. One can go far than just having a built-in bible, you can set a limitation warning when a developer goes out of bounds. What I mean is like for example lets say the person has created dozens of ship and lets say they are going to make one more which would of had a ship ID 192. Well a warning message pop up will tell the person that they can no longer make anymore ships since they have reached the limit, and then show them a part in the bible where it says so. Using quotes of a bible to explain the warning message will help alot.
**
EV-ONE will validate every resource the user creates or edits and checks every field against the requirements of the target program (EV/EVO/EVN). It also keeps track of every resource id and notifies the user when one is out of range or already taken. You will be happy to know that your extensions feature was implemented in EV-ONE three weeks ago. EV-ONE comes complete with a Data Files manager, allowing the user to leave all the aliases in the data files folder and enable and disable them on the fly. When the user creates a new plugin, EV-ONE automatically enables the data files that belong to the target program.
I believe that there was an extensions manager for EV a while ago, though it has probably not been carbonized. it is a good feature suggestion and should be quite easy to implement.
Jeffrey - Arios SoftWare
------------------
Originally posted by Platypus Man: **Something I liked about EV-Edit with the other two games and that I miss having for Nova is having an editor that displays a map of the galaxy and allows you to visually edit the locations of the systems and hyperlinks between them. Nova-wise, I think everything else is covered by NovaTools. **
Hrm. The point here is valid. EVO Dev Map had bugs in selecting different data files... EV Edit did not. An application which combined many things like this would be neat. One that is more self-explanatory, too.
------------------ Lequis Design lequis.netfirms.com PhantoM_63ff@hotmail.com
Originally posted by NTiOzymandias: **Pascal....?
WHY?!?!
explode**
Pascal is a great level 3 language. MacOS in the 80s and 90s was Pascal and 68k Assembler based, and that is when ResEdit was written and designed. The interface for ResEdit plugins is 68k assembler and Pascal, using MPW to compile and do the fancy linking.
ATMOS was already using ResEdit under OS9 with TMPLs for Nova, so leveraging off that made a huge amount of sense. The public release of NovaTools was a side effect, not the primary aim at all.
Besides, I must be one of the few remaining mac programmers who can still use that technology (I've been programming macs since 1984). I also program in FORTRAN under UNIX for high performance scientific simulations on supercomputers, and in C for telescope control by embedded cpus. In MacOS 9 and carbon and OSX I prefer C, and JAVA for javastations, and a little C++ for fun. My own OSX game project, 'VAST' , is in C.
Pascal and FORTRAN are in many ways more advanced languages than C, which is only a few steps above a macro assembler in my opinion. C++ comes closer to a reliable C, but performance/efficiency is often an issue there. I like Pascal set operators and definitions, local scope routines and much stronger typing. Once you add units and typcasting (as Apple did to Pascal), then it is fully as powerful as C. C is just more common - but then sports cars are rarer than ordinary sedans too, are they worse? I like to drive both
Cheers Ralph
------------------ (url="http://"http://homepage.mac.com/dr_ralph/index.html") w00tWare: NovaTools are here!(/url)