Spring RTS Engine

detailtexes are messed up in newest version:


also if your going to do a release you want shared pls give it a new version number in map name... otherwise map server doesn't detect a new map on springfiles and it doesn't get uploaded to autoservers

The Yak wrote:detailtexes are messed up in newest version

yep qray showed me that the detail tex's are messed up too.. I've literally only just finished uploading the fix. so should be all good now. I had problems last night getting it uploaded, and it was 4am so i crashed out while it was going.

The Yak wrote:also if your going to do a release you want shared pls give it a new version number in map name... otherwise map server doesn't detect a new map on springfiles and it doesn't get uploaded to autoservers

hmm, so forget the version part of springfiles? and just add it to the name?

the .smf file needs to have a different name to get recognized by mapserver

EDIT: .smf not sd7

The Yak wrote:the .smf file needs to have a different name to get recognized by mapserver

EDIT: .smf not sd7

oh, well that's weird. thanks i will try to remember it for next time.

Please upload map with a new version. Autohost, lobby download and springfiles is desync. Makes lots of problems for players, in the end map changed and never played :(

dansan wrote:Please upload map with a new version. Autohost, lobby download and springfiles is desync. Makes lots of problems for players, in the end map changed and never played

ok.

No, not the SMF... The map itself needs to have a different name. The file names are irrelevant.

Assuming you are using mapinfo.lua this just means that you need to bump the version number.

That said, plasmaserver is incapable of reading mapinfo.lua and licho won't fix it (I've been asking for over a year). As a result, you need to include a blank smd file that is the name of your map. It's stupid as shit, but that is the only way to get plasmaserver to see an ssmf map.

Forboding Angel wrote:No, not the SMF... The map itself needs to have a different name. The file names are irrelevant.

Assuming you are using mapinfo.lua this just means that you need to bump the version number.

That said, plasmaserver is incapable of reading mapinfo.lua and licho won't fix it (I've been asking for over a year). As a result, you need to include a blank smd file that is the name of your map. It's stupid as shit, but that is the only way to get plasmaserver to see an ssmf map.

so, update the mapinfo.lua version to 3.1 add a basic smd with what? the name and version of the map? can you give an example for me so i get it right the first time?

I usually do the smd like

Mapname-v<versionnumber>.smd

That way, if I search for it via autohost, it will work correctly.

Autoupload to Zero-K map server (plasma) seems broken, but I found I way to sync it manually... here you go: http://zero-k.info/Maps/Detail/29574

EDIT: Would it be possible to do a version without Springfeatures dependency? This prevents people from playing it on autohosts with certain lobbies (Springlobby, ZKlobby) and also prevents it from being featured with ZK hosts. Charlie 2.1 is featured so I'm quite sure this one will be too if it was compatible with all lobbies.

The Yak wrote:Autoupload to Zero-K map server (plasma) seems broken, but I found I way to sync it manually... here you go: http://zero-k.info/Maps/Detail/29574

EDIT: Would it be possible to do a version without Springfeatures dependency? This prevents people from playing it on autohosts with certain lobbies (Springlobby, ZKlobby) and also prevents it from being featured with ZK hosts. Charlie 2.1 is featured so I'm quite sure this one will be too if it was compatible with all lobbies.

OK, give me a little time, I will have to re-do the features from spring features and include them in my archive. I have them mostly separated already but it still requires some work.

The Yak wrote:EDIT: Would it be possible to do a version without Springfeatures dependency? This prevents people from playing it on autohosts with certain lobbies (Springlobby, ZKlobby) and also prevents it from being featured with ZK hosts.

Spring features is on rapid...

Doesn't matter, if not compatible with all lobbies it can't be featured on the ZK hosts. It's actually something that's prevented me from getting any of your EvoRTS maps featured

ZK lobby also doesn't grab dependencies anymore. I'm pretty sure it used to do this, but when we tried playing this map everyone who didn't have the springfeatures archive crashed out, even though nearly every player was using ZKlobby for windows.

Better to fix ZKL then.

KingRaptor wrote:Better to fix ZKL then.

Not necessarily, from what I understand, maps typically share very little data. The features of a map are microscopic compared to the texture data.

There is the possibility of savings of a few kilobytes, possibly a megabyte ( the unique features I use in charlie, all 15 of them with 512x512 texture maps amount to 1mb when zipped), there are perhaps another 5-10 features that are used from springfeatures.

Is that worth the hassle of having a dependency system?
Is the spring features archive subject to improvement changes that will have a flow on effect to the maps that rely on it?
Does it save a large enough percentage of bandwidth/storage between maps overall?

Considering these factors. I don't think its worth including deps in random generic maps. so regardless of whether ZKL gets fixed, I will be updating charlie so it doesn't rely on springfeatures.

Just got to get around to it, its rather tedious.

The Yak wrote:Doesn't matter, if not compatible with all lobbies it can't be featured on the ZK hosts. It's actually something that's prevented me from getting any of your EvoRTS maps featured

It has nothing to do with the lobby and everything to do with Licho refusing to fix plasmaserver. If you will notice: http://api.springfiles.com/

If you upload your map without the smd it is registered properly there. It is Licho's implementation that is all fucked up.

Spring features is on rapid, meaning that there can be many versions, and getting a different version is as simple as downloading a few kilobytes.

All lobbies should support dependency downloading. If they don't, it is a pretty huge lobby bug.

enetheru wrote:There is the possibility of savings of a few kilobytes, possibly a megabyte ( the unique features I use in charlie, all 15 of them with 512x512 texture maps amount to 1mb when zipped), there are perhaps another 5-10 features that are used from springfeatures.

Use DDS!

jK wrote:

enetheru wrote:There is the possibility of savings of a few kilobytes, possibly a megabyte ( the unique features I use in charlie, all 15 of them with 512x512 texture maps amount to 1mb when zipped), there are perhaps another 5-10 features that are used from springfeatures.

Use DDS!

Indeed I do already :).

I've had to do a bunch of reading lately on DDS or DXT textures, their quality has much to be desired, and their filesize is not really any good. Their only true benefit is the widespread hardware support for loading into memory and hardware memory footprint.

If we didn't care about map loading times, jpg is a smaller filesize for similar quality. but loading times are larger.

I've watched some good video lectures recently, will see if i can dig up a link sometime.

updated to remove springfeatures dependency http://springfiles.com/spring/spring-ma ... ie-hills-0

Thx.

Bug ? Spring & SpringLobby then doesn't see V3.2 map...

Checking basics and comparing to older vers...