Yet another doomed fantasy mod?

[wilbefast]

Guessmyname: I was following this tutorial:
http://springrts.com/wiki/Units:CreateModel

Which suggested you go with "Segment by Projection" - I did this for the Fugly Tank and, perhaps because it was a more complicated model than the example, I ended up with a rather confusing unwrap...ness.

This time round I manually selected surface and assigned Auv charts - I grouped things together in a way that seemed logical, and the result was a lot simpler and easier to use.

I've just realised that the inside of the box should have a flesh texture rather than a gold on - trouble is I've got no room left on the texture Would suck if I had to redo the whole thing from scratch: is there any way of adding more space to a texture? If not I suppose I can shrink the gold plate at make a second square for the inside...

It's hard going from 32x32 pixel art to texturing 3D models

I've got Maestro's tutorial - I'm going to try to get Fugly in-game now, though first I have to fix his alpha...

[zwzsg]

You learnt fast: Your second model is already on par with the good units I see around here.

If you don't suddenly disappear overnight like half of new the modders, you might very well manage to bring forth that mod of yours.

[wilbefast]

You learnt fast: Your second model is already on par with the good units I see around here.

If you don't suddenly disappear overnight like half of new the modders, you might very well manage to bring forth that mod of yours.

Cheers, really nice thing to say - we're not there yet though, got to work out alpha channels and animate it. Need to stop replying to forum posts and actually get some work done.
It's funny because you suggested I put a cube in-game - maybe I will

By the way, I will disappear overnight at the start of next week - eg: the end of my holidays. However, I will continue working on it, just not at the same manic pace.
Hopefully by then I'll have achieved enough to make me want to keep coming back in between lectures and course work. Still, I've been jealously guarding this idea for like 3 years, I'm hardly going to let someone else make it now am I.

That's the thing though isn't it - everyone thinks that everyone else wants to steal their ideas, but in the end everyone else has their own ideas they want to work on - not somebody else's...


edit: okay update - Fugly is now correctly team-coloured - I've downloaded FLOZi's empty mod file and I'm looking at creating a .fbi file for it (http://springrts.com/phpbb/viewtopic.php?f=14&t=17909)

This part looks tricky... since I don't know specifically want I want the unit to do except just sort of drive around and shoot stuff - like a normal tank you know? Gotta learn me some of that LUA

edit 2: hang on - am I using lua for this or fbi? Does it make a difference? Seems like the same tags...

edit 3: right, time to turn in I think to recap, we have a .sdd with the following folders to fill out:

• objects3d(.s3o files) => fugly.s3o [done]
• scripts (defines unit behaviour? Written as .bos or .lua?)
• units (defines unit flags? .fbi or .lua?) => created fugly.lua (no fugly.fbi):

  Code: Select all

  local unitName = "fugly"
  
  local unitDef =
  {
    name = "Fugly Tank",
  
    objectName = "fugly.s3o",
  
  }
  return lowerkeys({ [unitName] = unitDef })

• unittextures (texture is already included in .s3o - leave empty?)
• gamedata (leave alone for now?) => in sidedata.lua changed startUnit to "fugly"
• modinfo.lua (information about mod + some dependencies - I think)
• sounds (probably called by scripts => not nessecary)

[/b]

edit 4: Apparently you can just move the .sdd to your mods folder and the launcher will pick it up - nifty :D

I copied the cube.cob file and renamed it "fugly.cob" - for the moment that file is just a compiled version of:

Code: Select all

piece  base;

Create()

{}

I'm wondering how to either A - compile to a .cob and B - how to use lua scripting instead: no compilation =
Apparently the .s3o has a reference to a texture but the texture isn't included in the .s3o file itself I put the texture in the texture folder and...


High fives all round!

BTW - as you might have noticed I'm posting as a sort of journal - perhaps this will be helpful for other total noobs going through the same thing...

[Quanto042]

I got to say man, your demon box looked hella cool. I truly love how it looks, and I am pleasantly surprised that you didn't just make a box and texture it. Again, very nice.

[zwzsg]

That's the thing though isn't it - everyone thinks that everyone else wants to steal their ideas, but in the end everyone else has their own ideas they want to work on - not somebody else's...

You learn fast

• Written as .bos or .lua?
• .fbi or .lua?

At the beginning of times, there was no .lua.
Spring used retro-engineered Total Annihilation files formats.
- Units "stats sheet" were defined in /units/*.fbi (with syntax similar to windows's .ini file)
- Units "animations scripts" where defined in /scripts/*.bos /scripts/*.cob, where BOS is a compiled custom language with C-like syntax. You write the .bos, which is the source file, then you use a program called Scriptor.exe to compile it into a .cob, and .cob is the file actually used by the engine.

Then .lua was introduced to Spring.
Lua is an interpreted language, so you don't need any compiler for it, just write it in any text editor (Notepad++ would be a good choice though). Technically, I *think* the lua file are autocompiled by Spring the moment the engine loads them, but for the user it's transparent: You can edit a widget or a gadget, then reload the widget or the gadget, and have your change taken into account while still staying in the game, for instance.
- First Lua was for widget and gadgets.
But .lua is now progressively replacing everything else:
- Whenever someone ask for a feature request that previously could only be implemented engine-side by a C++ dev, now they are told to "Lua it!".
- At some point, the FBI parser that was in the engine was replaced by a FBI parser written in Lua, with the engine loading only the Lua version of the unit defs, allowing people to directly write their unit defs in Lua instead of FBI.
- Recently, Tobi abstracted the unit scripting, and then made it able to use .lua in addition to .cob.

So, now, you can write unitdefs and unit scripts either in Lua, either in the old way (respectively FBI and .cob/.bos). Being old school, I still use .FBI and .bos/.cob, which I find clearer, but I guess everybody else would tell you to forget about FBI and .bos/.cob and use only Lua. Using .lua offer the advantage of easier communication with other .lua stuff, and allow for dynamic stuff with ease. By that I mean, like, your unit "stat sheets" changing according to mod options, or unit scripts sharing tables with gadgets.

As for the syntax, crack open a mod that use them, and look around the wiki.

[wilbefast]

gotcha - so I could replace "scripts/fugly.cob" with "scripts/fugly.lua", it's just that the syntax won't be the same as in the "scripts/source/fugly.cob" because they're different programming languages. I know because I tried, just to see what would happen

Reckon I'm going to use lua (I'm no stranger to compilation but it's always nice to have something more simple to implement) - first thing I need to do though is figure out how to write:

Code: Select all

piece  base;
Create()
{
}

-in lua Then I'll build on it. It'll have to wait till Saturday though - I'm making slow progress with course work so I don't think this day-off-day-on type thing is going to work, even during the holidays

Never mind, slow and steady... also if I finished before the weekend there may be more people around I can ask for help with scripting.

By the way, the Demon Cube's faces were original supposed to be deformations of the actual box, but somewhere along the line I made it organic so it (flesh) and the box (gold) were different material. Result: it looks a bit like the head is glued to the outside of the box rather than bursting out from the inside.
Also I'm concerned that it may not read as well being part of the daemon faction - I need to make my mind up when it comes to a unified art design, I'm thinking perhaps:

Daemons = warped gold/silver/bronze, chitin.
Prometheans = granite, marble, clay
Fae = bark, fur, skin.
Undead = flesh, bones, electric bolts and rusty metal plates

Somewhere along the line the daemons all ended up where cool trench-coats, but from a practical point of view, well, that's likely to be hell to animate If I change the direction though it means changing the concept for Clock Face - who I think looks really cool with coat-tails
So coming back to the cube, I'm thinking of re-texturing it, making the whole thing metallic with the face coming forcing its way out, or making the whole thing fleshy, at the risk of conflicting with the undead.

Thoughts?

[zwzsg]

gotcha - so I could replace "scripts/fugly.cob" with "scripts/fugly.lua", it's just that the syntax won't be the same as in the "scripts/source/fugly.cob" because they're different programming languages.

Yes.

I know because I tried, just to see what would happen

Good.

Reckon I'm going to use lua - first thing I need to do though is figure out how to write

Lua for unit animation script is very recent, that would be why exemple and tutorials are scarce. Look for Tobi, 1944, and FLOZi, they were the first (and only?) to implement then use it.

So coming back to the cube, I'm thinking of re-texturing it, making the whole thing metallic with the face coming forcing its way out, or making the whole thing fleshy, at the risk of conflicting with the undead.

I'd rather have you not remake a single model until all the projected units are done, than remaking the same model again and again while the rest of the mod remains unfinished.

[FLOZi]

Reckon I'm going to use lua (I'm no stranger to compilation but it's always nice to have something more simple to implement) - first thing I need to do though is figure out how to write:

Code: Select all

piece  base;
Create()
{
}

-in lua Then I'll build on it.

Here is the the ARMSTUMP.bos (OTA stumpy unit script) converted into a lua unit script (It's probably not perfect, but should satisfy how piece defs and Create() work.

http://pastebin.com/f49542104

Note that you can also define pieces individually as such if you prefer

Code: Select all

local base = piece "base"
local turret = piece "turret"
-- etc

[wilbefast]

I'd rather have you not remake a single model until all the projected units are done, than remaking the same model again and again while the rest of the mod remains unfinished.

A very good point Let's not get overexcited before the model is even in game. Okay, so back to the tank...

Here is the the ARMSTUMP.bos (OTA stumpy unit script) converted into a lua unit script (It's probably not perfect, but should satisfy how piece defs and Create() work.

Sweet! I'm using your empty mod btw: very handy

I had a go at converting the lua script to work with fugly tank, whose sections are "flare", "head", "body", "wheel_r" and "wheels_l" - the last two might seem like an odd choice but my thinking was:

• move forward = turn both sets of wheels forwards
• turn left = turn right wheels forward, left wheel backward
• ... etc

The problem being that the front and back wheel on the left (or right) side don't turn around the same axis, and after reading the lua, I've realised how the animation works - I think - and it's just not going to work the way I envisaged:
As I read it (let me know if I'm wrong) you've got two functions to manually translate and rotate sections a given amount at a given speed along a given axis:

• Turn/Move (section, axis, where, how fast?)
• Wait for Turn/Move (section, axis)
• Send the "I am now read to fire" signal?

This is good news because it means that while it's infinitely easier to animate gun turrets than living bodies, there's theoretically no reason why organic-looking couldn't be achieved - you just need a whole bunch of segments and a whole load of unintuitive rotation and translating: smoke and mirrors rather than actually deformation.

Strandbeest

All done with rigid bodies Might not be all that efficient though...

Anyway, going back to the lua: it seems I'll have to go back to Upspring and maybe even wings to get the model fit for the game - maybe I'll just add the wheel to the body section and forget about it...

Anyway, let's see... we've got rotation of the turret (y) and angling of the barrel (z) to compensate for the pitch of the unit - then recoil of the barrel, wait for the barrel to return... The flare is shown and hidden... good stuff, I can actually make sense of most of it.
Not sure about the Threads and SignalMasks, but that's all stuff I should probably read up on...

One very simple problem though: I'm getting a "Could not load COB script from scripts/fugly.cob" error - is there something I should be setting up so that spring looks for a .lua and not a .cob?

[FLOZi]

You need to enable lua unit scripts

http://spring1944.svn.sourceforge.net/v ... iew=markup

Should help

[wilbefast]

You need to enable lua unit scripts

http://spring1944.svn.sourceforge.net/v ... iew=markup

Should help

redefines a constant? Okay, so:
- I need to put this in the right place so it is executed
- I need to put the file it wants to include in the right place so it can be included

OR

is "unit_script.lua" supposed to be replaced with "fugly.lua"?

Code: Select all

-- Author: Tobi Vollebregt
-- Enables Lua unit scripts by including the gadget from springcontent.sdz

-- Uncomment to override the directory which is scanned for *.lua unit scripts.
UNITSCRIPT_DIR = "scripts/"

return include("LuaGadgets/Gadgets/unit_script.lua")

mod gamedata? - I'm assuming those scripts are run when the mod is. Does it matter what it's called (apart from being a .lua)?

[Google_Frog]

Another advantage of lua unitdefs is that you can use the program CAEdit to do formula based batch edits.

[wilbefast]

Another advantage of lua unitdefs is that you can use the program CAEdit to do formula based batch edits.

Hold your horses there - first I need to get the thing actually working then I'll figure out what a formula based batch edit is (wikipedia?). I've had another try and I still have no idea how I'm suppose to use this pastebin code to activate lua unit scripts

edit: aha!

http://springrts.com/phpbb/viewtopic.ph ... 1&p=385611

edit: not making much headway with the scripting as there aren't any lua tutorial (as several people had mentioned) - I might end up doing it with cob in the end so that I can actually get some help
The reasons why I'm keen on using lua are that:
A - It's a "real" programming language.
B - I don't have to bother getting a compiler to work on Linux.
C - It's newer, so obviously must be better.
D - Just about everything else uses lua (except the engine itself of course).

In the meantime I finished off my daemon cube model:


I realised that the model didn't actually fit together - the plates would either have to merge or be different sizes, or I'd need a sort of "cage" around the outside. I think I'll use it for team colour and to provide a bit more contrast. It also makes the model look like a box rather than a just a bunch of plates.

Rather than assembling 12 rectangular bars I duplicated the top plate, scaled it up, intruded the middle to make a sort of square ring, then copied this onto the bottom, then bridged the two and removed the extra vertices and edges - result: a single model with 48 polygons rather than 6 models totally 72 polygons. Maybe I could have saved myself the effort, but it was good practice...

Unfortunately adding new elements to the model has done weird things to the UV map, or rather the new bits have ended up all bent and deformed all over the place in the UV - I'm still trying to figure out if I can got back and unwrap just those surfaces...
The problem may be that I duplicated a surface that was already mapped, and wings tried to extend the map as I did all my tricky whatsits - result = tangled mess...


edit 2: damn - I'm such an idiot: I never thought to have a look at the other mods to see what all the files are supposed to contain!
I've got so many examples now - joy

edit 3:

[maackey]

I just started my game from scratch: it doesn't have any unnecessary files. I'm adding more as I go along. You can download it and have a look if you want.

https://maackey.bountysource.com/ -- you can find it here. Just let me know if you need anything.

I really much prefer communication via the lobby, if you need any help. I find that lately I barely have enough time to browse the forums and make meaningful replies.

Anyway, I must be going. Just let me know if you need any help.

[wilbefast]

I figured I wanted the thing to run so that I could try various things and see what effects they had in game. When I know what everything does I'll be able to start from scratch - we're not all leet modders

I'm going to try to finish my course work by this evening (your morning) - then I'm going to track you down in the lobby: I have some serious questions


In other news, I've decided that the Golem team is a good team to start with because:
- they're the least atypical faction
- they'll be a lot easier to model and animate
I've decided that they'll use chess pieces as a theme, with a flat tech-tree: they have granite (earth/defense), obsidian (fire/assault), marble (air/flyers) and possibly lime (water/sea units) version of a pawn, bishop, knight, etc:

• Granite
  • King = armoured storage, can build, has shield (expensive - off by default).
  • Pawn = light m├¬l├®e.
  • Bishop = light artillery.
  • Knight = heavy m├¬l├®e, can jump.
  • Rook = heavy artillery (~bertha).
  • Queen = super-heavy artillery (~buzzsaw), has radar.
• Obsidian
  • King = armed storage, can build.
  • Pawn = light raider, anti-air.
  • Bishop = assassin (~penetrator).
  • Knight = riot (swarm killer).
  • Rook = heavy assault.
  • Queen = line-breaker (~Krogoth), has radar.
• Marble
  • King = hover storage, can build, has radar.
  • Pawn = hover scout.
  • Bishop = gunship.
  • Knight = light transport (1 unit).
  • Rook = bomber.
  • Queen = flying fortress, repairs aircraft, has radar.

That's 3 super units - so each one is less powerful and more specialised that they would be if there was only 1. Lime may or may not be used, depending on how many sea units are available to the other sides. Water is going to be a part of the game there - each team has ways of moving builders and certain combat units around the map, even without using transports.



I've had a thought though - units are defined in part by their build list, meaning that a unit can't build itself as that would mean referencing itself before it is defined (infinite loop). This, and the fact that the current AI doesn't like units building units, are making me consider using maybe one or two buildings (factories for example). But it's early days - for now I just want to get the units working in game.

edit: oh yeah, please comment on my unit list - (constructive) criticism is very welcome, otherwise I wouldn't have posted it!

[Google_Frog]

Flying golems? That makes little sense, if you want very different races you should consider no air for golems (probably need an airscout though). Also as they're basically rock they could all be amphibious which solves the sea problem.

You have a few artillery units but with little static defence and no energy what will artillery be for? Do you mean generally long ranged units like OTA Morty?

units are defined in part by their build list, meaning that a unit can't build itself as that would mean referencing itself before it is defined (infinite loop)

Could you explain this a bit more? I don't know if it's a perceived engine limitation or Golem-Lore.

This, and the fact that the current AI doesn't like units building units

People don't like units building units either as Spring factories provide players with many unit mixing and waypoint controls. If Golems are all going to morph/dig in to stronger static versions of themselves you could just make Kings morph to factories that can build their own rock type as well as other Kings.

Also why include radar in a fantasy game? Have you decided to add radar or is it a passing thought? Radar or no radar can both work and create an interesting intel game.

[wilbefast]

Flying golems? That makes little sense, if you want very different races you should consider no air for golems (probably need an airscout though). Also as they're basically rock they could all be amphibious which solves the sea problem.

Yeah, flying rocks had me stumped for a while but if you can make a rock lift itself off the ground, you can make it hover, and if you can make it hover, why can't it fly? You'll notice there's no interceptor or air scout: all their "flying" unit are sort of hover-disk things - they move a lot more slowly but have better armour than most other air units.

You have a few artillery units but with little static defence and no energy what will artillery be for? Do you mean generally long ranged units like OTA Morty?

When I say artillery I generally mean long-ranged units with a high trajectory. You're right though, with out buildings they're not all that useful
Another reason I wanted to have a few buildings: either way you'll be needing to entrench around resource points otherwise you'll lose them, and one of my main goals is to make a damaged economy somewhat crippling.

units are defined in part by their build list, meaning that a unit can't build itself as that would mean referencing itself before it is defined (infinite loop)

Could you explain this a bit more? I don't know if it's a perceived engine limitation or Golem-Lore.

When you define a builder unit, you write something like this:

Code: Select all

unitX = { ... builds(unitA, unitB, unitC, ...) ... }

I get an error whenever I try to make a unit able to build itself - I assume this is because you can't define a unit recursively - saying a unit can build itself is like saying:

Code: Select all

unitX = unitX

Say, if I want the Granite King to be able to build all Granite units: he won't be able to build other Granite Kings, because I can't include them in their own definition.

This, and the fact that the current AI doesn't like units building units

People don't like units building units either as Spring factories provide players with many unit mixing and waypoint controls. If Golems are all going to morph/dig in to stronger static versions of themselves you could just make Kings morph to factories that can build their own rock type as well as other Kings.

Sorry - didn't explain myself very well: I was always intending on doing something like the Cursed's stances, and Az has conveniently proved that it can be done However the AI never seem to build Necromancer/Lich units, only the ones that comes from stationary factories. I've done AI programming before and I'd rather not have to build my own custom AI for the mod - it's really hard
Then again I could always just forget AI and build it for PvP only.

Also why include radar in a fantasy game? Have you decided to add radar or is it a passing thought? Radar or no radar can both work and create an interesting intel game.

I say "radar" for the benefit of people used to TA - in game it will actually be called "intuition" or something, and serve mostly to detect stealthed or underwater units (so in truth it will be a combination of radar and sonar).
What makes radar in TA interesting is that it's one more thing to reinforce this "economic accountability" I've talked about, and provides long-ranged but only incomplete information about enemy troupe movements.

[FLOZi]

A unit can build itself just fine...

[wilbefast]

A unit can build itself just fine...

Don't say that! There I was, feeling really good about myself for putting my recursive programming knowledge to some use, and you had to go and ruin everything

More troubling, this means I need to figure out what the actual real problem is...

But first, course work

Algorithmics and Data Structures II [done]
Linear Algebra II [done]
Data bases [done]
Application and recursive programming [done]
Neuro-biology (option) [started]
Systems and networks [not started]

And all that in French

I need a hug...

[yuritch]

I'll give a hint: you don't have to define build lists at the same time you define the rest of unitDef. You can add buildlists at a later stage, when unitdefs for all things are already present.