Realistic/WWII total conversion?

[Watermelon]

lol! this was exactly the kind of thing i was trying to do using normal mod tools -- you just couldn't trick it that way... one thing i didn't do much of back (or now) then was warzone scripting, so there might be some way to "deresearch" the root node at game start to disallow each player from getting another faction's tech.

I dont know how to do wz scripting either,maybe I'll ask Troman if he knows how to do advanced scripting to implement factions,since he is the expert in this field.

[Troman]

I dont know how to do wz scripting either,maybe I'll ask Troman if he knows how to do advanced scripting to implement factions,since he is the expert in this field.

What Kage proposed should work. Just instead of 'deresearching' you don't pre-research stuff which would would give access to a tech branch not supposed to be used by this player. The implementation in scripts is trivial, shouldn't cause any problems.

[kage]

What Kage proposed should work. Just instead of 'deresearching' you don't pre-research stuff which would would give access to a tech branch not supposed to be used by this player. The implementation in scripts is trivial, shouldn't cause any problems.

hmmmmmm... are you saying that the engine doesn't "give" each player the root nodes of the tech tree on game start? if so, i feel pretty stupid that the obstacle in my way was not an obstacle at all.

and if so, might as well do it through scripting, because everything we can seperate out from the source code without severe performance penalties, we should.

[Watermelon]

What Kage proposed should work. Just instead of 'deresearching' you don't pre-research stuff which would would give access to a tech branch not supposed to be used by this player. The implementation in scripts is trivial, shouldn't cause any problems.

Thanks,I'll also need to find way to 'signal' the script with the info/Id of the faction the player(s) picked.Think the slo and vlo have tons of potentials,though we dont have many ppl interested in scripting in wz scripting language it seems.

[kage]

Thanks,I'll also need to find way to 'signal' the script with the info/Id of the faction the player(s) picked.Think the slo and vlo have tons of potentials,though we dont have many ppl interested in scripting in wz scripting language it seems.

wz scripting is a lost art: since we have the source code, it seems pointless to learn a quirky scripting language that is described as "homebrew" by its own creators when that can be abstracted into a scripting module, and add a second module to allow scripting via something like lua, python, or any number of other clean, pretty, and good-for-game-scripting languages that have several orders of magnitude greater capability.

way i was dealing with factions was to have one player color (up to 8 different ones) represent any of united states, german, russian, british, japanese, etc (fixed factions based on color), and have the scripts force alliances based on that (as far as i knew, both forced alliances and figuring out player number were possible via scripting). while this was good enough for a wwii mod, i can definitely see how it's not flexible enough for most other faction-based gameplay. it probably should be as easy as providing single variable, and letting the scripts run with the rest.

[Watermelon]

wz scripting is a lost art: since we have the source code, it seems pointless to learn a quirky scripting language that is described as "homebrew" by its own creators when that can be abstracted into a scripting module, and add a second module to allow scripting via something like lua, python, or any number of other clean, pretty, and good-for-game-scripting languages that have several orders of magnitude greater capability.

way i was dealing with factions was to have one player color (up to 8 different ones) represent any of united states, german, russian, british, japanese, etc (fixed factions based on color), and have the scripts force alliances based on that (as far as i knew, both forced alliances and figuring out player number were possible via scripting). while this was good enough for a wwii mod, i can definitely see how it's not flexible enough for most other faction-based gameplay. it probably should be as easy as providing single variable, and letting the scripts run with the rest.

Adding a faction option in multiplayer menu is easy,I just need to figure out how the color/team info gets passed to script/how the script recieve and process the info from multiplayer host interface.

[kage]

Adding a faction option in multiplayer menu is easy,I just need to figure out how the color/team info gets passed to script/how the script recieve and process the info from multiplayer host interface.

the in-game script stuff will be the easy part... the multiplayer/skirmish menu interface will be the hard part, since the menus seem to use bitmaps for everything, and since they were only programming this game with the concept of "color = faction && faction = color", and afaik everything in the multiplayer menu used a fixed-position layout (so adding the option may be easy, but making it look any good will mean you'll have to edit a few png's). hell, for all i know, since all the "colored flags" are represented in a straight horizontal line in the png, and they have pretty much the same appearance when loaded into the menu, and color to player # relations are fixed, the whole set of colored flags might just get loaded as one chunk instead of seperated out individually, in which case, if you want to represent the faction along with the player color, you'd have a bit of work to do... hmmmm... probably better off just setting aside a whole new section of that screen for your shiny new option, which it seems you were already planning on doing.

[Troman]

Adding a faction option in multiplayer menu is easy,I just need to figure out how the color/team info gets passed to script/how the script recieve and process the info from multiplayer host interface.

For color we can use:

INT getPlayerColour(INT player)
VOID setPlayerColour(INT colour, INT player)
those functions are documented in scriptLang.rtf

hell, for all i know, since all the "colored flags" are represented in a straight horizontal line in the png, and they have pretty much the same appearance when loaded into the menu, and color to player # relations are fixed, the whole set of colored flags might just get loaded as one chunk instead of seperated out individually, in which case, if you want to represent the faction along with the player color, you'd have a bit of work to do... hmmmm...

Player color is not fixed, it can be changed with VOID setPlayerColour(INT colour, INT player). Player name is now modifyable as well: instead of colors - black, green etc - we can assign any name to any player in the game.

There in no direct factions support, but wz now support fixed teams (I was really missing that feature in the past), maybe that could be used as a basement.

wz scripting is a lost art: since we have the source code, it seems pointless to learn a quirky scripting language that is described as "homebrew" by its own creators when that can be abstracted into a scripting module, and add a second module to allow scripting via something like lua, python, or any number of other clean, pretty, and good-for-game-scripting languages that have several orders of magnitude greater capability.

Pardon me, but your position is ignorant.

The only argument seems to be the fact that Pumpkin labeled their script as 'homebrew', which is not necessarily a synonym for "quirky" or not "clean, pretty, and good-for-game-scripting".

Any there are specific complains? What capabilities are missing?
I think your statements are based in incomplete knowledge.

As for the learning curve, what can be easier than C? That plus some wz-specific extentions is all that makes it out. Nothing can be easier or prettier, that's one of the reasons why I want to keep it.

[kage]

c is a low level language... learning curve is not very gentle -- i took 3 years of classes in c++ and 3 years later, i'm still learning new parts of the language spec. i learned the full syntax/construct spec of, as an example, python in 1.5 hours, not to mention, when speaking of c or c++ specifically (not referring to wz scripting here), the lack of garbage collection alone is brutal to new programmers: it teaches better programming techniques, but doubles the inclination of that fabled learning curve -- this is greatly amplified since the programmer is able to directly manipulate their program's virtualized memory.

Pardon me, but your position is ignorant.

The only argument seems to be the fact that Pumpkin labeled their script as 'homebrew', which is not necessarily a synonym for "quirky" or not "clean, pretty, and good-for-game-scripting".

indeed it is: i was trying to speak from the perspective of someone who is completely new to warzone and wants to learn to mod it -- the typical new modder with any prior programming experience would generally be more comfortable using a mainstream and well established interpereted embeddable language that has been used very successfully in game scripting, such as lua or python, and that already has hooks for doing things like loading files for mod-dependent settings (physfs helps eliminate any malicious virus-like scripts here), or, in some games extending the network protocol. as it stands, modders are something of a commodity: it doesn't matter as much for a foss community, but if there's some gnarly obstacle standing in the way of someone modding this game, whatever it is, they often enough will take their efforts, and mod ut2004 into an warzone clone, and then tweak that to do what they wanted.

my perspective: i don't mind using the wz scripting language -- it's good at what it does, and the only feature i'd like to see added is object support since i got tired of creating lots of parallel arrays.

and because of my perspective, i've never once suggested we rip out wz scripting and replace it with something else, while converting all current scripts to the new language: i've always made the argument that we should modularize the wz scripting stuff so that it can be loaded on equal terms with any new, say lua or python (or something else) scripting module.

[Watermelon]

c is a low level language... learning curve is not very gentle -- i took 3 years of classes in c++ and 3 years later, i'm still learning new parts of the language spec. i learned the full syntax/construct spec of, as an example, python in 1.5 hours, not to mention, when speaking of c or c++ specifically (not referring to wz scripting here), the lack of garbage collection alone is brutal to new programmers: it teaches better programming techniques, but doubles the inclination of that fabled learning curve -- this is greatly amplified since the programmer is able to directly manipulate their program's virtualized memory.

indeed it is: i was trying to speak from the perspective of someone who is completely new to warzone and wants to learn to mod it -- the typical new modder with any prior programming experience would generally be more comfortable using a mainstream and well established interpereted embeddable language that has been used very successfully in game scripting, such as lua or python, and that already has hooks for doing things like loading files for mod-dependent settings (physfs helps eliminate any malicious virus-like scripts here), or, in some games extending the network protocol. as it stands, modders are something of a commodity: it doesn't matter as much for a foss community, but if there's some gnarly obstacle standing in the way of someone modding this game, whatever it is, they often enough will take their efforts, and mod ut2004 into an warzone clone, and then tweak that to do what they wanted.

my perspective: i don't mind using the wz scripting language -- it's good at what it does, and the only feature i'd like to see added is object support since i got tired of creating lots of parallel arrays.

and because of my perspective, i've never once suggested we rip out wz scripting and replace it with something else, while converting all current scripts to the new language: i've always made the argument that we should modularize the wz scripting stuff so that it can be loaded on equal terms with any new, say lua or python (or something else) scripting module.

Learning curve 'difficulty' is reduced significantly when you already know one or more programming languages,if you start learning python with no programming background or whatever,it would probably take you few months to understand its extremely strict syntaxs and such.

wz scripting is no exception,maybe we just need some good docs,some time to make it get recognized.

[lav_coyote25]

i keep saying that those docs we got!!  and i have even said where they are.  ;D - all one has to do is go get em.

register - receive an confirmation email - login - goto downloads - grab the documents project file.



warzone2100DocumentsProject4.8.rar

[Troman]

c is a low level language... learning curve is not very gentle -- i took 3 years of classes in c++ and 3 years later, i'm still learning new parts of the language spec. i learned the full syntax/construct spec of, as an example, python in 1.5 hours

WZ Scipts are just a tiny subset of C. You surely won't need more than this to go through the EBNF of the wz scripts syntax. We don't have a clean EBNF documentation unfortunately, but for those who is interested it can be found in bison .y files. And just by looking at the existing script or scriptlang.rtf it is actually more or less self-explanatory.

indeed it is: i was trying to speak from the perspective of someone who is completely new to warzone and wants to learn to mod it -- the typical new modder with any prior programming experience would generally be more comfortable using a mainstream and well established interpereted embeddable language that has been used very successfully in game scripting

I'm sure a typical modder has learned how to declare/multiply/divide/subtract variables and make function calls in C before he mastered any scripting language. And even if he hasn't, it might be about time.

such as lua or python, and that already has hooks for doing things like loading files for mod-dependent settings (physfs helps eliminate any malicious virus-like scripts here), or, in some games extending the network protocol. as it stands, modders are something of a commodity: it doesn't matter as much for a foss community, but if there's some gnarly obstacle standing in the way of someone modding this game, whatever it is, they often enough will take their efforts, and mod ut2004 into an warzone clone, and then tweak that to do what they wanted.

All true, but doesn't affect us, luckily. Look at any other aspects of the game, sound, gfx, anything else. How many modders do/did we have? Even in the NEWST days. I have more fingers on my both hands. The only exception is maps.
WZ is one of the modder-friendliest games I have seen. Literally any aspect of the game can be modified, but apparently this is not all that a game must be able to offer.
We can teach people how to use wz scripts or add new units but nothing can replace the motivation or passion (it is another question why WZ can't motivate people) and if you have those two I'm sure you don't need anyone to explain you how to master a simple scripting language, although some help can surely be helpfull at some stage, but not that much help was needed in the past.
If there's such a need it can be satisfied quickly.

Learning curve 'difficulty' is reduced significantly when you already know one or more programming languages,if you start learning python with no programming background or whatever,it would probably take you few months to understand its extremely strict syntaxs and such.

wz scripting is no exception,maybe we just need some good docs,some time to make it get recognized.

Even if Coyote's documentation archive is huge already, I hope he will not mind if it will grow a bit. 

[kage]

well, on all counts true, troman.

wz scripting is a really small subset of c - no externs, no unions, no malloc. it's definitely easy by comparison -- i wouldn't even call it "c" any more than i'd call php "c", even though php's syntax is also heavily based on c and c++. so yeah, it's not bad at all from an embedded language standpoint (i still think it needs structs though).

you'll still find that the language learning thing is true though in many cases: i've seen many a time where a modder will have a great idea, but will get scared away from even some negligable unpleasantry and make that same mod using another engine that isn't half as suited for the task (but which they are more comfortable working with).

yes, we certainly don't have many modders, and only 3 or 4 active ones that i know of, and we're not going to get many more, no matter how nice we make the graphics, unless we get our project out in the open, which pretty much means publicity stunts. maybe we could start some "best mod" contests, in conjunction with tournaments (we would want to add some way to spectate, and allow spectators to follow any unit in the normal "space bar" way -- best achieved by having a secondary "wz tv" server that is responsible for all spectator requests, so that we don't lag out the primary server). a small bit of concentrated effort doing what is needed to set that up (master server that keeps track of player stats, and the protocols to communicate those stats, central mod repository that automatically handles meta-data inside the .wz like is done with many unix package management systems) could pay off with a huge influx of players, devs, and modders: if we were really successful with such a thing, i'd not be surprised if we quickly had 1500 registered users at this site.

in fact, at this point i don't know of anyone who regularly plays warzone via multiplayer -- there's no master server, so getting into a random game is next to impossible... perhaps if we sent up a temporary forum, in which people wanting to host will list the date, time, region, and ip address of their game (preferrably using some standard, such as GMT), including the official game start time. an example (none of the below is for anything but demonstration purposes -- i won't be hosting a game):

Code: Select all

hoster: kage
ip address: 137.208.211.16 (i made this up -- don't try it)
region: western united states (used so that players can estimate how good or bad their ping will be)
lobby available: 02:30 GMT (24 hour time format), 2006/12/04 (yyyy/mm/dd, or some pre-agreed upon standard format).
game starts: 02:50 GMT
game type: 4 player, preferred 2 on 2, free-for-all and humans vs comps available if there is a shortage of players

way i see it, people aren't going to be too interested in modding for this game, or downloading this game to play if there isn't a good community of people to play it with. if we want this community to grow bigger, we're probably not going to be able to count on the single player campaign to do that.

If there's such a need it can be satisfied quickly.Even if Coyote's documentation archive is huge already, I hope he will not mind if it will grow a bit. 

he's a tough guy... i think he could take it... 

[lav_coyote25]

for 5 years now i keep asking for documentation -  >:(    (or is it 6 now???? ???)


BRINGITON!!!!!!!!! ;D


i have been thinking that instead of one huge freaking massive file i am going to have to break it up into probably by topics instead... whatchathink... would that be better? ???

[kage]

would be nice if we could also wikify a lot of that data in addition to having coyote's offline reference.