I don't have C: involved in my compilation process either.
You have installed Python and SCons, right?
0.73b: Yup, more Weapons Stuff
Moderator: Moderators
Yeah, and when I type "python" into the command-prompt, it replies:
I edited the scons.bat file, giving it an explicit path, and now it works, kind've. Now I get a different error:
After doing some reading... it appears that the problem is with PATH variables not being properly assigned in Windows. CMD.EXE just doesn't "know" that Python exists, and can't pass commands to it... and since this whole mess is using a BAT file that's supposed to find it... sigh.'python' is not recognized as an internal or external command,
operable program or batch file.
I edited the scons.bat file, giving it an explicit path, and now it works, kind've. Now I get a different error:
There's gotta be a way to fix this stupid thing. I have a feeling that if Python was working all right, I'd be done in minutes...scons: *** No SConstruct file found.
File "C:\Python24\scons\SCons\Script\__init__.py", line 870, in _main
Look... I've never even gotten scons to work, period. If I use a command-line argument to tell python to run one of the .py files, it invariably fails with a cryptic error message.
When I use the BAT in trunk, it crapped out until I told it explictly where Python was, and then it told me that Scons wasn't configured properly. Which I can't do, since I can't run it in the first place. This is driving me insane- first figuring out how to do it with Express Edition only to realise I'm building garbage, and now this
When I use the BAT in trunk, it crapped out until I told it explictly where Python was, and then it told me that Scons wasn't configured properly. Which I can't do, since I can't run it in the first place. This is driving me insane- first figuring out how to do it with Express Edition only to realise I'm building garbage, and now this
Well, this suggests you got it working properly but ran it from the wrong directory.Argh wrote:I edited the scons.bat file, giving it an explicit path, and now it works, kind've. Now I get a different error:
scons: *** No SConstruct file found.
File "C:\Python24\scons\SCons\Script\__init__.py", line 870, in _main
You're using a dosbox to run it right?
Code: Select all
cd \path\to\my\checkout
scons configure
scons
About the VC try, you got an exe right? That it's 1M smaller then the distributed one doesn't mean a thing - the distributed one may have been built using another compiler, another version of VC, or with slightly different settings. In general, executable size is X smaller does not mean there's less functionality in it. Are you sure you used right datafiles etc. for it?
Yes. Doesn't work. Tells me that it doesn't recognize Python, no matter what I do to itdid you add the python install path to your PATH environment variable?
Instead, I always get:
'python' is not recognized as an internal or external command,
operable program or batch file.
Yes. Maybe it's just really unstable right now- the number of warnings I got were well over 500! So far as I know, I'm using the right datafiles... otherwise, I wouldn't expect it to compile at all.About the VC try, you got an exe right?
The warnings in VC Express are common. If you got so far that you actually got an executable in trunk/game, then it's very likely a working one. You can best test it in your regular spring directory, so it doesn't have any missing files such as tacontent.sdz/springcontent.sdz.
If you want to test it from VC, be sure to set the "working directory" in project properties/debugging
If you want to test it from VC, be sure to set the "working directory" in project properties/debugging
Click "my computer" with second mouse button and go to system properties-advanced-path and add the paths there. Now all the executable in those locations you added should work when called from command prompt (or in a bat file).
At least in windows 2000, might be different in XP.
...that is, if you didn't already do this, I'm ignorant and just trying to help.
At least in windows 2000, might be different in XP.
...that is, if you didn't already do this, I'm ignorant and just trying to help.
Ok, so you're basically saying, JC, that it's fine? The version I compiled must just be very unstable, then- the client runs just fine until I try to start the game (i.e., placing game objects on the map). Up until that point, it's working just fine. So maybe I'll have better luck with the bugfixes that have been just merged (I just saw that on SVN).
And Bamb... yeah, I tried all that. Doesn't work. And the explanations of why it doesn't work just confuse me even more. I'll try again with VC++ EE and see if I can't at least test my code
And Bamb... yeah, I tried all that. Doesn't work. And the explanations of why it doesn't work just confuse me even more. I'll try again with VC++ EE and see if I can't at least test my code
IT WORKS!!!!
Repeated testing has shown, completely convincingly, that this works perfectly. Raise the size variable to raise hit-detection for faster projectiles... pure and simple! And it really doesn't cause a lot've visual discontinuity!
To give you a better idea... if you raise the Size value on a BeamWeapon to 16... I got consistant hit results, on BRAWLERS, with a souped-up LLT firing a shot travelling 2500!
And, um, if you make the explosions instant, it makes a gigantic difference in damage delivered. Gonna be interesting to watch everybody have to re-balance their mods again, with these two toys to play with!
So, er... can y'all please replace those files with the ones I made available? 'Tis a simple change- I didn't get around to making the color of the FlameThrower modder controllable... yet.
Now, if only it wasn't crashing with NanoBlobs
Repeated testing has shown, completely convincingly, that this works perfectly. Raise the size variable to raise hit-detection for faster projectiles... pure and simple! And it really doesn't cause a lot've visual discontinuity!
To give you a better idea... if you raise the Size value on a BeamWeapon to 16... I got consistant hit results, on BRAWLERS, with a souped-up LLT firing a shot travelling 2500!
And, um, if you make the explosions instant, it makes a gigantic difference in damage delivered. Gonna be interesting to watch everybody have to re-balance their mods again, with these two toys to play with!
So, er... can y'all please replace those files with the ones I made available? 'Tis a simple change- I didn't get around to making the color of the FlameThrower modder controllable... yet.
Now, if only it wasn't crashing with NanoBlobs
Lol, and here I thought I was done with mental challenges for the day 
Can I get you to compile it one more time, on the off chance that maybe I did something wrong, or that maybe your compile won't cause NanoBlobs to crash Spring on start? Pretty please?
Ok... I built the patch. Do I just post it on the ML? I can't commit anything, as I'm not a developer.
Here's a download link to this patch file. I put up the raw files earlier- this is the same thing, just in patch format.
Can I get you to compile it one more time, on the off chance that maybe I did something wrong, or that maybe your compile won't cause NanoBlobs to crash Spring on start? Pretty please?Ok... I built the patch. Do I just post it on the ML? I can't commit anything, as I'm not a developer.
Here's a download link to this patch file. I put up the raw files earlier- this is the same thing, just in patch format.
I'm not sure if the beam laser changes are correct though, initially they depended on the length of the beam, but now you set them to a constant TDF defined value. But then again I can't even seem to find where beam lasers line<->sphere collisions are done...
OT, I found that putting "largeBeamLaser=1" in the weapon TDF will enable it... (IIRC people wondered how it was enabled)
E: Most of the time pos.distance(endPos) is a lot bigger than what you set it to to in the weaponDef, so I'm really clueless why changing that would actually improve anything
OT, I found that putting "largeBeamLaser=1" in the weapon TDF will enable it... (IIRC people wondered how it was enabled)
E: Most of the time pos.distance(endPos) is a lot bigger than what you set it to to in the weaponDef, so I'm really clueless why changing that would actually improve anything
With Beamlasers, I tested it, and it definately works better than the previous code. I think you're assuming that pos.distance(endPos) is a large number because it sounds like it's getting a hitsphere from the current position to the end position, then using it as the radius.
There are two big problems with this assumption:
1. We don't want the size of the hitsphere to be changing dynamically, except for things like the flamethrower. It should be a constant.
2. When the beam is near the end of its path, is when it actually matters most that it is of a proper size to detect hits. Most mods using these weapons are assuming that a BeamLaser is inflicting damage over time- what has been affectively happening is that they don't really do so, with fast-moving small targets- they're simply getting missed entirely. A BeamLaser with a weaponvelocity of 1500 in Spring right now is nearly useless against fast-moving small targets- if you give it a fairly high tolerance and make the turrets speed up, you can watch it passing the beams through things like a searchlight.
Mainly though, this affects EMG, BeamWeapons, and the others, which all had fixed values before. All of them can now be adjusted to deliver accurate hitsphere behaviors at almost any practical speed.
If you just want me to put up the binary and a few changed files from XTA, so that you can see that this produces a verifiable and dramatic improvement in gameplay... lemme know. It's really obvious though that this is working right, and that it does what is necessary. And it's not like it's a lot've code, or wasteful, or involves any big computational steps- it just grabs a value that has a default anyway, so it's even backwards-compatible with old mods.
There are two big problems with this assumption:
1. We don't want the size of the hitsphere to be changing dynamically, except for things like the flamethrower. It should be a constant.
2. When the beam is near the end of its path, is when it actually matters most that it is of a proper size to detect hits. Most mods using these weapons are assuming that a BeamLaser is inflicting damage over time- what has been affectively happening is that they don't really do so, with fast-moving small targets- they're simply getting missed entirely. A BeamLaser with a weaponvelocity of 1500 in Spring right now is nearly useless against fast-moving small targets- if you give it a fairly high tolerance and make the turrets speed up, you can watch it passing the beams through things like a searchlight.
Mainly though, this affects EMG, BeamWeapons, and the others, which all had fixed values before. All of them can now be adjusted to deliver accurate hitsphere behaviors at almost any practical speed.
If you just want me to put up the binary and a few changed files from XTA, so that you can see that this produces a verifiable and dramatic improvement in gameplay... lemme know. It's really obvious though that this is working right, and that it does what is necessary. And it's not like it's a lot've code, or wasteful, or involves any big computational steps- it just grabs a value that has a default anyway, so it's even backwards-compatible with old mods.
Even though it might fix it, we do have to understand why it fixes anything..
The code for the other projectiles is ok though, but the beamweapon should not be fixed with this. If it is, it probably means your fixing a bug with another bug
I also wonder how weaponvelocity should influence the beamlaser. Beamlasers are instant, so they don't travel and don't have a velocity....
The code for the other projectiles is ok though, but the beamweapon should not be fixed with this. If it is, it probably means your fixing a bug with another bug
I also wonder how weaponvelocity should influence the beamlaser. Beamlasers are instant, so they don't travel and don't have a velocity....
I didn't have any trouble with beamlasers and small, fast units in CvC. What you have to keep in mind is that once the beam laser is fired the beam's orientation is fixed, no matter what the units or pieces do. A fast unit will move out of the beam very quickly and only take damage for a few frames.
<shrugs> maybe it's just that my beamweapon tests have also included the instant-explode code, so that the time-delay is no longer fuzzing things up. I dunno.
I'll have to do another proof, I guess, with the older version, and see if I can catch it not working and screenshot it, and make a test-piece with XTA, since this compile doesn't get along with NanoBlobs and I haven't figured out why yet
I'll have to do another proof, I guess, with the older version, and see if I can catch it not working and screenshot it, and make a test-piece with XTA, since this compile doesn't get along with NanoBlobs and I haven't figured out why yet