What about a selection when hosting a game to start MiniSpring.exe as engine instead of usual Spring.exe? Perhaps a checkbox next to the map selection dialog should be sufficient.
Games that are hosted with this option checked can only be joined by players who also have minispring on their system. Joining such a game would lead to MiniSpring.exe being launched as the client engine instead of Spring.exe.
Is that possible?
Sounds very easy to implement. Unfortunately I have no C++ knowledge.
Idea for MiniSpring and network play
Moderator: Moderators
Re: Idea for MiniSpring and network play
LOL!!!!!!!!!!!!!!!!HiEnergy wrote: Sounds very easy to implement. Unfortunately I have no C++ knowledge.
For the 19832987297628978308750872987953798347087th time, we need one scale to rule them all. We cannot have MiniSpring and normal Spring because it would make it impossible for mappers to properly make maps that suit two entirely different scales. There needs to be one standard, and only one, otherwise you're just going to further divide the community. And honestly, there is no real reason to keep normal spring: Buggi has the code done and ready. Minispring will allow smaller map filesizes for larger maps (in terms relative to the units), which will make it easier for everyone to create, upload, and download maps. Minispring lessens the obviousness of the low poly models and low resolution textures of TA. Minispring makes terrain deformation much more reasonable. There are no cons for going to minispring, and there are no pros for staying with normal Spring. But either way, we need one and only one scale.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Hmm... I'd like to be able to see my units; having the units so small makes it difficult to select the right unit out of a group...Gnome wrote:There are no cons for going to minispring, and there are no pros for staying with normal Spring.
Most importantly, all (okay, 95%) of maps out there are designed for (big)Spring, so globally converting to MiniSpring would entail a massive map redesign effort. Unless, of course, unit scale doesn't matter for maps... which kills your entire argument for one and only one community standard.
I don't see why allowing player choice is a bad thing, personally. Some of us will prefer standard Spring; some will prefer MiniSpring; some can go either way; some will go with whatever game is running. As long as both Spring and MiniSpring are bundled with the download, we don't divide the community. I'm sure that if MiniSpring is included with the Spring download, there will be plenty of people who make maps specifically for MiniSpring.
Zoom in. As a side effect, MiniSpring also makes it possible to get a larger view of the battlefield when zoomed out.Felix the Cat wrote:Hmm... I'd like to be able to see my units; having the units so small makes it difficult to select the right unit out of a group...Gnome wrote:There are no cons for going to minispring, and there are no pros for staying with normal Spring.
Easier for mapmakers to recompile 40 or so existing maps (which they'll probably have to entirely remake when the fabled new map format comes along anyway) than to make them try to design maps for two scales. Think about the apparant size of hills/mountains, rivers/lakes/oceans, etc in Spring vs their apparant size in minispring. They're totally different, and that is a HUGE gameplay element.Most importantly, all (okay, 95%) of maps out there are designed for (big)Spring, so globally converting to MiniSpring would entail a massive map redesign effort. Unless, of course, unit scale doesn't matter for maps... which kills your entire argument for one and only one community standard.
I hear complaints on IRC constantly that there are only 2-6 players in the spring battleroom at any given time; and of those players, they are usually idling or playing/wanting to play a different mod than you. By making minispring an option, you're only going to further divide the dismal player resources available. And the other thing about maps: It'd be a huge pain to find a great looking map for minispring which is totally unplayable in normal spring, simply because of the size and other gameplay elements of the map.I don't see why allowing player choice is a bad thing, personally. Some of us will prefer standard Spring; some will prefer MiniSpring; some can go either way; some will go with whatever game is running. As long as both Spring and MiniSpring are bundled with the download, we don't divide the community. I'm sure that if MiniSpring is included with the Spring download, there will be plenty of people who make maps specifically for MiniSpring.
I repeat again: there can only be one scale, period.
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
Yes, Felix, it has been already argued and proved in two seperate minispring threads that there cannot be an option with this. While Spring and TA are all about giving as many options to the players as possible, something like this is such a massive change that you just cannot have two versions floating around. As Gnome said, it would decimate the online community, as well as posing massive issues for the map making community.
There cannot be two sizes of Spring floating around. You can either have normal spring, or minispring.
Therefore, the decision comes down to "which is better, normal spring or MiniSpring?"
And as has already been argued, and already been voted for by the community, the answer is MiniSpring.
There cannot be two sizes of Spring floating around. You can either have normal spring, or minispring.
Therefore, the decision comes down to "which is better, normal spring or MiniSpring?"
And as has already been argued, and already been voted for by the community, the answer is MiniSpring.
Also I have played several LAN game's using mini-spring, and the maps where still balanced, just... bigger! Which I have been assured is the whole point. Also i have come across a crazy argument about "I don├óÔé¼Ôäót like huge maps!"
well, make SMALLER MAPS!!!
Also with mini-spring implemented you don├óÔé¼Ôäót have to worry as much with unit compatibility with maps. I think that the mini-spring idea should be less of a "TA" only thing and more of a standard unit scale. That would greatly help mod makers (like me!) to make tanks the right size for ALL maps, and make K-bots, infantry, titans, krogoths, airplanes etcetera.
So a mini-scale would be....
Infantry: .5
K-bot's: 1
Tanks: 2
Large Tanks: 2.5
air plane: 2
Large Airplane: 2.5
Titan(krogoth): 3
Huge Titan: 4
Massive Titan: 5
or something on that line. These would be guide line's and wont be set in stone , so that mod makers and map makers would have a handy reference to make big chock points, narrow valleys. So if they want mountain ranges that will dwarf massive titans, they would make a mountain roughly larger then a 5 sized unit (whatever that is).
well, make SMALLER MAPS!!!
Also with mini-spring implemented you don├óÔé¼Ôäót have to worry as much with unit compatibility with maps. I think that the mini-spring idea should be less of a "TA" only thing and more of a standard unit scale. That would greatly help mod makers (like me!) to make tanks the right size for ALL maps, and make K-bots, infantry, titans, krogoths, airplanes etcetera.
So a mini-scale would be....
Infantry: .5
K-bot's: 1
Tanks: 2
Large Tanks: 2.5
air plane: 2
Large Airplane: 2.5
Titan(krogoth): 3
Huge Titan: 4
Massive Titan: 5
or something on that line. These would be guide line's and wont be set in stone , so that mod makers and map makers would have a handy reference to make big chock points, narrow valleys. So if they want mountain ranges that will dwarf massive titans, they would make a mountain roughly larger then a 5 sized unit (whatever that is).
-
[K.B.] Napalm Cobra
- Posts: 1222
- Joined: 16 Aug 2004, 06:15
-
LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
correct me if I am wrong... but ok... you reduce the unit size and put the units on the same map and zoom in.... isnt this the same as making the map scaled bigger, with a bigger zoom factor? thus, only reducing the map quality for a bigger map/unit scale??
can't we just make a higher compression 60x60 map (looking like ass) on regular spring.. look just like a 12x12 on normal compression (ZOOMED WAY IN, again looking like ass) for mini-spring??
sounds redundant to me...
the only REAL differences between mini and normal, are:
a- LOS is huge....
b- Trees and stuff are bigger
c- Larger FOV from overview camera
d- units are very fast
e- map low detail and large scale vs. high detail and small scale
can't we just make a higher compression 60x60 map (looking like ass) on regular spring.. look just like a 12x12 on normal compression (ZOOMED WAY IN, again looking like ass) for mini-spring??
sounds redundant to me...
the only REAL differences between mini and normal, are:
a- LOS is huge....
b- Trees and stuff are bigger
c- Larger FOV from overview camera
d- units are very fast
e- map low detail and large scale vs. high detail and small scale
Actually my idea sprang from mini-spring and the intrinsic argument that is more about standardization then the two differing things. I mean the only realy choice is mini-spring (that├óÔé¼Ôäós pretty arrogant of me, but its true). Now see standardization seems to remove choice. But actually it ADD'S a multitude's of choice. Why do you think the money system works better then the barter system? Because with the standardization of money (kind of) a nation's trade increases cause its EASYER! Suddenly you don├óÔé¼Ôäót need to haggle that a goat is worth more then a cart lode of grain, because every one agreed by group concessions that a goat is 10 coins, and a cart of grain is 20 (that├óÔé¼Ôäós a little simplified, but that├óÔé¼Ôäós pretty much how it came about, plus the fact that the touchstone allowed gold├óÔé¼Ôäós value to be standardized and it kind of grew from there).
If we standardize scale in Spring, then map making is easier because you can instantly judge which scale of unit's will get through there, how many tanks someone will be able to realistically field ext. Mod makers also have a easer time of it, because they can say "If i want a small scout infantry to wriggle through as many smallish cracks in mountain├óÔé¼Ôäós as possible, and still make them a good enough size, i will make them so big, cause i├óÔé¼╦£m using the same scale system as the map maker's!". Scale is NOT a core engine issue. Its an agreement to how big a big unit is! If you want a Battletech mod then you will be able to make a bunch of large mechs. If your making WD then you will know how large an infantry unit should be, then build off that to make large infantry on the large end of the scale, and the small one's....small.
So standardization isn├óÔé¼Ôäót some oppressive device. In fact, historically, standardization of measurement, money, and a verity of other commonly use things has increased everything├óÔé¼Ôäós efficiency, ease of use, and general prosperity.
If we standardize scale in Spring, then map making is easier because you can instantly judge which scale of unit's will get through there, how many tanks someone will be able to realistically field ext. Mod makers also have a easer time of it, because they can say "If i want a small scout infantry to wriggle through as many smallish cracks in mountain├óÔé¼Ôäós as possible, and still make them a good enough size, i will make them so big, cause i├óÔé¼╦£m using the same scale system as the map maker's!". Scale is NOT a core engine issue. Its an agreement to how big a big unit is! If you want a Battletech mod then you will be able to make a bunch of large mechs. If your making WD then you will know how large an infantry unit should be, then build off that to make large infantry on the large end of the scale, and the small one's....small.
So standardization isn├óÔé¼Ôäót some oppressive device. In fact, historically, standardization of measurement, money, and a verity of other commonly use things has increased everything├óÔé¼Ôäós efficiency, ease of use, and general prosperity.
-
LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
-
smokingwreckage
- Posts: 327
- Joined: 09 Apr 2005, 11:40
There's two more footprint sizes needed: Infantry and sub-infantry (like zerglings for eg.)
LS: they're close, but minispring gives longer L-o-S, faster units, and smaller map sizes in terms of megabytes per map. All these are good things. L-o-S in original Spring looks very oddly truncated, the transition from TA engine did it no favours.
LS: they're close, but minispring gives longer L-o-S, faster units, and smaller map sizes in terms of megabytes per map. All these are good things. L-o-S in original Spring looks very oddly truncated, the transition from TA engine did it no favours.
thats a balancing issue that ahs prett muchy been encoutered already, one that I think buggi has grappled with and changed so that they work correctly to an extent. I shall have to read up on that, but if not implemented it would just mean changing the engien slightly so that all stats where reduced by a factor of 4 (stat = stat*0.25, it's that simple)the only REAL differences between mini and normal, are:
a- LOS is huge....
b- Trees and stuff are bigger
c- Larger FOV from overview camera
d- units are very fast
e- map low detail and large scale vs. high detail and small scale
You're wrong. The texture still looks fine even when zoomed in fully; there is nothing wrong with map quality in miniSpring compared to megaSpring.LathanStanley wrote:correct me if I am wrong... but ok... you reduce the unit size and put the units on the same map and zoom in.... isnt this the same as making the map scaled bigger, with a bigger zoom factor? thus, only reducing the map quality for a bigger map/unit scale??
can't we just make a higher compression 60x60 map (looking like ass) on regular spring.. look just like a 12x12 on normal compression (ZOOMED WAY IN, again looking like ass) for mini-spring??
AT. ALL.
Spring overlays a texture otnop fot he terrain texture to make ti appear more detailed. Otherwise the texture would look stretched and wierd at ordinary zoom in normal spring. You can see this texture that the engien voerlays when you zoom in close up, thus the terrain never looks stretched unless it's been done to the extreme and is looked for..
minispring addresses several problems:
the range of the los.
-los radious is bigguer for minispring units (in coparision to normal).
this has been proposed several times too, the units should have a bigguer los. for realistic purpouses.
the size of the maps.
if the map is too big, it requires a lot of resources, thus you need a better pc to play epic maps.
well... we could make map quality so crappy that you can use a 233 to play spring.
this is a limit of the computers we have and not of the engine.
minispring alows a pc 3 yrs old to have epic maps, that is good, but at the cost of graphic quality.
to do such being closed minded and not thinking ahead.
Zoom out farther than spring..
-well this is an ilution as units are smaller, on same zoom, you have more of them in the view.
that can be fixed in the original size by allowing a farther zoom out.
Trees and stuff are bigger
lol... well if you want human size robots.. make a race of units like that.
currently, commander and units being taller than trees is the CORRECT scale.
if you want a mini commander with mini .. er.. there is minispring! and its cool
also.. there are some wrong things about minispring as unit footprints.
its a nice mod and trying to make it default is simplistic.
also spend more time on this is stupid, really, there are like 3 threads on this and a lot of hijacked threads (like this one) that have loads of stuff on it and i wont spend time reading those.
you better address this issues in a better way.
the range of the los.
the size of the maps. (better pc)
Zoom out farther than spring..
non right lod in map tiles..
the range of the los.
-los radious is bigguer for minispring units (in coparision to normal).
this has been proposed several times too, the units should have a bigguer los. for realistic purpouses.
the size of the maps.
if the map is too big, it requires a lot of resources, thus you need a better pc to play epic maps.
well... we could make map quality so crappy that you can use a 233 to play spring.
this is a limit of the computers we have and not of the engine.
minispring alows a pc 3 yrs old to have epic maps, that is good, but at the cost of graphic quality.
to do such being closed minded and not thinking ahead.
Zoom out farther than spring..
-well this is an ilution as units are smaller, on same zoom, you have more of them in the view.
that can be fixed in the original size by allowing a farther zoom out.
Trees and stuff are bigger
lol... well if you want human size robots.. make a race of units like that.
currently, commander and units being taller than trees is the CORRECT scale.
if you want a mini commander with mini .. er.. there is minispring! and its cool
also.. there are some wrong things about minispring as unit footprints.
its a nice mod and trying to make it default is simplistic.
also spend more time on this is stupid, really, there are like 3 threads on this and a lot of hijacked threads (like this one) that have loads of stuff on it and i wont spend time reading those.
you better address this issues in a better way.
the range of the los.
the size of the maps. (better pc)
Zoom out farther than spring..
non right lod in map tiles..
two version on this are PERFECTLY ok, i dont think why this cant be done.Warlord Zsinj wrote:While Spring and TA are all about giving as many options to the players as possible, something like this is such a massive change that you just cannot have two versions floating around.
zjin is very mistaken about that.
just need to be programmed as a mod. and not a engine change (that is easyer to do for buggi i guess).
minispring changes a lot of stuff and is worth being a hole different mod.
if some of its fans had the time to port it as such.
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
I can't be bothered arguing with you, Mongus.
You are wrong, but I don't want to repeat myself for the millionth time. If you want to see why there can't be two versions of Spring, go read up on previous threads.
Please stop double posting, and put some effort into your posts to make them vaguely comprehendible.
You are wrong, but I don't want to repeat myself for the millionth time. If you want to see why there can't be two versions of Spring, go read up on previous threads.
Please stop double posting, and put some effort into your posts to make them vaguely comprehendible.
-
smokingwreckage
- Posts: 327
- Joined: 09 Apr 2005, 11:40