Repulsor Tweak

[incidenta5]

I put all the code under an SVN repository, now I should be able to create diffs for the real SVN server in case others want to mod the game in similar ways

[patmo98]

There have been many people screaming for a patch that does nothing except make repulsers on/off able (or make hold fire work). I bet a patch that did that alone whould be VERY populer.

[incidenta5]

There have been many people screaming for a patch that does nothing except make repulsers on/off able (or make hold fire work). I bet a patch that did that alone whould be VERY populer.

Off to post the diff then I guess :)

[Edit]

Patch .diff for PlasmaRepulsor.cpp

[Dragon45]

There have been many people screaming for a patch that does nothing except make repulsers on/off able (or make hold fire work). I bet a patch that did that alone whould be VERY populer.

Off to post the diff then I guess :)

[Edit]

Patch .diff for PlasmaRepulsor.cpp

Let me reword that for you:

PATCH .DIFF FOR MUCH-WANTED FEAUTURE

[incidenta5]

There have been many people screaming for a patch that does nothing except make repulsers on/off able (or make hold fire work). I bet a patch that did that alone whould be VERY populer.

Off to post the diff then I guess :)

[Edit]

Patch .diff for PlasmaRepulsor.cpp

Let me reword that for you:

PATCH .DIFF FOR MUCH-WANTED FEAUTURE

Time to edit my main post :)

[Dragon45]

^_^

[AF]

You posted a bianry? You are aware people with this can battle eachother but not the ordinary users?

[incidenta5]

You posted a bianry? You are aware people with this can battle eachother but not the ordinary users?

This was the only way to get the proper functionality for the mod. Its a small tweak that can possibly be added into the main game if a dev approves it.

For now, its possible to play by swapping the executable and playing against others you know have the same version. I had a really fun lan game not to long ago with this mod on :)

[Argh]

I'll have to try it out and see how it came out

[Soulless1]

can someone mirror this on FU or something? Rapidshare won't let me download it for some bizarre reason - they're insisting that i've downloaded a whole load of stuff already when I haven't.

[zwzsg]

I already have the behavior of the emitter linked to the fire state:
Hold Fire - (same as the off button)
Return Fire - bounce mode

Instead of liking that to the firestate, I wish it was linked to some static TDF tags.

Also, I'd like shield that reflect laser too! Oh, and what about the Dune kind of shield, that explode big time when hit by laser? (Ok this one is probably a stupid idea that no mod will use, and that's not worth spending time to code). But most of all, keep everything configurable with TDF file.

It's good to see works on Spring shields, they look so nice it would have been a shame to let them remain in their current unuseable state. Having them turn off when script says so or when lacking energy, and have it possible to define which weapons shields work against is a big plus.

Hmm, how would that "Shield Type" work? Would you have a few hard coded category based on tags such as ballistic=1; / lineofsight=1; / selfprop=1; ? Would you have to name every single weapon a mod use in each shield TDF? Would a system with user defined groups similar to the units "armor.txt" be implemented for weapons?

[incidenta5]

I've been looking into making these changes a bit more elegant. So far, I think there might be at least one cause for a sync error; but only if players are in different modes; such as bounce or collision. On/off should work fine as long as the mode is the same between players.

Adding a section to the FBI file is probably the easiest way to go at this point. I'll be looking into this, so I can eliminate any possible sync errors.

[Soulless1]

Is it possible to give a shield it's own personal power source and shield energy capacity, unrelated to your total energy? I ask because such a feature would enable the widespread use of shields on a unit-by-unit basis, in mods like FF.

[jcnossen]

Allowing it to be set by the COB script would be better than FBI, which is always depending on actual C++ code for the behavior.
Implementing another GET/SET option in the cob interpreter is very simple too.

[FizWizz]

Does this mean that it is relatively simple to add ANY type of secondary 'life' bars to a unit, like Fuel, or ammunition, shielding?

[jcnossen]

It is sort of easy to add one little thing yes, but it's the wrong way to go. With adding all these little gameplay things, you keep having to maintain the code (ie: spending a lot of time on it when some other change breaks it)

What would the solution to all of this is ofcourse a scripting language, (suprisingly all the commercial game engines have that )

Now you think I'm just putting the job in the modders hands, but in reality what will happen is that because things are better seperated, things tend to break less.
And the C++ gamecode will be relatively small, so it's easy to maintain for the engine developers.
The mods will have independent scripts so when a game script (what used to be C++) does something wrong it only affects a single mod.
Last but not least, unit/modmakers will have much more flexibility but that is already known....

Modmakers, especially GZ, say that scripts will be too difficult, but they are forgetting that the engine developers could be writing the first mod implementation compatible with the current fbi stuff. Then modders can take that code, throw everything out they don't need and start extending.

Anyway, this post is just an attempt to promote the idea of extensive scripting in spring... nothing really happening yet

[Argh]

As a modder who has worked with scripting languages in several game engines (TA, DoW, Freelancer, RuneSwordII, etc., etc.)...

I am 100% in agreement with Zaphod. I want everything under my control that is possible, without ruining performance or piling on complexity where it isn't warranted.

That said, how the scripting language's syntax is designed (is it easily readable? does it require a great deal of knowledge about finicky order of lines, or will it accept anything under a given header line in any order? Is it in Plain English, or does it require annoying or difficult-to-type special characters?) matters a LOT.

For example... Freelancer's scripting language was just about ideal, in some ways. It was written with a series of states in textfiles, much like TA's TDF/FBIs are.

However, just like the TDF/FBI system, it severely lacked flexibility. For example, you couldn't use mathematical operators. Nor could one type of textfile refer to others (other than very peripherally) and perform operations on its values. As another example, it wasn't possible to, say, change the number of hitpoints a given spacecraft had because of some other operation. This is the problem with a system like TDF/FBI, and why we should go to something that is still simple, readable, and easy... yet flexible.

BOS actually gives a very good example of how to do this right. It has a simple syntax (for the most part) supports mathematical operations well, and can do subroutines, randomizers and other fun things. The only problem with BOS is how easily it can get locked if two operations occur simultaneously, and in Spring this doesn't seem to happen like it did in OTA, so it's really a non-issue at this point.

And once we (by "we", I mean the modder vanguard, plus the developers) get some stock code built, such as "this is how you do a particle system attached to a Unit", "this is how you script a Unit with dynamic hit points affected by what attacked it", etc., we'll be going in a very useful direction, I think.

I look forward to the day when we move from a static world of simplistic flat-files and towards a dynamic approach where the game engine is, essentially the Thing that Executes, rather than being one of the creative forces in its own right. Freelancer's design team did that part really well, in my opinion- their code was clearly very modular, and broken into a series of DLLs which were called by the game engine core when needed. They did a lot of other things wrong, mind you, like having bizarre file-format issues (their content side made Spring's "spaghetti loops" look tame, trust me- they had, for example 3 different kinds of sound formats!)

Very, very powerful, but not so powerful that it requires a degree in CS or any knowledge of compilers, SVNs, and all of the other arcana I hear you guys talk about- that's about my speed

[incidenta5]

I'll look into the scripting angle of controlling the building.

As for the secondary bar, I can add the code to make it work in practice, but I haven't gotten the second bar to draw properly just yet.

I was considering doing the same type of setup that i did with the shield itself. I could have the bar change colors from green to red based on shield strength while the left->right part of the bar would be unchanged.

Edit:

I've got a simple shield strength readout setup in spring .70b3. I'll tie it into the repulsor weapon at some point so individual units can use it :)

[Warlord Zsinj]

At the risk of sounding like a broken record, anything termed a "shield" would need to reflect lasers, other wise it would just be a "personal plasma reflecter", seeing as it can only repulse that type of weapon. Mods which would make significant use of this, such as FF and SWS, and even probably AA all use laser weaponry significantly, and so would require some sort of response here to really use such a function and be able to call it a "shield". (ie: "Why does my shield block cannons, but not lasers?", etc)

[SinbadEV]

It's a "kinetic" shield... not an energy sheild.