50 réponses à ce sujet

[DahliaLynn]

My thoughts exactly
I suppose the best thing I can do now is create a topic where people can list their requests for making the toolset's scripting tasks a bit more accessible to those who aren't familiar with scripting. Hopefully there will be a few scripting pro's willing to take this on as a team effort. 

Modifié par DahliaLynn, 18 novembre 2010 - 03:59 .

[Yara C.]

That is a good idea, Dahlia.
Furthermore, to be fair, both posts alluded to the aspect of a win-win situation. Why not a talent swap thread? And TimelordDC mentioned that the wiki needs cleaning up not only in the scripting area. That is true. We know where are still some documentation lacks in areas we are more familiar with. (I would be willing to contribute but someone else would have to clean up my English, LoL)

Modifié par Yara Cousland, 18 novembre 2010 - 11:01 .

[0x30A88]

I rather want the bugs fixed - many bugs there are - than making it easier. There are a lot of tutorials with copy-pasta scripts that helpted me in the beginning - and still do.



Bugs I want fixed is the level editor posting only works when Single Player is chosen (light probe problem), obsolete settings removed (many of them in creature editor) and allow us to change the loading background for only the module and not the game core.

[FollowTheGourd]

Gisle Aune wrote...
and allow us to change the loading background for only the module and not the game core.

That's technically already possible unless you're talking about something else - or have a specific issue in mind, since you put it in a list of bugs.

Modifié par FollowTheGourd, 19 novembre 2010 - 01:58 .

[ladydesire]

Gisle Aune wrote...

 obsolete settings removed (many of them in creature editor)

Most of the settings for creatures can be set either manually or by script; it all depends on what the module maker wants to do.

and allow us to change the loading background for only the module and not the game core.

Don't overwrite the existing core backgrounds; Awakening adds a new background that is separate from the ones in Origins, and it doesn't overwrite any in the process.

[0x30A88]

FollowTheGourd wrote...

Gisle Aune wrote...
and allow us to change the loading background for only the module and not the game core.

That's technically already possible unless you're talking about something else - or have a specific issue in mind, since you put it in a list of bugs.

You think of bacgrounds as in origins, by loading background, I mean what you see when the game is loading an area or something. The Carrion Birds have a custom one, but it overrides all mods' loading background, perhaps I should have called it loading screen background. What if another mod does the same, then it's ovveride war. Giving us a way to override it only for our module would be nice.

ladydesire wrote...
Most of the settings for creatures can be set either manually or by script; it all depends on what the module maker wants to do.

Like class, talents, spells, ... are just obsolete and serve no purpose, other than confusing new users. Removing them would be no hard task for Bioware. (put down that kitten, Gaider).

Modifié par Gisle Aune, 21 novembre 2010 - 01:14 .

[DahliaLynn]

I just want to remind you, (at least my original intent here) is not for Bioware to change or do anything to the current toolset, but rather for talented scripters out there to make the less obvious parts of the toolset more accessible to those who aren't familiar with scripting. For example, from the little knowledge I attained, you don't need to override anything when you manipulate the loadscreen.

At least I don't think so since in my own mod I was able to do this without touching anything in single player. (More so Sunjammer- a talented scripter did this for me so I would have never known)

Unfortunately many modders don't know that, because it is done by script commands, creating new ids, and (compiling?)a new GDA for this particular purpose. Even I am not sure exactly what it's about, but this is one example of what I'm trying to do here. Too many of us (I believe) have no idea what's going on there and what in fact is available to us, since the script part seems to scare off anyone who is more used to a graphic interface assisting us with what we want to accomplish.

Modifié par DahliaLynn, 21 novembre 2010 - 01:56 .

[ladydesire]

Gisle Aune wrote...

ladydesire wrote...
Most of the settings for creatures can be set either manually or by script; it all depends on what the module maker wants to do.

Like class, talents, spells, ... are just obsolete and serve no purpose, other than confusing new users. Removing them would be no hard task for Bioware. (put down that kitten, Gaider).

Those very ones are some of the ones that can be done either way; in fact, that's how the character generation system knows what class, etc. your new character is to begin with.

[FollowTheGourd]

Gisle Aune wrote...

FollowTheGourd wrote...

Gisle Aune wrote...
and allow us to change the loading background for only the module and not the game core.

That's technically already possible unless you're talking about something else - or have a specific issue in mind, since you put it in a list of bugs.

You think of bacgrounds as in origins, by loading background, I mean what you see when the game is loading an area or something. The Carrion Birds have a custom one, but it overrides all mods' loading background, perhaps I should have called it loading screen background. What if another mod does the same, then it's ovveride war. Giving us a way to override it only for our module would be nice.

Nope, I was thinking of the same thing you were, and it only has to be the case if you want your custom loading screen to appear before your module actually loads, and you put atl_load_town_dxt5_00.dds (or the "subtextures" the atlas comprises) or load_town.gfx in the core directory instead of the module directory. If it's in the module directory instead, you should only get the default loading screen when you first resume or start a new game after having just relaunched the game. One unavoidable side effect is that until you relaunch the game or until a new module finishes loading, you'll have the previous module's loading screen because its resources are still loaded.

Maybe it's possible to get around that in some crazy way like abusing tooltips to store state between the load screen and main menu or something (partially, cmd line -autologin=uid would probably mess that up). But yeah, that one case requires a compromise, but I don't see it getting changed on BioWare's side for the case when your module hasn't finished loading yet.

In the end, it's probably easier to not worry too much about it if you can provide an easy way for a user to remove it without breaking the rest of your mod. Maybe just give them a file to toss in the override, even though they might not want to do more than click on a dazip file.

I don't think a module is really "available" until around the time you see the "story so far" text, so one possibility was to alter the UI to crossfade in another custom loading screen at that time... another compromise, but maybe good enough if there's generally enough time to display it. The loading screen UI modification would then have to go in core, but it wouldn't load a non-default loading screen if it didn't need to.

Modifié par FollowTheGourd, 21 novembre 2010 - 02:54 .

[DarthParametric]

Sounds to me DahliaLynn like you are dumping everything you aren't familiar with under the banner "scripting", when likely at least some portion has nothing to do with scripting whatsoever. You mentioned GDAs, for example. They have nothing to do with scripting. They are just spreadsheets - modified Excel files essentially.

[DahliaLynn]

You're right. All I know is that there was a need for a command to be placed in a script in order to bring up a custom load screen text to appear when my module is called. For this I created a new GDA when inserting a new string id, attached to GUI defined text for the loadscreen. As you can see, it's obvious I have little idea of what is going on here, which is the point.
There are advanced modders out there who still baffled by the way the toolset works. How long would you say it takes to learn the Toolset's inner structure? Not to mention learn how to program? It's commands?
What followthegourd mentioned was what I meant. As in "Kismet"
To prevent any further foolishness on my part, I'll refrain from making anymore outlandish requests. It seems like the modding oldtimers have little understanding of what people who have never modded before feel like when confronted with this thing.

Edit: if this tool was meant for professional developers only then I'll just say thanks and do my best to try what I can, hopefully without giving up. 

Modifié par DahliaLynn, 21 novembre 2010 - 03:18 .

[AmstradHero]

DahliaLynn: I wouldn't feel too overwhelmed by the toolset. At least not to the point where you feel you should consider your posts "foolishness". I program for a living, yet there are some parts of the toolset I haven't explored yet that require some scripting.  Custom origins, classes, abilities, custom loading screens, text screens, credits, etc, etc... there are tons of things I simply haven't focussed on.

Most of my time has been spent:
a) Writing dialogue
Creating areas
c) Plot creation using plots/flag/minor scripting
d) Dialogue animation
e) Area editing (sound, ambient creatures, etc)

I've implemented a custom map, but that's about as far as my customisation has gone. I've played with the cutscene editor, but I don't have your skills with it.  I can script, but I haven't explored the intricacies of encounter design within DAO. I haven't dealt with customising creatures and their abilities. I want custom load screens and load text, but I haven't worked/found out how to implement them yet.

The wiki could do with an overhaul and the addition of a heck of a lot of content that modders now know how to do that wasn't known before.  How many of the things that have been listed as things we know how to do are missing from the wiki? I'm going to guess quite a lot.

Going it alone using the DAO toolset to create a fully fledged adventure is a huge task. Nay, a massive task. We have to rely on the knowledge and efforts of others to give us pointers on how to achieve the things we can't/haven't explored on our own, or otherwise work together in order to create such mods. If you want to go it alone, you can expect to have to put in months and months of work to create a complete adventure. That's the hard truth, unfortunately.

Don't feel disillusioned, just be aware that everyone struggles in different areas of modding.

[DarthParametric]

The difference between Kismet and what you are asking for is that Kismet isn't a tacked on community-made tool. In other words, you're never going to get something like Kismet in DA's toolset, and certainly not something as fundamentally incorporated into the workflow.



Yes, the toolset made for professional developers - it was made by Bioware for Bioware devs to make DA. It was never designed with mod makers in mind, they just decided to let us have a copy. We are lucky we got as much as we did in terms of the original skeleton of the wiki and some initial dev feedback/help before they dropped it and walked away.



Bottom line: the toolset is hard to use and that's unlikely to change. That doesn't mean you should give up, it just means you need to be realistic about what it is you can achieve on your own. No one person can do everything as well as a team of people with specialist skills in different areas (except in the case of some sort of freaky toolset savant). If you really have a project you want to get off the ground then put the word out and try and recruit some people to help. If you absolutely want to go it alone then you need to just bite the bullet and dive in and learn by doing.

[-Semper-]

DahliaLynn wrote...

What followthegourd mentioned was what I meant. As in "Kismet"

kismet is the same like scripting manually, it only takes away learning the commands and the structure. these are minor parts in programming - without the knowledge of the mathematical logic behind the scenes (which absolutely no plugin can provide) you are still not able to develope advanced scripts. there is no way around learning this stuff if you want to "master" it by yourself.

as i've never worked with lilac soul's my understanding of it is that this plugin provides only basic scripts and nothing special.

[0x30A88]

The toolset is hard to use, true, but once you master it, it's hella rewarding. Level design is the hardest parts considering the foul selection system and grouping system (groups pastes in each other...). But once one learns to work around it, you will notice that your level-design skills are improving. Patience is the key to success when it comes to developer tools.

The same goes with everything else.

What, however, makes the toolset easier is that you have this wonderful community that can help you with anything they find possible. Wiki tutorials are also a nice way. copypasta scripts also makes things easy.

Modifié par Gisle Aune, 21 novembre 2010 - 02:26 .

[Sunjammer]

If possible I would like to try to drag the conversation back to finding practical solutions for this issue rather than trying to reassure/convince non-scripters that scripting isn't difficult. Ultimately I don't think the difficulty, or lack there of, is the real problem: as I said previously some modders have no desire and/or aptitude for things like scripting.

So what practical steps can we take?

I think the first thing that needs to be done is to identify the common issues. For that we need DahliaLynn and her peers to tell us what they can't do or at least can't do easily. Capturing this information probably needs to be fairly high-profile and cross-site since most modders hang out on DA Nexus rather than here. So possibly using the wiki rather than the forums?

You guys probably have better ideas (if so please post them) but to get the ball rolling my suggestion would be for non-scripters to put together a list of specific "How do I ... ?" style questions which involve scripting or scripting-like tasks (i.e. 2da, local variables, etc). Essentially a non-scirpters scripting FAQ:

• How do I create a custom load hint and make them appear?
• How do I make a cutscene run when the Player enters a new area?
• etc.

Once we have a list then we can set about dividing them up between the more technically minded who will either locate, updated and link existing articles on the wiki or write new articles for the wiki. They would also look at providing script templates, demo mods, copy-and-paste snippets, etc. If needs be the programmers among us can also look at providing handy little utilities like DAToolbox or the Cutscene Companion.

Final thought do we want to set up a group? The Dragon Age Friendly Toolset Initiative might be an appropriate name.

Modifié par Sunjammer, 21 novembre 2010 - 02:59 .

[DahliaLynn]

@Darth: I know GDA's aren't about scripting. But in order to use loadhints I needed script assistance for integration in the long run.
"the toolset is hard to use and that's unlikely to change" I honestly don't believe that should have to be the case.

@Amstradhero:

I understand that the task of making an all out adventure campaign alone wouldn't be realistic and makes perfect sense.

The issue I was attempting to stress was the fact that I had needed to perform what seemed to be the simple task of attaching a cutscene to single player provided certain requirements be met. There was no way I could do this without having to learn the details of every other related aspect.I would have hoped to have an easier method to integrate the scene into the game, but instead found out that I had to learn the ins and outs of plots, conversations, spreadsheets, conventions, 2das, and scripting them into place.

My modular focus was the cutscene editor. To actually implement it I needed to learn everything else. My qualm is that if I choose to focus on cutscenes, do I need a team to make it work? Perhaps I do, but does this have to be the case? It seems that a few helper programs manipulating plots loadhints and the like can definitely ease the pain at least with regards to my own focus.

I agree with you on the Wiki, and simply hoped to make the learning curve a bit more bearable. I write this from the perspective of one who has a high technical aptitude for learning new interfaces, as well as scripting potential, but prefer to avoid it if possible.
Thanks for your added insight.

Gisle Aune : I agree, rewarding is an understatement, hence my passion to make the other areas of the toolset, a bit more accesible to people who have chosen to concentrate their efforts in one particular "module" of the Toolset.

@-semper-
"as i've never worked with lilac soul's my understanding of it is that this plugin provides only basic scripts and nothing special."
That would be helpful as well. Anyone that would want to dive further than basic script commands can do more research. But such a plugin would provide a more user friendly introduction to the algorithmic structures of the toolset and its mechanics to the newcomer.

@Sunjammer: Excellent post. I have had experience with modders who have already released quality mods who still have little clue as to whats going on, not to mention the constant anger and common misconceptions associated with the toolset in general. It doesn't have to be that way.

I believe Mikemike37's efforts in the community contest trying to expand the toolset using population is wonderful. But even so, it still remains an enviroment of rummaging through a deserted wiki to find the relative raw info, possibly causing a turn off at some point. Creating such a group would definitely benefit the Toolset using community a great deal for now and the future.

Modifié par DahliaLynn, 22 novembre 2010 - 03:21 .

[alschemid]

Not only the how do I do, which would be really really great, but some examples of how a function is used, which include files should I use with it. Because this is scary:

Returns the party list for the creature
[[object[]]] GetPartyList( object oCreature = -1);
Parameters: oCreature
Returns:
Source:

Modifié par alschemid, 24 novembre 2010 - 11:01 .

[DahliaLynn]

Dragon Age Friendly Toolset Initiative

A big step in the right direction.

Thank you. 

Modifié par DahliaLynn, 24 novembre 2010 - 01:47 .

[Proleric]

I think it fair to ask why the future of the wiki is being discussed in a group under Sunjammer's control, rather than in this public forum. IMO the wiki belongs to everyone.

[ladydesire]

Because you can't really discuss making the toolset more user-friendly without discussing how to make the wiki more useful; the two go hand in hand, since the wiki is the instruction manual/help file for the toolset. The group has open membership, so anyone truly interested in helping with the initative can join and contribute to it.

[Proleric]

That doesn't really answer the question.

I'm all for an open public discussion on how to improve the wiki. You know you can rely on me to do a fair share of the work, too. What I don't understand is why we can't have that discussion right here, in this forum, where no one is excluded.

[DahliaLynn]

I would think a social group devoted to the initiative would provide a more organized platform for singling out, categorizing, and implementing all the aspects related to the Wiki as well as anything else that contributes to the Toolset's friendliness.

Writing in an endless thread in a disorganized fashion seems to be a more than messy approach and will most likely lead nowhere. What's wrong with joining such a group? Anyone who is truly interested in an effort such as this will find this group the perfect place to shoot ideas and eventually have the best most practical ones implemented.

Modifié par DahliaLynn, 26 novembre 2010 - 05:03 .

[FollowTheGourd]

Both sides have a point, I think. The group is open, but people might not even know that the future of the wiki is being discussed there. It might help to announce it as a separate thread in this forum and link back to the group? Maybe that announcement thread will get hijacked into a discussion one, but what can you do - just say you'll only discuss it in the group maybe and leave it as that.

Modifié par FollowTheGourd, 27 novembre 2010 - 12:10 .

[ChewyGumball]

The whole point of the group system is to divert discussion from the main forums to a place where it can be more focused. Anyone is free to join and discuss but if you have negative feelings towards Sunjammer or anyone else participating in the discussion please do not let them colour your view of their points or derail the discussion at hand.