37 réponses à ce sujet

[KenquinnTheInsaneOne]

Any persistant world builder knows that as your modules increase so does the build time. After you get to 60+ megs in size it can take almost an hour to build depending on your computer. Lucky for me I don't just have one 60+ meg modue, but three all with seperate content. I have been thinking of ways to reduce the build times. Other than putting  Creatures/Scripts/Items/Encounters/etc that you dont edit very often into a hak. Is there anything else you can do to cut down build times?

[Lightfoot8]

Best way to reduce the time. Dont do it. If the module prompts you to build the module Press the cancel button and go your merry way. The build does not do much more then cross checks for the report it gives after the build. If you are not interested in the report it gives dont do the Rebuild.



For manual builds with just the "compile scripts' checked. is the only usefull function I have found for the build options.

[TSMDude]

Editted for being an idiot, lol....must have failed my Reading DC Check again.....

Modifié par TSMDude, 31 octobre 2010 - 02:39 .

[KenquinnTheInsaneOne]

Lightfoot8 wrote...

Best way to reduce the time. Dont do it. If the module prompts you to build the module Press the cancel button and go your merry way. The build does not do much more then cross checks for the report it gives after the build. If you are not interested in the report it gives dont do the Rebuild.

For manual builds with just the "compile scripts' checked. is the only usefull function I have found for the build options.

I don't use the stock compiler to compile my scripts I use the PRC Command line compiler, but that is not part of my question. So the toolset calling the compile options compiling apart from the scripts option is a loard of farce? One reason I assume it was nessicary was party, because they are compile options which implies they are doing more than checking for issues. The other reason I made the assumption is, because when content was submited to me and I uploaded it ot the server it did not allways apply. I got the users to make sure to build the content on their end with only the compile optins on and that stopped the issue. Any idea what could of caused the changes not to of apply. It was solved by me making sure anything that was sent in got compiled on their end first. Could it of been them forgetting to save the module, before trying to send me the changes? Other than that I have no idea what could of cause that other than them not compiling it.

I tested it on my end and it works exaclty as you say. No need to compile the module to make changes take affect.

@TSMDude: Was not talking about tricks to make content faster, but thank you for the advice.

[kalbaern]

KenquinnTheInsaneOne wrote...

Lightfoot8 wrote...

Best way to reduce the time. Dont do it. If the module prompts you to build the module Press the cancel button and go your merry way. The build does not do much more then cross checks for the report it gives after the build. If you are not interested in the report it gives dont do the Rebuild.

For manual builds with just the "compile scripts' checked. is the only usefull function I have found for the build options.

I don't use the stock compiler to compile my scripts I use the PRC Command line compiler, but that is not part of my question. So the toolset calling the compile options compiling apart from the scripts option is a loard of farce? One reason I assume it was nessicary was party, because they are compile options which implies they are doing more than checking for issues. The other reason I made the assumption is, because when content was submited to me and I uploaded it ot the server it did not allways apply. I got the users to make sure to build the content on their end with only the compile optins on and that stopped the issue. Any idea what could of caused the changes not to of apply. It was solved by me making sure anything that was sent in got compiled on their end first. Could it of been them forgetting to save the module, before trying to send me the changes? Other than that I have no idea what could of cause that other than them not compiling it.

I tested it on my end and it works exaclty as you say. No need to compile the module to make changes take affect.

@TSMDude: Was not talking about tricks to make content faster, but thank you for the advice.

Only the when editting factions does a rebuild become neccessary and I've never been able to stop a full build in those cases. So making custom factions when you first start a new module is best as the rebuild is alot quicker. Better off making more than you'll end up using than constantly adding new ones too. But as Lightfoot said, just abort the builds when changing haks. You do have to abort fairly quick though too. Often waiting more than a minute will fail to let you abort the rebuild.

[KenquinnTheInsaneOne]

I never rebuild when adding haks. I am still unsure as to what the issue was with the updates that were being sent to me to upload. I am guessing that the person forgot the save it on their end, before exporting them and sending it to me.

[TSMDude]

DOH! You mean when you run the build? I have to agree with Lightfoot as the other parts have really never done anything for me either.



Just run the Scripts Compile and save a lot. Otherwise your just wasting your time.



And yes on factions. Another short cut on factions is to make a "empty world" of areas except one and then do the custom factions there with JUST creatures and one area. The full build takes like 5 minutes this way and then you just readd the creatures BACK to the orginal allowing them to overwrite and voila...



Easiest way i could find.

[DM Heatstroke]

TSMDude wrote...

And yes on factions. Another short cut on factions is to make a "empty world" of areas except one and then do the custom factions there with JUST creatures and one area. The full build takes like 5 minutes this way and then you just readd the creatures BACK to the orginal allowing them to overwrite and voila...

Easiest way i could find.

That is brilliant, thanks.

@Kenquinn - I don't rebuild my module either.  Very little need to.

[Grymlorde]

What about rebuilding the palette? I like to compile just the palette after I've deleted some things from the palette.



Also if I bulk copy from another module into the temp0 directory, I'll rebuild the palette at that time also.

[Invisig0th]

There are other situations where it is a very good idea to do a full compile, including troubleshooting for certain problems. So learning ways to make the compile process faster is still very useful, even if one chooses not to compile frequently.

[FunkySwerve]

The OP wasn't talking about a full compile of the mod's scripts, which is a good thing to do before you drop any update to a live server, but the build option built into the toolset, which is a waste of time. You don't even need to do. Even the palette can be managed with a right-click refresh, which takes a minute or two tops. Doing full mod builds, and worrying about how to speed them up, are both wastes of time in most cases. The only time our toolset ever goes idle for that long is when we add custom factions, which is a royal pain in the rear.

Funky

Modifié par FunkySwerve, 04 décembre 2010 - 06:37 .

[Invisig0th]

I understood the question, thanks very much. Apparently you did not quite understand my response.

I have personally been involved with troubleshooting several problems where a FULL BUILD OF THE ENTIRE MODULE was necessary to identify the problem. Yes, it is rare, but there are indeed situations where building the module is the *only* way to get to the bottom of a problem.  So anyone who says a FULL BUILD OF THE ENTIRE MODULE is absolutely never useful is misinformed.

Just to be clear, let me say it again -- this kind of scenario is uncommon. For everyday use, a full build is generally not necessary. But there are indeed certain situations where a full build is actually beneficial.

Modifié par Invisig0th, 04 décembre 2010 - 09:55 .

[FunkySwerve]

Can you give an example? I've never, in over 6 years of modding, encountered such a problem. By contrast, sometimes a full script build is useful for diagnostics (modders I help have often forgotten to compile something), which is why I assumed that was what you meant.

Thanks,
Funky

Modifié par FunkySwerve, 04 décembre 2010 - 10:20 .

[Invisig0th]

I can't actually locate the specific example I was thinking of at the moment, thanks to the shortcomings of the search engine on the old site. I also don't remember the symptom that first caused the poster to start a thread. However, IIRC after several days of unsuccessfully trying to find the cause of the problem, I finally suggested that he should just do a full build of the module. That caused the toolset to crash with an error, one which he had not seen before that. Based on that, I suggested that the underlying problem might actually be a corrupt installation of the toolset. After he reinstalled the toolset, he was once again able to run the toolset and rebuild his module without any problems.

I've seen a similar problem at least one other time.

Modifié par Invisig0th, 08 décembre 2010 - 05:24 .

[FunkySwerve]

I can see how that makes sense, at least anecdotally. Still, I've never had to resort to a full build to recommend that someone reinstall - odd exception errors and the like are a good indicator that there's a problem of that kind. Most of the corrupt installs I've seen have pretty obvious symptoms, like crashing out of certain areas - corrupted texture files are the variety I've seen the most, though, as you say, it's not a common problem (most means about a dozen, out of tens of thousands of players, and only handful of builders, mostly from troubleshoot work with HGLL, SIMTools, and letoscript). Further, a full mod build wouldn't necessarily turn up that sort of problem.



Anyway, given how uncommon a problem that is, I don't see how it makes finding faster build methods worthwhile. You'll wind up wasting more time on the fix than the problem.



Funky

[Invisig0th]

Once again, you misunderstood the post. In this specific case, the ONLY way to generate the actual error message was to do a FULL BUILD OF THE MODULE.  That error message led directly to the solution to the problem. Prior to that, neither Axe Murderer or myself was able to solve the problem. So this is one example of a specific situation where a full build of a module was very important.  Anyone who claims that a full build of the module is never useful is quite simply wrong. 

My post was intended to share this first-hand information with the OP -- information which you were apparently not aware of. And that's exactly what I've done.

Please feel free to continue to insist that this kind of thing never happens to anyone, based solely on the fact that you personally have not seen it happen. The people reading this thread will make up their own minds regarding how logical that particular line of reasoning is.

Modifié par Invisig0th, 09 décembre 2010 - 01:49 .

[FunkySwerve]

Invisig0th wrote...

Once again, you misunderstood the post. In this specific case, the ONLY way to generate the actual error message was to do a FULL BUILD OF THE MODULE. 

No, I'm quite clear on what you're saying. And naturally, the only way to get build errors to appear is to run a build. What I am telling you is something else entirely:

1) that you don't need to get those build errors to tell that a module or toolset is corrupt
2) a corrupted mod or toolset will not necessarily throw a build error, making this an uneven tool at best
3) that there are much quicker ways of determining that a module or toolset is corrupt
and lastly, that, even were 1) through 3) not the case, that:
4) justifying time spent on optimizing builds based on the notion that they can solve obscure and uncommon problems, is silly, because you'll likely spend more time optimizing than you save.

That error message led directly to the solution to the problem. Prior to that, neither Axe Murderer or myself was able to solve the problem. So this is one example of a specific situation where a full build of a module was very important.

That's all well and good - clearly, in that case, it helped you determine the nature of the problem. None of that, however, really refutes 1-4 above. Yes, it helped in that case, but that doesn't mean that there wasn't a faster way of figuring it out, or that it necessarily would've determined the problem. You can dig a hole with a spoon, but that doesn't mean you shouldn't grab a shovel.

  Anyone who claims that a full build of the module is never useful is quite simply wrong. 

I agree. Of course, that's not at all what I'm claiming. I'm claiming it's pretty much always a waste of time. That you could never possibly ever see ANY benefit from doing a mod build is a rediculously easy-to-disprove straw man, which your anecdote did quite handily. It misses the point.

My post was intended to share this first-hand information with the OP -- information which you were apparently not aware of. And that's exactly what I've done.

That may be, since you're right, I didn't know you could dectect a corrupt toolset in that fashion - it never occured to me to waste my time trying it. :happy: You are are also, however,  advocating for the usefulness of the toolset's build option, which, as I and the other posters have noted, is wrongheaded.

Please feel free to continue to insist that this kind of thing never happens to anyone, based solely on the fact that you personally have not seen it happen.

I didn't insist that. In fact, if you bother yourself to read my post, it's happened to me a good deal more than you (you claim one other instance besides the anecdote above, while I've dealt with a dozen or so players and a handful of devs - check back and see). And, as a matter of fact, speak of the devil and he shall appear. It happened to one of my devs today. In this case, it was the module that went corrupt, in a new and wonderous way I'd not seen before. It caused the items icon palette to list merchants instead of items, with no other effects (the merchants were also listed normally under the merchants icon:
Behold!

So, you may ask yourself, how did we set about diagnosing this bizarre, never-before-seen-by-us behavior? He tried loading another module. It displayed the icons normally. He loaded the old one, and they displayed incorrectly. Mystery solved. Time spent diagnosing? Under 5 minutes. He then loaded up a recent backup, replaced the script he'd been working on with a txt backup, and went on his merry way, but not before sending me a copy of the mod - I wanted to put your diagnostic method to the test.

A little over three hours later, I can now report to you, the mod turned up no build errors. In the interests of full disclosure, I DID turn off script compiling, because the feeble bioware compiler chokes on our code (too many declarations), but compiling the scripts using the prc compiler, an improved bioware compiler, yeilded no errors, unsurpisingly. So, there you have it. Time saved by NOT using the build module option to diagnose? Over three hours (it's a big mod, what can I say, only used to take 2 and a quarter, and that's with a fair chunk of resources deposited outside the mod, in resman).

I'd love to hear more details about what kind of corruption a build DOES turn up, and what kind of error it throws - you've been very vague.

Likewise, while you're sharing things I don't know, if you can come up with an example of corruption that takes less time to diagnose with the build module option than other options, by all means, I'd love to see it.  I can understand how it might seem like the way to go when you haven't seen many corrupt modules/toolsets/game installs, and are confused by what the mod/game/toolset is doing, but I  promise, it isn't.

The WORST case diagnostic scenario I can imagine would be doing a full reinstall to check, after having spent 10-15 minutes ruling out all other possibilities (hak order, corrupt mod, etc). I can well imagine a reinstall taking more time for some people than a mod build (not me, with a mod the size of HG), but it, unlike the mod build, is nearly certain to correct any corruption, and you're going to have to do it anyway if that is in fact the problem, so it's a flat-out winning proposition for dealing with corruption, as opposed to wasting a couple hours on a mod build. And, in most cases, you don't need to do the reinstall to figure it out anway.

In my case, I have yet to have to resort to reinstall to check for corruption, since, of the instances I've seen, simply swapping modules to check for a corrupt mod, and swapping the same mod with another builder to check for a corrupt toolset has worked (though 'swapping the same mod' is admittedly a more complex proposition for someone using different set of haks etc, and yes, I've done that too). I'll also admit I used to try leto scans first, since they're quite good at turning up corrupt gffs (and I still do for hunting corrupt bics, though I haven't had to do that for years now), but that is now more a confirming step than anything, if I even bother at all (they're somewhat time consuming, though not nearly so much as a build).

The people reading this thread will make up their own minds regarding how logical that particular line of reasoning is.

Oh, I'm certain they will.

Funky

Modifié par FunkySwerve, 09 décembre 2010 - 05:45 .

[Invisig0th]

The Bioware Aurora Toolset is the executable program we use to edit module files. I explained above that I've been involved in situations where the Bioware Aurora Toolset installation itself becomes corrupt, requiring a reinstallation of the toolset.

Module (.mod) files, on the other hand, are simply data files which we can edit using the toolset.  As it turns out, module files get corrupted rather frequently.

Having a corrupt toolset installation is a fundamentally different problem than having a corrupted module file -- for the same reason that getting an error on a web page does not mean you should reinstall your web browser.

So your anecdotal story of a corrupt module file (a data file) not only proves nothing at all, but it actually turns out to not even be relevant to this discussion. In fact, the only thing you have accomplished with your most recent post is to call into question how much you actually understand about this subject matter. Someone who was knowledgable about these things would certainly not talk about corrupt modules and a corrupt toolset installation as if they were equivalent.

The fact that you persist in claiming that you fully understand specific problems which you have zero actual  experience with (problems which you weren't even aware of prior to this discussion) is self-evidently foolish. I won't be wasting my discussing this with you further.

Modifié par Invisig0th, 12 décembre 2010 - 02:50 .

[ffbj]

I do a full build once and a while just to see if I've screwed anything up. Not to get into the specific questions of whether it is useful or not it has been for me.

You can reduce the size of your module by telling it not to copy scripts, or whatever that function selection is called in the toolset. This will reduce the size of your module quite a bit if you have not already selected it, and subsequently reduce build times.

[FunkySwerve]

Invisig0th wrote...

The Bioware Aurora Toolset is the executable program we use to edit module files. I explained above that I've been involved in situations where the Bioware Aurora Toolset installation itself becomes corrupt, requiring a reinstallation of the toolset.

Module (.mod) files, on the other hand, are simply data files which we can edit using the toolset.  As it turns out, module files get corrupted rather frequently.

Having a corrupt toolset installation is a fundamentally different problem than having a corrupted module file -- for the same reason that getting an error on a web page does not mean you should reinstall your web browser.

Fundamentally different in what relevant way? They both rely on files that can become corrupt, and it's difficult to tell which file without diagnostics of some kind. Yes, an executable is different from a data file, but that rather obvious fact doesn't render corruption of one magically irrelevant to corruption of the other. As I point out above, you can use one to diagnose the other, and figure out which has a file gone bad.

So your anecdotal story of a corrupt module file (a data file) not only proves nothing at all, but it actually turns out to not even be relevant to this discussion.

It proves exactly what I said it proved - that there are faster ways to diagnose corruption. When you get a problem of the kind I described in that anecdote, it can be with either the toolset or the module - there's no prima facie way to know in most cases (in all I've seen, in fact). This is, of course, why we diagnose things. Trying to pretend that, because the corruption happened to be in the module in this instance, that the anecdote has no bearing on diagnosing corruption, is transparently silly.

In fact, the only thing you have accomplished with your most recent post is to call into question how much you actually understand about this subject matter. Someone who was knowledgable about these things would certainly not talk about corrupt modules and a corrupt toolset installation as if they were equivalent.

I agree - no one knowledgeable would claim a corrupt module is 'equivalent' to a corrupt toolset. Of course, I didn't
talk about them as if they were equivalent, just related. They obviously aren't equivalant, for
the reasons you state. Again, you do an excellent job of smacking down something I didn't say. [smilie]../../../images/forum/emoticons/grin.png[/smilie] This leads me to wonder whether you simply aren't understanding the points I'm making, or you're setting up straw men in a attempt to win a losing argument. Likewise, calling my diagnostic chops into question when you've breathed barely a word about how you yourself diagnose corruption, is more than a little silly. All you've revealed of your own know-how is a rather spurious-sounding story about the toolset throwing some unspecified build error once, while I've actually talked about how I've solved these issues in the past, and offered up a concrete example from this very week. Who do you think you're kidding? [smilie]../../../images/forum/emoticons/tongue.png[/smilie]

The fact that you persist in claiming that you fully understand specific problems which you have zero actual  experience with (problems which you weren't even aware of prior to this discussion) is self-evidently foolish. I won't be wasting my discussing this with you further.

Where exactly did I claim to 'fully understand' anything? I've been asking you repeatedly to share what you know - hardly the mark of someone claiming to know it all. I've shared what I know, but you seem unable or unwilling to do likewise. And, if you've read my posts, you know that I have experience wtih the topic, toolset corruption (and the folly of spending time looking for ways to reduce mod build times on the off chance you might be daft enough to actually use the build option, the main topic of this thread, to diagnose said corruption), so I'm not sure where you're getting that notion, or the notion that I somehow wasn't aware of it before your post.

But, since you're claiming an understanding you say I lack, I'll ask again, please, enlighten we heathens. Give us an example of toolset corruption that a build is the fastest way to detect, or one in which you don't have to rule out the module as a possible source of corruption, rendering your remarks about them being unrelated something other than complete nonsense. Or explain why it is that it's worth trying to reduce module build times on the off chance you'll get a corrupted toolset and use a build to diagnose it. Heck, just tell us how you diagnose corruption, other than with a toolset build turning up a mystery error. I showed you mine, show me yours. Sharing knowledge is, after all, the purpose of these forums. No need for all the hostility, bluster, and obfuscation. Anyway, I , like you, am growing tired of this thread, and my point is made, so I won't reply either, unless you have something constructive to say.

Best,
Funky

Modifié par FunkySwerve, 12 décembre 2010 - 05:38 .

[Invisig0th]

Whatever. Welcome to the BLOCKED list.

Modifié par Invisig0th, 12 décembre 2010 - 10:41 .

[FunkySwerve]

You can reduce the size of your module by telling it not to copy scripts, or whatever that function selection is called in the toolset. This will reduce the size of your module quite a bit if you have not already selected it, and subsequently reduce build times.

Sorry, didn't notice this earlier. I think you're referring to turning off debug info, which is always a good idea, build times or no, since it increases the size of the module a fair bit, increasing upload and download times.

Funky

[Avonos the Rogue]

Invisig0th wrote...

Whatever. Welcome to the BLOCKED list.

Really?  I mean really?  C'mon now you can talk through this one, I'm sure of it.

[ffbj]

Yes the debug mode is what I meant. Just since no-one mentioned it before and module size effects load times.

[Lazarus Magni]

FunkySwerve wrote...

You can reduce the size of your module by telling it not to copy scripts, or whatever that function selection is called in the toolset. This will reduce the size of your module quite a bit if you have not already selected it, and subsequently reduce build times.

Sorry, didn't notice this earlier. I think you're referring to turning off debug info, which is always a good idea, build times or no, since it increases the size of the module a fair bit, increasing upload and download times.

Funky

To turn off debug mode in the toolset do you have to add a line:Debug Mode=0 to the nwntoolset.ini? Or to the nwnplayer.ini? Or how is this done?

Modifié par Lazarus Magni, 17 juin 2011 - 08:14 .