Shooting For the Moon
TarotRedhand
Member Posts: 1,481
What would I want from an improved toolset? I have been thinking about this for a while now. I have come up with a number of proposals that I think are worthy of debate. Do I think any of this will happen? Some... maybe. OK because this is just my wish-list I have written it in a form that echoes a great man's speech from some decades ago (no offence intended, I just found it easier to frame it that way). So with apologies to the late Martin Luther King, here is my list.
________________________________________________________________________________________
I have a dream that one day we will have a vastly improved toolset. Where these 2 annoyances are fixed
In this dream you can have more than one area open in the toolset at once each open in its own tabbed space. And where you can work on scripts in their own tabs too. (like in modern programming integrated development environments).
And further in this dream is revealed to me the glories of an actual help system. Wonder upon wonders this help system is actually context sensitive. Then revelation on revelation, there was a built-in spellchecker that worked across the whole toolset from conversations to scripts.
And in my dream I saw that each unfinished module was allotted its own space on my HD in its very own folder. Only appearing in the main modules folder when I pushed a shining button marked [PUBLISH]. Then I beheld further wonders. That the toolset now supported a simplified, very easy to use versioning system so I could revert whole areas to previous versions. (but not on cloud storage e.g. GitHub)
Then my dreams turned to the script editor. What wonders there to behold? And I saw that it was good supporting intellisense and a built-in simple code generator that supported all the new code that lilac soul’s does not. It had actual debugging tools as well. It had a built-in snippets system and the ability to store user made functions in a database library for future use. And lo nad behold oPC becomes an official built-in object*.
As my dreams started to fade I could swear that I saw too other simpler things too. That double clicking on something in an area would automatically bring up its properties window. Finally I saw something the user could turn off. The icons at the top of the screen replaced with a modern ribbon control.
_________________________________________________________________________________________
an official built-in object* - OK this needs a little explanation. Consider this little snippet that is for use with a generic triggers OnEnter event.
Object oPC = GetEnteringObject();
if(GetIsPC(oPC))
{
//do stuff
}
Now oPC is used universally for to store the/a PC object. So why do we need to use a different function depending on the event just to make sure that it is the PC we are getting? Wouldn’t a more generic approach be better? With a built-in oPC object that could be used like -
oPC = GetTriggeringObject();
On those occasions when it is not the PC causing the event to be triggered that line would cause an automatic return from whatever function it is in. This line could then be used for any event without having to remember the actual function needed, without having to declare oPC over and over again and without having to write an if statement to test whether or not oPC was a PC.
And that's it. Thoughts anyone?
TR
________________________________________________________________________________________
I have a dream that one day we will have a vastly improved toolset. Where these 2 annoyances are fixed
- When EE's toolset is opened it is always in a small window instead of remembering its previous state.
- When you export anything to an erf file the revert to parent faction checkbox is pre-ticked. Instead of an opt-out we should have an opt-in system here. Untick it by default.
In this dream you can have more than one area open in the toolset at once each open in its own tabbed space. And where you can work on scripts in their own tabs too. (like in modern programming integrated development environments).
And further in this dream is revealed to me the glories of an actual help system. Wonder upon wonders this help system is actually context sensitive. Then revelation on revelation, there was a built-in spellchecker that worked across the whole toolset from conversations to scripts.
And in my dream I saw that each unfinished module was allotted its own space on my HD in its very own folder. Only appearing in the main modules folder when I pushed a shining button marked [PUBLISH]. Then I beheld further wonders. That the toolset now supported a simplified, very easy to use versioning system so I could revert whole areas to previous versions. (but not on cloud storage e.g. GitHub)
Then my dreams turned to the script editor. What wonders there to behold? And I saw that it was good supporting intellisense and a built-in simple code generator that supported all the new code that lilac soul’s does not. It had actual debugging tools as well. It had a built-in snippets system and the ability to store user made functions in a database library for future use. And lo nad behold oPC becomes an official built-in object*.
As my dreams started to fade I could swear that I saw too other simpler things too. That double clicking on something in an area would automatically bring up its properties window. Finally I saw something the user could turn off. The icons at the top of the screen replaced with a modern ribbon control.
_________________________________________________________________________________________
an official built-in object* - OK this needs a little explanation. Consider this little snippet that is for use with a generic triggers OnEnter event.
Object oPC = GetEnteringObject();
if(GetIsPC(oPC))
{
//do stuff
}
Now oPC is used universally for to store the/a PC object. So why do we need to use a different function depending on the event just to make sure that it is the PC we are getting? Wouldn’t a more generic approach be better? With a built-in oPC object that could be used like -
oPC = GetTriggeringObject();
On those occasions when it is not the PC causing the event to be triggered that line would cause an automatic return from whatever function it is in. This line could then be used for any event without having to remember the actual function needed, without having to declare oPC over and over again and without having to write an if statement to test whether or not oPC was a PC.
And that's it. Thoughts anyone?
TR
4
Comments
- improved performance
- Vastly improved performance
- greater support for dynamic content
- greater control over creature stats, such as being able to set ability score to 0
-Vastly, vastly improved performance
Basically, I want it so that having one or more editors open doesn't freeze the rest of the toolset. That one change would make the toolset so much more user friendly, it would be like a week of Saturdays!
Yes, yes! 90% of my scripts have "object oPC = (SomeGetFunction); if(!GetIsPC(oPC) {return;}" ... a built-in oPC object (that automatically verified it was a PC) could streamline that ugly little bit of kludge out of most scripts.
A thousand times yes! Little things like this would make all the difference for me. I personally don't need all the fancy features that come in super-expensive software development environments ... they might be cool, but I understand why they might not be feasible for a $20 video game. IMO, a handful of relatively minor (I think) usability tweaks like this would do the trick.
Here's one of my own, that I haven't seen mentioned but that I'd like to see: Object tinting. A lot of minor reskinning / retexturing could be made moot by the ability to add an RGB tint to creatures and placeables. They keep their same textures, but can be tinted to subtly (or drastically) different shades. Along with the ability to resize creatures and placeables (which I have seen mentioned already), this would put considerable customization capabilities in the hands of those who have no talent for texture-editing or 3D-modeling.
A few other things I'd like to see -
- A small modification to the new module creation wizard. This would be to ask for a small description of the module that is being built. There are way to many modules that don't have one. Even if it just says what level character the module is for, it would be an improvement.
- A functional macros system. Now I am not asking for the type used by ms office that are written in a script language (an archaic version of vb the last time I looked). Rather an extension of keyboard macros that includes mouse actions. With the ability to have more than one macro and to be able to save and load them from disk.
- Some sort of search that could look in conversations etc. Also that could search for specific names/tags/resrefs etc.
- A system to accommodate plug-ins for the stuff on my wishlist that BD doesn't choose to implement... OK a bit cheeky this one but hey it is a wish-list after all.
TRThose would all be awesome, but this one especially would really throw open the doors for the community. I've seen it suggested that BD open up the source code, which I think would be cool, but seems very unlikely to me ... accommodating community-made plug-ins (and maybe even making a few plug-ins of their own) would be almost as good.
TR
That double clicking on something in an area would automatically bring up its properties window.
I don't believe it. One of my suggestions made it into this weeks patch. Now I'm not claiming it was because of my suggestion, just that I'm gob-smacked that it happened.
TR