Spring RTS Engine

Stop being so melodramatic. You haven't been here long enough to understand how mapping was when I first started... When azure rampart was the pinnacle of spring mapping *shudder*.

Mapping has come a long way, and with the advent of lua it is inevitable that maps are going to contain code, including code that causes it to communicate directly with a game. Just be thankful to behe that now we can compile maps that look damn near photorealistic.

Go make another rainbow map or speednuts 12 and be happy.

i have nothing against in making better looking maps.

my point is, all those lua features that makes maps better looking, should be simple to add in your map, without you having to script it there with lua.

Oh and i dont mean that everything can be added into static TDF file as an option, lua can still be used. But the default map settings should never be overrided by lua script...

any code can crash.

TradeMark wrote: my point is, all those lua features that makes maps better looking, should be simple to add in your map, without you having to script it there with lua.

The coding is already done. God forbid you have to change a few values *gasped*

aegis wrote:

TradeMark wrote:added straight into the engine

then we can't modify it anywhere near as easily, and bugs can break the entire engine, instead of a single script's operation

But on the other hand, bugs can be fixed in the engine once for all and ever, instead of being fixed in only one mod and remaining in a hundred other mods and maps.

zwzsg wrote:But on the other hand, bugs can be fixed in the engine once for all and ever, instead of being fixed in only one mod and remaining in a hundred other mods and maps.

yeah that too...

Forboding Angel wrote:God forbid you have to change a few values *gasped*

good dreams on that "few values"

Just keep in mind that implementing features in lua is a completely different issue from using lua for data. Lua is used for data because it can have better defaults (no looking into the spring source for them, and they can be multiple-variable), and so that spring only has one text file format. None of this matters when you're talking about a feature like fog.

Trademark cba figuring out how to generate a lua VM inside a php script and would rather kick up a fuss on the spring forums

AF wrote:Trademark cba figuring out how to generate a lua VM inside a php script and would rather kick up a fuss on the spring forums

false, i already have lua parser

Then you dont need to kick up a fuss and faff around with this thread do you?

I think the discussion actually should be about what I also see as an upcoming problem if things keep developing the way they are right now and that are logics either game relevant or otherwise providing huge changes that come with a map but have nothing to do with a map itself. As I see it even TradeMark now isn't moaning about a change to a Lua syntax. I think that is a good idea so we get something free and useable over the entire engine from unit scripts over gadgets/widgets up to whatever variables you want to pass over to the engine be it unit stat files or resources that should be included...

Even though I agree TradeMark put a bit too much drama into expressing his view I share his opinion towards what maps are providing nowadays and what disadvantages this has. Seriously if a map includes stuff about how to render certain things then something is going wrong in my opinion. I from the top off my head don't have a perfect solution or advice what to do but I think it's appropiate to do an actual discussion about it so please stop posting if you intend to just flame TradeMark. Thanks...

Does parser in this case mean real execution, or in the same terms as trying to use regexes on html?

I am waiting for the day they decide terrain handling with lua is wrong and decide to invert all the values so they're proper.

Caydr wrote:I am waiting for the day they decide terrain handling with lua is wrong and decide to invert all the values so they're proper.

+1
Coordinates in 2D plane should be x,y. Z should be height. But they used OpenGL convention.

ye x,z,y doesnt make sense. and its not opengl's fault...

for some retarded reason they think thats the right way of doing things.

I'm pretty sure "they" don't think any such thing. It happened and supposedly going back and changing it is nontrivial.

y is up is pretty standard. Honestly, stop moaning about utterly irrelevant things.

TradeMark wrote:ye x,z,y doesnt make sense. and its not opengl's fault...

for some retarded reason they think thats the right way of doing things.

That's why we use x,y,z

(And yes, what we use is the same as what OpenGL uses by default...)

FLOZi wrote:y is up is pretty standard. Honestly, stop moaning about utterly irrelevant things.

references please.

I'd argue that OpenGL is "up" agnostic, it doesn't
really care what the Xs, Ys, and Zs refer to.

Note that it could be argued that OpenGL's default
"up" coordinate is Z, if you consider looking down at
the terrain as default view point (OpenGL's Z
defaults to the axis that is normal to the screen, ie:
in and out of the screen).

P.S. I've always found Spring's (x,0,z) setup irritating