Topic: Starting Resources

That Matter gets treated by a Lua-Script. There exist at Present 2 Scripts per Tribe for HQ-Start and another for Castle-Village. I think there is Need for another Abstraction: another Data-File (perhaps a CONF ?) which define Standard-Settings for Resources ... better call them here Inventory or StartingCapital (Term Capital does not imply that something have to be Money to be Capital, eg Ground and IP InterlectualProperties are Kinds of Capital as well). My first Idea was about you mean that Resources on the Map gets diced on StartUp adding some Surprise/Unknowness to the Map .. that Feature would require surely much more Development-Work.

Let's assume the Settings for Inventory are outsourced into another Type of File, we need at least one for Standard/Default while the StartingCapital-Editor /GUI could write another Setting as Temp-File and the Lua-Script takes just the File-Name for these Settings to extract Data for Init. That Way the Temp-Files could get used as some Kind of Cache of previous defined Custom-Settings without a special Saving to keep them beyond deleting Temp-Files.

Resume of Logical Deduction: there exist per Tribe two Scripts which have a large common Part: One sets a HQ and fill its Storage, the other place instead a Village with Castle and fill the WareHouse similar like the HQ-Script. The CrossSection here is the Data for Storage-Filling. Now as third Protagonist Custom-Filling enter the Stage. If we don't want any wired which patch the Things together we have to rethink/abstract/generalize that Matter to have a good Entry to insert custum StartingCapital into Storage. Eg I would increase Standard-Gold by 8 Gold to lower Impact from Depencies from Gold needed for several basic Features like ConstructionSite, Expedition and Expansion/Colonization resp Construction of another Harbort. I did some Time ago change the Init-Script aside of Inventory-Settings and figured out there exist a Lot of Potential for Generalization: there are effectivle

You can read the Tribe-CONF-Files a Lot similar like Source-Code from C++ resp in an OOP-Fassion: In C++ you can do all Init-Things for a Class its Instances by Code inside the Constructor BUT initializing the Class itself (static Fields/Variables) require Class-external Code. This Aspect returns for WL-CONF-Files in that Way that the Tribe-Classes can't initialize the HQ resp Castle/WareHouse as Representant of a Tribe-Class which means to be an Instance from the Tribe. The Tribe-Conf can explain a Lot what' s inside the Tribe and how it can do this/that but it can not explain how to place a Tribe on the Map. The Map-Editor can resp have to define at which Locations a Tribe can get placed by marking these Positions numbered as StartingPositions. Inside the Tribe-File-Hiearchy exist a Folder named 'script'. No Idea how you can use that Folde different but for sure there are Tribe-Instance-Init-Files searched. A broken Init-File causes Problems from starting a Game --- probably the Lua-Interpreter gets simply loaded by the Scripts there and if success their Script-Names are listed as Options for Player/Side how to init his Tribe. Other Scripts which can get loaded from Lua-Interpreter but can't init the Tribe would cause other Problems inside the Game. However, as long as that Init-Part can not get solved by the Tribe-Class-Definition resp CONF-Code I suggest to rename the Folde from very generic Name 'scripts' more specific to Term 'Init' inside Tribe-Folder (and so the File-Hiearachy explains better what is inside.. and I don't have to explain that these Scipts have probably to be only Tribe-Init-Scripts even the Folder-Name does not explain that but indicate also other Tribe-Scripts could get placed there ... eg special Tribe-Win-Conditions or what ever additional Tribe-specific may get added and does not fit into CONF-Sections)

Here we talk (afaik) about additional customized Starting-Capital-Settings defined while setting up a Game with a GUI. At this Point I agree with you VERY about the Use for such Settings especially for quick/heavy Games: With much more Resources the Player can do a quicker KickStart to expand on the Map reduces Time till Confrontation and final ShowDown .... even that's not the Way I like to play the Game resp. I prefer Adventure more than RTS even I can do/play both. Let's call it XP or DeCrepitude .. I am not sure what the exact Difference. What I want to say is: I do not want to go into Direction of RTS but respect that Direction but stress I prever more Directions of Adventure/Cooperation than Confrontation but however, while analyzing Improvements dealing my special Needs (eg. I did start modifying the Init-Scripts and found that the present Way is very plain and unsystematic resp require a Lot stupid Work to manage the Files/Code/Data to add additional Init-Features and an additional Abstraction like Seperation of Starting-Capital-Data from remaining Init-Matters would offer an excellent StepIn for a GUI to place a customized StartingCapital-Setting as Data inside the Tribe-Init-Chain .... so I embrace that RTS-Thing another Time even that's not the Direction I want to go but IMO neither this nor that Direction is the Point but the rational reasonable better. Some Math: One Player want another Starting-Capital and another Player want another Tribe-Init-Script ... EG I did start to adapt Castle-Village and place instead a WareHouse at first Order a Harbort and if that fail not a WareHouse but a HeadQuater due to that offers more Value to the Player as Balance to DisAdvantage of not having a Port and if that fail another Time at last a WareHouse gets tried to get placed and if that fail .... hmmm.... let's see if we can place instead a Ship in Expedition-State or or or. ... however, I don't think it's a good Way if I add a 3rd Init-Script and Players have to edit it to adapt their 20 specific Starting-Capital-Settings makes 40+20=60 different Init-Scripts resp 60 Options for the Player to set up a Game to play. Tired now from trying hitting the Nail and if I did not hit already close enough I doubt I will ever hit sufficient enough.. so my brief Resume is: Pro RTS-friendly StartingCapital-Settings, Abstraction resp Differentiation of StartingCapitalSetting for Storage from Village-Site-Settings inside Init-Script resp as different Options inside GUI for setting up a Game.)

Btw: I miss a Shoping-Way to place a Building and reduce the Storage according to the BuildCosts of that Building reducing Problems for Init-Scripts like a Player which can not get placed all his Starting-Buildings won't have DisAdvantages from receiving lesser Resources but only Time due to he can't utilize the missing Sites that quickly like the other Players. Oh... when you have this you don't need that ... this Way I don't argue normally but if a Feature is usefull than I don't care if another Feature can cover same Problem. Eg I won't drop Feature of different Init-Scripts due to a single super-smart Init-Script could do all.

Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top

Quote

wow thanks for the info! that's a lot and i think i understood most of it. i will read over it again when i get time tomorrow after work. only thing to clarify is "starting resource" as in whats in the warehouse when the game starts,not actual resources located near the HQ. only reason for the suggestion was to help have a quicker game when time is short i have a 70 hour work week.

the amount of effort put into this game amazes me! i downloaded this in 2008 and tried to play it but i couldn't figure it all out so i deleted the game. i re-installed last week and found the game amazing! i dont know if i was just a retard when i tried it the first time or you all have updated the game since then, but i am an instant fan! i do love RTS but i am really enjoying the logistical side of the game with the economy! the game is awesome like settlers, but it also resembles strongholds resource system which is a big seller to me! thanks again for such a quick reply and taking the time to explain why it does/doesn't work!

Top

Quote

SirVer wrote:

The Lua starting files can already be refactored to reuse common code. There is no need for a intermediate file format. adding a new starting condition is of course possible, but afaik the current starting conditions are very rarely switched at all - every new option is confusing for a new player and adds complexity to the game. If it is only used by very few players, it is a bad thing to add them in.

Starting-Types with Sea-Casle-Village (Harbort instead WareHouse) and a Harbort instead a HQ are valuable Options for the Player and it's the Nature of Newness that just few Players use them. Is that an Argument against every new Thing or did I miss the Point? May I commit any Patch with that Script(s)?

crazyeye, the game has changed a lot since 2008 - glad you like it now.>SirVer wrote:

The Lua starting files can already be refactored to reuse common code. There is no need for a intermediate file format. adding a new starting condition is of course possible, but afaik the current starting conditions are very rarely switched at all - every new option is confusing for a new player and adds complexity to the game. If it is only used by very few players, it is a bad thing to add them in.

Starting-Types with Sea-Castle-Village (Harbort instead WareHouse) and a Harbort instead a HQ are IMO valuable Options for the Player and it's the Nature of Newness that just few Players use them. Is your Argument against every new Thing or did I miss the Point? May I commit any Patch with that Script(s)?

Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top

Quote

SirVer wrote: ... Feature creep is very real and there are a ton of features that creeped into Widelands that are just a burden now - did you know that you can snap the windows to each other? There is an option for that in the options menu.

Never noted but noted that the Windows pop up exactly there I want to interact covering the Scene which represents the OverAll-Context (Map-View) of Things I want to do and am used to move these Windows automatically aside. HowEver, I wonder how that Burden, that should only be relevant when a Window get moved on the Screen, should cause significant Impact to OverAll-Performance or is it pure Code-Size for Implementation?

Btw 3 Questions:
1st) Does Lua use the ordninary Exception-Syntax ? : try { foo(); } catch (ExceptionType e) { bar (e); } 2nd) DO I need that to catch Failure from Placing additional Sites? The regular (plain) Lua-Way is afaik to take NIL as ReturnValue (RVAL) for Things like that omiting an Exception in many Cases.

3rd) I encountered an Behavior from Placement-Function I can not really understand concernoing the Range-Radius-Argument, which should be in its Nature really intuitive: I tried to increase Range somewhat to get additional Space for an additional Building (ShipYard) but Result was that lesser Sites were placeable. Playing somewhat with that Arguments didn't result in useful Idea what's going up there, so I left given R-Argument there as best experienced Result. So my stupid Question is what does the RR-Argument (RangeRadius) resp what does it not?

I need the Answers for first two Questions to handle properly Selection/Placement of HeadQuater/Port/WareHouse and the second to influence the Range the Sites get placed. May be I got right now the stupid Idea what's about related to Order of Placement (which I tried to keep to omit unforseen Errors) and especially the Placement of Castle resp Sites which increase Territory which is another Condition for Placement independent from PlacementRangeRadius PRR. Did just a quick Hack and Results were surprisingly disappointing as Attempt failed due to unknown Reasons, precisely: Placing with a larger PRR placed lesser Sites when with given PRR. That was rather currious. May be that the PRR-Filter filtered before Territory-Filter and PRR returned Locations for Placements which failed by Territory-Issues ... so my Idea know. Did not investigate that Matter since I did that Time, I played with, install a new BZR which eleminated my solved Work another time. I told about disappointed in my small Guide how to update Files/Installation. May be I think about another Try ... and will surely submit that File as a Patch/Branch. I am not satisfied about anything due to I made it self but I won't talk about submiting anything If I am not absolutely sure that it's useful/better than present. Btw: I am notr surprised that you can't see any Future for my new Scripts, which offer the Players to select a Castle-Village inclusive Port instead a WareHouse and ShipYard to get quickly able to colonize anywhere else on the Map causing quicker Expansion. So it's effectivle just a Castel-Village that factor in SeaFaring -- no Idea who need that.

Ivan the Terrible is dead .. Genghis Khan is dead .. and I do not feel well, too.

Top

Quote