Sigh... who put rapid in a subfolder?

[smoth]

the problem is that the devs have not been around that long. Some have only bee around 2-3 years forb. They may have never chatted with you. Even still, not nearly as much as I have.

[AF]

Things like rapid being moved to a sub folder should have been tested and verified as working, as well as a lot of other things.

I know that a lot of things ARE tested, and some developers are very vocal about testing their own code ( e.g. JK in the development meetings ), but in this case this wasn't done.

The best thing to do would be to post in this thread and apologise, and promise to avoid it in future but say you cant make any promises. What's likely to happen is someone getting curious and looking up who actually changed it, and the person in question getting a major reputation hit.

Eitherway situations like this shouldnt happen to begin with, and we could save ourselves much time and effort.

ps: lmao at knorkes post
ps: I agree my post holds little value to peet and probably never will. His loop is more like this:

Code: Select all

while(problem_exists){
    counter++;
    if(counter > 2){
        abandonIdea("oh well kthxbai");
        break;
    } else if( (counter == 1) AND ( problemSeverity == lifeOrDeath) ){
        makePassingReference(problem);
    }
    if(fixed){
        doStuff();
        break;
    } else {
        sleep(6months);
    }
}

[smoth]

code explanations of personal logic were only funny when I was a sophomore in college.

[AF]

The idea is coders are more likely to read code than a large hunk of prose

[Forboding Angel]

Call me sad but I still find them amusing.

Tobi made rapid for linux. I then proceeded to compile it for winbloze and failed repeatedly. Eventually others succeeded where I originally failed (apparently I suck at using py2exe) and with some insistence on my behalf it was included with the engine to be recompiled at times by koshi and maintained by tobi.

This is perfect for anything on rapid because then the author to make an "Install" only has to serve up a zip file with a one line batch file in it, e.g.:

rapid pin tail:donkey

and viola, installs and updates.

Putting rapid in a subfolder breaks these batch files because well.... rapid.exe doesn't exist where the command line expects it. Easy fix by using rapid/rapid.exe pin tail:donkey, but if the location changes and you don't know it, you spend several days trying to diagnose what is essentially a "file not found" issue. Not to mention the havok it creates with your existing userbase, so my solution is to package the needed bat files and the entirety of rapid into the zip file, and instruct the user to unzip it all to their spring folder. Problem solved.

Oi, what a mess such a simple little mis-communication makes.

[knorke]

package the needed bat files and the entirety of rapid into the zip file, and instruct the user to unzip it all to their spring folder.

somehow this does not seem perfect. I'd be quite happy to see rapid.exe, tasclient.exe, springlobby.exe, zerok.exe and their files to disappear into their own subfolders instead of polluting the spring folder.

[Forboding Angel]

package the needed bat files and the entirety of rapid into the zip file, and instruct the user to unzip it all to their spring folder.

somehow this does not seem perfect. I'd be quite happy to see rapid.exe, tasclient.exe, springlobby.exe, zerok.exe and their files to disappear into their own subfolders instead of polluting the spring folder.

And what happens when they move the rapid files again to a different folder and fuck it all up again?

Likely? Probably not, but this way I don't need to find out.

[abma]

it wasn't moved: https://github.com/spring/spring/commit ... 5b0202af1c

initial commit installed it into rapid subfolder and this was done with a rapid.exe that supports unitsync.dll to be in parent folder. so... who to blame now?

[klapmongool]

Also, gui has to load unitsync which can take a reeeeeaaaaaaaallly long time. It will work fine if you copy everything in the rapid folder to the main spring folder and then run rapid gui.

initial commit installed it into rapid subfolder and this was done with a rapid.exe that supports unitsync.dll to be in parent folder. so... who to blame now?

Hmm.... How long does it actually take? Cos I have waited before, running rapid gui from the subfolder... And now i moved everything to the main folder... waiting waiting waiting.

[zwzsg]

so... who to blame now?

Forb for not updating his batches!

I haven't checked what I'm saying, I just want to play the blame game.

[Forboding Angel]

it wasn't moved: https://github.com/spring/spring/commit ... 5b0202af1c

initial commit installed it into rapid subfolder and this was done with a rapid.exe that supports unitsync.dll to be in parent folder. so... who to blame now?

But it doesn't support being in a parent folder... I already explained this to hoijui in the other thread.

[abma]

hm, this is why i think, bug reports are better than endless discussions :-/

i'll have a look at it, thanks for beeing the more specific, what's the problem.

see http://springrts.com/mantis/view.php?id=2343 for future reference.

howto report bugs: http://springrts.com/wiki/Bugs (i will use this link more often from now on...)

[Forboding Angel]

Well specifically, if rapid.exe or rapid-gui are run inside the rapid folder, it will not work at all.

The easy workaround is if it's called, e.g. rapid/rapid.exe pin yo:momma

My point is tho that we have to be made aware of that fact. I know that ct uses (or at least used at some point) a system similar to what I use (batch files). The issue at stake is trust. Look, if we just start distributing batch files (which is what I did), we have to know that it's going to work. Now, by all rights, I'm the asshole that didn't understand that rapid was always in a subfolder, but that wasn't how it was originally explained to me and using the installer didn't exactly prompt me to look. So in part, sort of my fault as well, but on the other hand, all this was done under the radar so to speak, so us lowly content people didn't know horsecrap from peanut butter, and that's the big issue here.

I don't care so much about rapid's location. I don't really give a rat's ass. What I do care about is the fact that no one said diddly squat to any of us that actually use the tool, and in my cause caused some serious (and rather embarrassing) headaches.

[abma]

"before" it wasn't included in the installer, it was nowhere... it was installed by hand. It doesn't work, so it's a bug.

For the rest, read:

http://springrts.com/wiki/Bugs (this page maybe needs some improvements, too...)

[Forboding Angel]

You aren't understanding me. Meh nm, is ok.

[abma]

then please clarify what you want

[kremmy]

Forb? Do you realize that you linked a screenshot showing that it can't find MSVCR71.DLL as an example of it not supporting being run from a subdirectory? That's a *completely* separate issue and you should damn well know that.

Okay, so my question is, does rapid *actually* not support being run from a subdirectory, or is this whole thread a *Visual C++ runtime DLL not being put in the right place* issue?

[zwzsg]

then please clarify what you want

Forb distribute a .bat that only work when rapid is in the Spring folder. He would have liked to know that rapid would be put in subfolder so that he would have updated his .bat.

[abma]

http://springrts.com/phpbb/viewtopic.php?t=24970

[Forboding Angel]

then please clarify what you want

Forb distribute a .bat that only work when rapid is in the Spring folder. He would have liked to know that rapid would be put in subfolder so that he would have updated his .bat.

^^ This. I said the same thing like 3 times, but hopefully hearing it from z will get the point across.