Jump to content

elexis

WFG Retired
  • Posts

    3.644
  • Joined

  • Days Won

    59

Posts posted by elexis

  1. On 3/7/2019 at 2:12 AM, wowgetoffyourcellphone said:

    It seems to me that right now WFG has all the money it needs for its current goals. More than enough, actually. Something like $25,000+ currently in its vaults. It may be that WFG already has enough money for whatever "goal" or project you have in mind. 

    What are the current goals though? The funding campaign from 2013 at https://www.indiegogo.com/projects/support-0-a-d-an-open-source-strategy-game#/ specified 40k for a new pathfinder, somewhere like 80k or whatnot for the singleplayer campaign if I recall correctly. 25k may get you to any single goal, but after that the funding is gone.

    The numbers are public https://spi-inc.org/corporate/annual-reports/, since Wildfire Games is a member of the non-profit organization Software in the Public Interest as mentioned.

    Notice that Wildfire Games has running costs, of maybe USD 1000 for the servers and few hundred USD for travel costs. Also notice of the 33k from the campaign, 5k went towards merchandise. In 2018 WFG received about USD 3000 in donations and about USD 1000 server costs. What to do with that money noone figured out yet, and so it is kept in reserves (at least that's what's been happening so far). If nothing changes, it's at least good to know that one can afford server costs for the decades to come.

    On 3/7/2019 at 1:00 AM, Boudica said:

    I guarantee that you can get good programmers if you pay them well

    How can you guarantee that?

    On 3/5/2019 at 1:00 AM, Pudim said:

    but if you can have 2 or 3 programmers / artists full time, it would be very good

    25k USD / (10 USD/h) = 2500 hours. With 25 hours per week that's 100 weeks, i.e. 2 years for one contributor, excluding server cost. So indeed it  would need more funding.

    I expect Wildfire Games will not be able to raise sufficient money to hire even one contributor fulltime in the foreseeable future, but that doesn't mean one can't try to improve the situation. I can pull something out of the hat later, but I haven't finished the IRS documents, and they are just as dull as GDPR.

    • Like 1
  2. 45 minutes ago, stanislas69 said:
    2 hours ago, elexis said:

    [...] Arguments in favor. 

    Moving seems like a pretty good idea then. 

    I could imagine some people critizing that the implementation is moving things around for no reason. So the question is whether the provided arguments are too hypothetical or defeating arguments. One can often increase the sample size in such situations, then the consequences accumulate, making the advantages or disadvantages more grave, giving one a more clear picture which alternative is preferable.

    ResourceSupply.prototype.Schema = Engine.ReadFile("simulation/components/schemas/ResourceSupply.xml").replace("Resources.BuildChoicesSchema(true, true)", Resources.BuildChoicesSchema(true, true));

    Those should be *.xsd files, because they contains the Schema to validate XML files, if Im not mistaken.

    The most simple solution would probably be to remove the Schema code entirely from the component code (JS or C++) and have the component manager instead load the Schema from <componentname>.xsd.

    I don't know if that approach could work with the resource type definitions, or whether one can just skip validating these, or whether one could do something fancy with including another xsd file.

  3. The only arguable benefit of having the Schema in the JS Component implementation is to to have less user interaction when comparing the Schema with the implementation? We also have the JS and C++ interface files.

    The benefits of moving the Schema to an XML file each:

    • Mixing multiple languages in a single file is an anti-pattern. In webdevelopment one can easily mix html, css, javascript , php and mysql in the same file. While there is less user interaction between searching lines in the same file, it may become even more fragmented;  and the encoding of one language in the other language adds some overhead. For the same reason it's also better to keep GUI page JS in JS files and use the XML files to specify only how the page will appear and be accessible to JS.
    • Syntax highlighting in XML / JS supporting editors will be correct
    • Syntax checks by the Phabricator bot or in the IDE of the developer will inspect correctly
    • The Schema file could be read by external scripts. Parsing XML is much easier than JS or even C++.
    • One doesn't always have to compile C++ code again in order to changing some minor property of the Schema of a C++ component. It reminds me of the time when special templates were hardcoded in C++. (Special templates are more variable than Schemas though.)
    • The componentmanager implementaiton might or might not become cleaner. Those global JS Engine.RegisterComponentType calls at the end of every JS Simulation component file break a bit the nice pattern of these JS files only specifying one prototype and doing nothing else.

    Is the Schema actually used currently anywhere? I can't find any call to GetSchema() in *.js, *.cpp. Why the heck does the Pyrogenesis simulation not use the Schema currently to validate entity templates upon entity construction? Seems like a glaring use case. And SimulationDocs.h is disabled? And CCmpTemplateManager::Init also looks incomplete:

    	virtual void Init(const CParamNode& UNUSED(paramNode))
    	{
    		m_DisableValidation = false;
    
    		m_Validator.LoadGrammar(GetSimContext().GetComponentManager().GenerateSchema());
    		// TODO: handle errors loading the grammar here?
    		// TODO: support hotloading changes to the grammar
    	}

    About the word "engine components" -> #5366 works with JS components being engine components as well and should thus be moved to the pyrogenesis engine mod instead of the 0ad gamecontent mod. The only difference between the two types is that one of them has to be fast C++ and the other one can be slow but comfortable JS. C++ even hardcodes references to the JS components in the C++ / JS interfaces and via the C++ components that refer to the JS components through these interfaces. At least I don't find any other distinction between these JS simulation components and the C++ simulation components that would qualify them as gamecontent:

    Spoiler
    
    ./AIInterface.js
    ./AIProxy.js
    ./AlertRaiser.js
    ./Armour.js
    ./AttackDetection.js
    ./Attack.js
    ./AuraManager.js
    ./Auras.js
    ./Barter.js
    ./BattleDetection.js
    ./Builder.js
    ./BuildingAI.js
    ./BuildRestrictions.js
    ./Capturable.js
    ./CeasefireManager.js
    ./Cost.js
    ./Damage.js
    ./DeathDamage.js
    ./EndGameManager.js
    ./EntityLimits.js
    ./Fogging.js
    ./FormationAttack.js
    ./Formation.js
    ./Foundation.js
    ./Garrisonable.js
    ./GarrisonHolder.js
    ./Gate.js
    ./Guard.js
    ./GuiInterface.js
    ./Heal.js
    ./Health.js
    ./Identity.js
    ./Looter.js
    ./Loot.js
    ./Market.js
    ./Mirage.js
    ./MotionBall.js
    ./Pack.js
    ./Player.js
    ./PlayerManager.js
    ./ProductionQueue.js
    ./Promotion.js
    ./RallyPoint.js
    ./RangeOverlayManager.js
    ./Repairable.js
    ./ResourceDropsite.js
    ./ResourceGatherer.js
    ./ResourceSupply.js
    ./ResourceTrickle.js
    ./Settlement.js
    ./SkirmishReplacer.js
    ./Sound.js
    ./StatisticsTracker.js
    ./StatusBars.js
    ./TechnologyManager.js
    ./TerritoryDecay.js
    ./TerritoryDecayManager.js
    ./Timer.js
    ./Trader.js
    ./TrainingRestrictions.js
    ./Trigger.js
    ./TriggerPoint.js
    ./UnitAI.js
    ./UnitMotionFlying.js
    ./Upgrade.js
    ./ValueModificationManager.js
    ./Visibility.js
    ./VisionSharing.js
    ./WallPiece.js
    ./WallSet.js
    ./Wonder.js
    Quote

    ./CCmpAIManager.cpp
    ./CCmpCinemaManager.cpp
    ./CCmpCommandQueue.cpp
    ./CCmpDecay.cpp
    ./CCmpFootprint.cpp
    ./CCmpMinimap.cpp
    ./CCmpMotionBall.cpp
    ./CCmpObstruction.cpp
    ./CCmpObstructionManager.cpp
    ./CCmpOverlayRenderer.cpp
    ./CCmpOwnership.cpp
    ./CCmpParticleManager.cpp
    ./CCmpPathfinder_Common.h
    ./CCmpPathfinder.cpp
    ./CCmpPathfinder_Vertex.cpp
    ./CCmpPosition.cpp
    ./CCmpProjectileManager.cpp
    ./CCmpRallyPointRenderer.cpp
    ./CCmpRangeManager.cpp
    ./CCmpRangeOverlayRenderer.cpp
    ./CCmpSelectable.cpp
    ./CCmpSoundManager.cpp
    ./CCmpTemplateManager.cpp
    ./CCmpTerrain.cpp
    ./CCmpTerritoryInfluence.cpp
    ./CCmpTerritoryManager.cpp
    ./CCmpTest.cpp
    ./CCmpUnitMotion.cpp
    ./CCmpUnitRenderer.cpp
    ./CCmpVision.cpp
    ./CCmpVisualActor.cpp
    ./CCmpWaterManager.cpp

     

    Notice there is a gotcha about using XML files for the Schema, since some JS files (resources and damage types) create the Schema programmatically using JS. With XML one would have to have one XML file per resource per affected simulation component if one wants to support enabling multiple mods that add new resources each.

    The large XML file you posted above appears nicer than encoding that in JS. Another random example: CCmpPosition.cpp probably wouldn't look worse when that XML is in a separate file. So seems possibly nice, perhaps one can find some more specific applications to see if it's worth the refactoring and the additional userinteraction.

    (JSON might be more compact, but simulation components used XML to gain validation. Then I wonder why validation isn't reasonable for aura and tech templates if its reasonable for entity templates. Weren't auras introduced as JSON, then converted to XML by merging them into the entity templates, but that failed because different entity templates should refer to the same aura types? But perhaps that could have also been solved by having auras as separate validatable XML files? Actually, meh.)

  4. The lobby users have accepted the lobby terms and conditions. While there is a clause about multiple accounts being permissible, such requests are exemptions for specific reasons, for example if someone wants to test a lobby patch, if someone is a moderator, or if someone can host two games simultaneously with the (almost) same nickname. Otherwise, requests for nickname changes and secondary accounts are not granted, so that players are able to identify each other after they have seen each others in games, thus able to avoid each other if they can't stand each other etc. (one of the reasons).

  5. That is on MacOS / OSX or not? Gloox TLS is bugged differently on every platform ¯\_(o.o)_/¯

    On 2/26/2019 at 8:07 AM, stanislas69 said:

    are those js error message normal ?

    On 2/28/2019 at 12:30 PM, Imarok said:

    mods?

    I'm unable to determine what a normal error might be, also those are warnings. But opening the file and the accoring line number and reading the error message shows that the language code is undefined. Opening the error screenshot and reading the language dropdown reveals an undefined there too. So I'd be wondering whether the locale code is broken on that platform. The terms dialog uses the same code as the language selector, so I'd be wondering whether that's broken on the affected platform equally (main menu -> options -> language or something).

    On 2/26/2019 at 2:35 AM, oOWOOHOo said:

    "The TLC handshake did not complete successfully"

    No, I don't want no scrub... Also I guess that indicates you being the author of #5404.

    • Like 1
  6. On 2/26/2019 at 8:14 AM, stanislas69 said:

    I can render the game at 20x with very little lag

    We can't distinguish how fast it actually runs, this gamespeed number is an upper limit. Also the rendering is cut to 1 frame per simulation update when doing signficant fast-forwards. Running a non-visual replay with one and multiple threads would provide a comparison.

    Threading indeed won't solve the slow algorithm (laptops with only one core won't benefit), nor is the problem related in any way to networking code. It's just that the pathfinding is too slow, burns too much CPU cyles, with threading the other cores burn too many cycles more equally. It will make the CPU fan more noisy I suppose, but it should probably still be done (and then the algorithm improvements on top of that).

    • Like 3
  7. We have no lack of people who want to decide on gameplay as a whole.

    The gamedesign plans where one doesn't know which individuals will implement them, doesn't how they can be implemented, doesn't know when they will be implemented by the envisioned individuals are doomed to remain pipedreams. The plan usually put forward by gamedesign proposals is that someone invents a fun game concept, and then Wildfire Games is supposed to implement that. The reality is that Wildfire Games is not a company, doesn't have any employees. The people that have worked on 0 A.D. and pyrogenesis at a time, throughout the soon two decades of existence one way or another were countable on one or two hands. When they worked on it, they worked on it in their spare time. In contrast, some commercial companies that provide comparable "triple A" RTS games may spend millions on hundreds of employees. What a single person can accomplish in their free time is very small, in particular when every possible alternative proposal by players shall be taken into account. S, to be honest, what 0 A.D. needs is more people who are capable and available for years to work on 0 A.D as a whole, so that they can decide on 0 A.D. as a whole and then implement 0 A.D. as a whole. Gameplans that decide on 0 A.D. as a whole without being able to plan an implementation with our current technical C++/JS implementation is not able to estimate the amount of work that is needed for that plan, not able to demonstrate the feasibility of 'the whole'.

    So it should be

    Quote

    To be honest, 0AD needs someone who decides on gameplay as a whole and then implements that.

    I'm pointing this out because if we only get "someone who decides on gameplay as a whole" without the proof of concept, we might actually worsen the situation for 0 A.D. as a whole, because it removes the freedom of the contributors to plan what they will implement. They are degraded from the developer to the programmer.

    I do get that the point that is often brought about is that developers can keep adding random stuff if they didn't subscribe to a common vision. But it seems rather that this is due to the absence of experience with the game and existing game concepts (implemented and not implemented), rather than the lack of "a person who decides on the game as a whole".

    (Also notice that Wildfire Games as a whole should decide on 0 A.D. as a whole in an ideal world (i.e. no time and effort cost to gain knowledge and take decisions and no possibility of mistakes due to partial knowledge).)

    On 9/11/2018 at 10:20 AM, (-_-) said:

    But thankfully, the amount of bugs and stuff means theres still stuff to do

    But that's reversed. If we didn't had to spend past and future years on defects (and too long or sometimes emotional discussions on minor details), we could instead spend (and have had spent) our time on implementing new features and mechanics and revisioning the game.

    On 9/11/2018 at 10:20 AM, (-_-) said:

    But there isnt any major changes, features or mechanics planned

    Depends on whether "planned" means "scheduled" and what threshold one defines for "major", because we have several lifetimes of plans on trac issues, in the old design documents, in forum threads. And I guess everyone has desires and imagination of the potential 0 A.D. could become, but fails to develop them (both figuratively and literally) because of the reallife constraints (the time it takes to implement it).

    I can provide a recent example. From August 2017 to February 2018 I worked merely on fixing bugs of the rmgen codebase. There was no space for any imagination, because there were just defects in the code that consumed months to rework. While doing so I gained a lot more knowledge on the gamedesign background, what the authors of these maps and map library methods (Spahbod, matei, Mythos Ruler, FeXoR) had in mind (or at least published) at the time of authorship. After most of the defects were gone and after months of time to think about the essence of that codebase, I gained the freedom to envision and implement the Kushite mapscripts, 'as a whole'.

    Exchange the program folder worked on, and we get the same storyline that we would need for someone who will work on formations/batallions, or a history mode, or as in this thread, many news civs.

    I elaborated on this because (a) it has potential for damage if put into action as is (spending time and effort on possibly unrealizable project ideas), (b) the same is stated by others in other threads, (c) there are no hypotheticals or conditions in that statement.

    On 9/11/2018 at 10:20 AM, (-_-) said:

    However, personally I dont like something that doesnt evolve with time. 

    I agree.

    On 9/11/2018 at 8:46 AM, wowgetoffyourcellphone said:

    Epochs

    On topic, it would be great to have many more civs, but they should IMO be part of separate games that use the same pyrogenesis engine. Like the 0ad mod for civs between 500 bc and 0 ad, the 500ad mod for the civs between 0 and 500ad, and so forth. Then if someone wants to go bananas and do extremely ahistoric fights, they can launch the games as mods simultaneously. 0 A.D. has the claimed purpose to inform players of the history of each civilization. So there should be a historical campaign for each these civilizations that should be more fascinating visual entertainment than any movie or documentary while the player gains the knowledge without any efforts to blindly learn it, like in school. At least that's what I would spend my time on before spending equal amount of time adding more civs. (Though I still think that the celtic tribes that aren't britons and aren't gauls, north of rome are missing if we want to implement the early history of rome in a campaign.)

    • Like 3
  8. Use cases for accounts:

    • Accountability before WFG: Being able to enforce terms of service by rejecting the service to users that violate the terms.
    • Accountability before the community: You stand by the history of your posts. To allow others to seek you out or avoid you, they are able to recognize you by the nickname that is displayed. They shouldn't have to conclude from the forum post content, let alone stray forum posts from years ago.

    Examples:

    • People who look through past forum or phabricator messages and have a question to the author of messages or patches are actually able to find the author under that nickname.
    • People don't try to inform you of things they have already informed you before.
    • For example the GettingStarted bit was the first thing people send to you, but you have have a long Phabricator history, so the people were mislead by the new account.
    • If someone would create a new account on Phabricator, one would repeat all the newcomer stories on coding conventions and codebase explanations from scratch instead of  recalling what that one already knows or doesn't know.

    Use cases for uniqueness of accounts:

    • By definition of the account: The defined purpose of the nickname field is to indicate the author of the message. Two different names are supposed to identify two different people. If people are permitted a second account for testing software, the nicknames should be similar, for example "user" and "user-testing". If we don't want that but a forum where noone knows who everyone else is, it would have to be built into the software, similar to 4chan, so that people have no false expectations of what an account means.
    • Missing practicality: Even if you post in your forum posts that this is your second account, it is unfeasible as a general rule. For example servo didn't get that you are smiley although it was stated explicitly. Sending a personal message to every community member and writing it in every forum post costs a lot of time and space while the nickname field still displays you as a different natural person and people don't get it. Imagine everyone would have 3-4 fun accounts. People would not be able to keep track of who is who anymore. While this 'not hiding the identity' model works when 99% of the users stick to the rule and 1% exempts itself from the rule, it surely wouldn't work anymore if the other 99% exempt themselves too.
    On 2/15/2019 at 2:06 PM, Servo said:

    I don’t think it’s bad to have couple of accounts in the lobby as long as you don’t abuse it. I was requesting help to have another account so that if I have visitors or gamer relatives whom I can play in the same house to no avail.

    Visitors in the same house are different persons that should have their own account. That's not the same as having two accounts for your own. If there is a technical reason to have two accounts, for example one for permitted lurking and one for playing, or a secondary account to test a bug in the development lobby. But in these cases, it should be accountname1 and accountname2, so that it is clear who the owner is (which is also the reason why we are ok with (-_-) using the smiley accountname on the lobby, but not the cloud9 one).

    The same is true for all the other people on the lobby or forums, high profile or not, who create smurf accounts. Creating a new nickname so that people assume you are a different person is behavior that we used to see from people who solely join the community to enjoy playing and harassing others, but not from people who have worked hand in hand for years on the project.

    56 minutes ago, cloud9 said:

    fine

    So thanks if that is the case. I don't like being in a trilemma situation as a moderator where I either have to abandon the no-smurfing rule, ban or stop moderating.

    By the way game companies (like Blizzard if I recall correctly) counter smurfing by new accounts not being able to participate in chat or rated games until they gained a reputation and having account creation cost money (instead of moderation afaik).

  9. 38 minutes ago, Nescio said:

    Historically, a city was only conquered when all of its fortifications were taken.

    Perhaps that argument could be filled with some examples, since it can only be true for a part of the battles, perhaps the majority. For example Vercingetorix had to surrender to Cesar because they were starving, despite still being fortified as far as I know.

    • Like 4
  10. Your legal person doesn't concern anyone unless you became criminally active on our online platform. Otherwise we only care about your IP address and whether that uses our service in violation of the terms of service. The service is rejected to users that violate the terms. Notice that you know all of that already because you have commented about all of that stuff with your other online account on phabricator and the lobby, and probably irc too.

    That about the legal side. About the moral part: If you actually "don't hide" that you are smiley, then why are you arguing for registering as many accounts as you desire?

    Chanigng nicknames because they are more interesting is not covered by the terms and imply the problem that people lose the ability to ban you from their matches, lose the ability to leave matches when they see you are there too, or correspondingly stop responding to your forum output. An account enables accountability, removing accounts removes accountability. Pretending to people who you have become very familiar with after countless hours of game sessions and partnership in code projects, for, it must have been years, to be a  a total stranger is joining the discussion under false pretenses.

    On 2/6/2019 at 5:36 PM, cloud9 said:

    Apologies for the false alarm. It was an accidental reverting of the config file. Which leads to a more understandable conclusion as I was banned from arena23 for a valid reason. (Multiaccount) 

    I can't keep track of how often you have intentionally posted profanity in order to become muted, changed your nickname after we kicked you many times already and how often we banned your multiple smurf accounts and your original account temporarily. Last time I logged into the lobby I only saw you shouting "why the @#&#036;% am I not muted". Saying that you don't understand the rules and that it was unintentional is something that works the first 5-10 times, but at some point I cannot take this as honest and good faith anymore. We just had the same discussion about your "accidentally lost" lobby account password last week already with at least two other lobby accounts. Given that you have bragged on the lobby that you have intentionally changed your phabricator password so that you lose access makes me doubt whether your lobby password loss was an accident. But in case that you have created the cloud9 forum account because you merely lost your forum password: https://wildfiregames.com/forum/index.php?/lostpassword/.

    • Like 2
  11. What do you think how bloody my knees were sending PMs and begging people to commit who had no interest in the patches throughout 2015? One always had to consider how far one could go with spamming people before they would stop responding and go offline.

    If you want something to change, you gotta be that change, noone else can or will do it for you.

    Sure, there's a condition to getting commit access, that is mostly leaving a good impression on the members.

  12. Techs in the summary screen are a must-have. It's good that they are ordered chronologically, but we should also record the time when they were researched, so that viewers can compare when the players researched a specific technology and how it influenced their economic or attack stats. In particular it would be nice to show them on the graphs as icons. Equally should record the time when players are defeated or have won, and the defeat reason.

    (Also it would help to formally report that Set vs. JSON issue of the GUIInterface that you informally reported on multiple occasion.)

    Great features, popular mod. I guess the terms-and-conditions check for lobby-autologin is still missing, and I guess noone reads the terms anyway, and they are updated rarely as well. The nickname option was removed? If so and if someone checked for the absence of possible security problems, perhaps the popular mod should be upload to mod.io finally.

    • Like 3
×
×
  • Create New...