Scripts on SVN

eh. zarqon obviously wants me to do that. I'll go modify batfactors to make Candyblast work. I simply assumed that we shouldn't put hacks like that into the public mapfile.

There! batfactors has been improved! Candyblast now works.


Should I also comment out the chefstaves that are limited use in AoJ since that's the best way to make sure that WHAM doesn't use them? That's all I can do until zarqon makes it possible to ban specific chefstaff jiggling. OF coruse commenting them out will cause them to not exist at all in my local copy since the process of loading and then saving a map will remove all comments.
 
Last edited:
Bale said:
eh. zarqon obviously wants me to do that. I'll go modify batfactors to make Candyblast work. I simply assumed that we shouldn't put hacks like that into the public mapfile.

There! batfactors has been improved! Candyblast now works.


Should I also comment out the chefstaves that are limited use in AoJ since that's the best way to make sure that WHAM doesn't use them? That's all I can do until zarqon makes it possible to ban specific chefstaff jiggling.
Click to expand...

Don't be petty.

Philosophically I agree with zarqon but specifically he is incorrect; there are situations where it's not as simple as "sharing an optimization." Either way how about we discuss this like adults in lieu of defacing a data file to make a point.
 
roippi said:
Don't be petty. Either way how about we discuss this like adults in lieu of defacing a data file to make a point.
Click to expand...

You are correct, of course. Batfactors has been restored. It was meaningless anyway since zarqon just added some special handling for Candyblast. (I didn't read that thread until after reading this one, so it was a big shock to be me.)
 
roippi said:
there are situations where it's not as simple as "sharing an optimization."
Click to expand...

You're right, of course. But I don't believe those situations are relevant to data files, because data files only contain information, not logic. I would suggest that in the case where editing the data file both is and is not an optimization (due to differing perspectives), it's something that should be addressed in the parent script's handling of the information, not the information itself. Thus I feel pretty confident saying that it's beneficial to share any data file edit you find personally useful.

Take this Candyblast issue: BatBrain is concerned with correct information, and I believe people knew that and thus did not share their hack (which LIES!), on principle. People did, however, alter their personal copies to achieve correct function. BatBrain's inability to function correctly given correct information thus caused one of the situations you're talking about -- a conflict between correct information and correct function. The problem was with BatBrain's use of the information, however, and sharing the hack would have at least led to correct functionality for all users until the fix was implemented. I don't blame anyone for not submitting that hack -- as I said I believe it was withheld for very good reasons -- but in future I encourage everyone to view data files on the Map Manager as a sort of Wiki, where any one person's edit likely reflects the views of several and is thus helpful. In the event that it causes problems for others, they may feel free to edit the file as well, or report the problem so that the script author can account for multiple perspectives. These edits are not permanent.

Back on topic: How about a single SVN repository for all data files, which allows anonymous read/write access, containing a subproject for each data file? The Map Manager could then be reprogrammed to use that repository rather than its own data storage. All the benefits in one package?

ETA: @Bale: I missed whatever "defacing" you did to batfactors. That said, since I view it as a Wiki which people are likely to fix if it's harmfully wrong, I don't mind, either. It's constantly in flux as information is added, spaded, fixed, or refined; mostly by me but often by others (especially new skills). I should let you know, however, that instead of commenting the chefstaves out, you could have given them the "custom" keyword to remove them from consideration without actually removing them from the data file.
 
Last edited:
zarqon said:
Back on topic: How about a single SVN repository for all data files, which allows anonymous read/write access, containing a subproject for each data file?
Click to expand...

I'd really go with authorized r/w access if you're moving to SVN. By far the biggest hurdle for lay users is learning to use an SVN client, signing up for a sourceforge account is trivial.
 
The idea was to retain the web update interface yet gain SVN functionality. Is that possible with authorized access? i.e. could a PHP script be a user?
 
Ah, I see. That sounds pretty cool.

Answer: probably? I'm sure there's a precanned solution somewhere out there on the tubes. Any php thing capable of doing svn commit operations should be able to respond to auth challenges. (read access can/should be anonymous of course)
 
zarqon said:
Back on topic: How about a single SVN repository for all data files, which allows anonymous read/write access, containing a subproject for each data file? The Map Manager could then be reprogrammed to use that repository rather than its own data storage. All the benefits in one package?
Click to expand...

Nice. Worthwhile. I do prefer registred users though. Anything worth doing is worth putting one's easily registered and possibly disposable membership id on. Right? Maybe.


ETA: @Bale: I missed whatever "defacing" you did to batfactors.
Click to expand...

I just implemented the dried face hack for Candyblast to make it work for everyone. A helpful defacing. Because I'm not a jerk. Although maybe more of a "facing". :)
 
Last edited:
I agree with Bale. I oppose anonymous updates. If somebody can't be bothered to register, their updates are of no value, in my opinion.
 
I have a request for the first post in this thread: could you add a column that shows the date that a script was added to the svn? Would be nifty to be able to check that first post and see which scripts might be new since the last time someone checked the page.
 
Sorry, no. That's why I make a post in this thread every time I add something if it wasn't posted by someone else. If you read the thread, then you'll know which ones are new.

Anyway, the table is already cluttered enough. It is tough keeping the descriptions brief enough that they don't wrap onto a second line on my 1080p monitor. If I added another column I'd have to make them even briefer.
 
Finally got something into SVN.

ManagedStore
Code: 
svn checkout https://svn.code.sf.net/p/kolmafiascripts/shop/code/

CFStat
Code: 
svn checkout https://svn.code.sf.net/p/kolmafiascripts/cfstat/code/

CFStat fetches and caches price and sales volume from Coldfront.

ManageStore identifies items in your mall store that are unlikely to sell and autosells them or tries to sell them on kBay.

Sorry about the latter - it is certainly going to clutter the table if you use it verbatim.
 
Yours isn't the first description I've had to cut down.

No thread for either of those? Both added.
 
My suggesting anonymous access was simply so that the Map Manager could commit changes -- but if PHP can commit changes as an authenticated user, then it doesn't matter since the user experience would be exactly the same. To be clear, I'm suggesting we interpose the Map Manager as a middleman, so that anonymous users may still update data files via a web interface. Script authors (who are registered users) would also be able to add new data file subprojects to the repository, however Map Manager itself would not be able to create a new project if a map file were uploaded which does not already exist. Seems like an improvement on current functionality all the way around.
 
In the end, it's still anonymous updating, the difference being that we could distinguish anonymous updates from registered user updates.
 
It's still better than strictly anonymous updating, since php can do sanity checking in its middleman job. No drastic file size changes, only n commits/day per IP, IP logging, that sort of thing.

It all seems like a rather nontrivial amount of work; it would be much easier to just have the current map manager turn into a read-only frontend for svn. Shrug.
 
Well it would be nice if people can make edits without installing TortoiseSVN, so sure. Banzai for map manager.
 
Added SmartStasis to the list.

Also, combat scripts now have their own section. It seemed a good idea even though there are only three of them because it allowed me to clearly indicate their inter-reliance.
 
You must log in or register to reply here.
Back
Top